Tag: Methodologies

The Art and Science of Servant Leader in Agile Scrum world

Written by Sreedhar Koganti on July 22, 2014. Posted in Articles. 4 Comments on The Art and Science of Servant Leader in Agile Scrum world

In this article we will examine some of the concepts and background of Servant Leader. Discuss some well-known leadership styles and explain how the Servant Leader associated with them. Discuss the characteristics of Servant Leader that pertain to a Scrum Master.

One of the Key roles in Scrum is Scrum Master. The Scrum frame work has given a clear definition for Scrum Master. Scrum Master meant to be an Agile Coach and a Servant Leader. To have a successful Agile-Scrum project, Scrum Master should play an active role. To precisely say Scrum Master should be a Servant Leader. In order to know clear definition of Servant Leader, first we need to know who is a leader and what leader ship means.

The most challenging question is what is Leadership?

There are many definitions for Leader and Leadership. Many people described Leadership in different ways. The most common conclusive answer is, “Leadership is a process of social influence, which maximizes the efforts of others, towards the achievement of a goal”. My personal view and the most influential definition to me is “Leadership is an art and science of leading others to deliberately create a result that wouldn’t have happened otherwise.”

The reason I liked the idea of defining “Leadership is an art and science of leading”, is because I truly believe and also many scholars stated that Leadership has nothing to do with seniority, one’s position in the hierarchy, nothing to do with title, and most importantly it is not meant to be just management.

The most commonly recognized qualities of leader are: Honesty, Ability to Delegate, Communication, Sense of Humor, Confidence, Commitment, Positive Attitude, Creativity, Intuition, Ability to Inspire, and Clear Vision. There are other qualities we often see in books are, Self-Awareness, Self-Direction, Ability to Motivate and Social Awareness etc.
A leader can have one or all the above qualities, but they choose to follow different management style to achieve results. In general the management styles are broadly defined as:

Autocratic Leaders: Make decisions without consulting their team members, even if their input would be useful.
Democratic Leaders: Make the final decisions, but they include team members in the decision-making process.
Laissez-faire: leaders give their team members a lot of freedom in how they do their work, and how they set their deadlines.

I won’t say they are the only styles, but I would say these are popular styles. I am hoping I gave enough information on Leader and Leadership. Let’s switch the gears and discuss Servant Leader.

Background of Servant Leader:

The style and definition of Servant Leader has been introduced by Robert K. Greenleaf. I would say before he defined, it might be there but he gave a form and definition to it and made it popular. The idea of the servant as a leader came partly out of his own experience. Greenleaf at one place mentions as “the need for a better approach to leadership, one that puts serving others—including employees, customers, and community—as the number one priority. Servant leadership emphasizes increased service to others, a holistic approach to work, promoting a sense of community, and the sharing of power in decision making.”

The characteristics of the Servant-Leader from Greenleaf are: Listening, Empathy, Healing, Awareness, Persuasion, Conceptualization, Foresight, Stewardship, Commitment to the growth of people, Building community.

Servant Leader in Scrum:

Just to reiterate, in the beginning of article I mentioned that Scrum Master is a Servant Leader. Just keep that in mind. If one truly believes and understands the soul of leadership and the philosophy behind Servant Leadership we can safely say ScrumMaster/Servant Leader is an important and very interesting role in Scrum. In Scrum framework, Scrum Master acts as a servant leader that serves the product owner, team and organization.

How can a Scrum Master be a True Servant Leader?

To know the association, first we need to know some of the responsibilities of Scrum Master. They are:

Responsible for making sure that the team lives by the values and practices the principles of Scrum.
Scrum Master does anything possible to help the team perform at their highest level.
The Scrum Master is also often viewed as a protector of the team.
Involves in removing any impediments to the process and also in the Team.
Facilitating meetings.
Coordinating with Product Owner and the Team.
Making sure that team doesn’t overcommit the work.
Establishing clear communication channel between stakeholders, Team and Product Owner.
Helps in reaching goals to deliver potential shippable product.
Etc

Let’s also see some of the Key Characteristics of Servant Leader. They are: Awareness, Listening, Persuasion, Empathy, Healing, coaching etc.

If we look into the Scrum Master Responsibilities and characteristics, we can conclude that Scrum Master is a Servant Leader, and this kind of leadership style only can help in achieving better results in Agile environments.

A true leader will deal with the situation and uses expert judgment in taking decisions. In order to achieve above responsibilities, Scrum Master/Servant Leader should not stick to only one management style or philosophy. I meant to say depending on situation, Scrum Master should act as a Democratic Leader, Laissez-faire, and Autocratic Leaders etc. The Scrum Master/Servant Leader can only achieve above responsibilities by following different management styles in different situations.

Where Servant Leader stands in the Pyramid/Equilateral Triangle:

As pictures is worth of thousand words. I felt like explaining it with an example picture. Whenever we talk about Leader or Leadership, we find a picture and in that it will show Leader will be on the top of the PYRAMID and several layers will be represented below him, could be characteristics, organization structure etc.

In Scrum world, I would see Scrum Master/Servant Leader will be inside the Equilateral Triangle. Not on the Top of it.

Picture 1 : Scrum Master/Servant Leader Equilateral Triangle

If you look at the picture 1, Product Owner (Stakeholders) is on one side, Team is on one side and Scrum Sprint is in another side. The Scrum Master/Servant Leader is inside. It’s the Scrum Master’s duty to keep all the sides and proportions are equal. Keep the balance between proportions. In order to achieve, Scrum Master need to follow all the Servant Leader principles, guidelines, characteristics etc. Scrum Master ultimate goal is to make sure the scrum team lives by the values, principles and practices the Scrum at all time, the only way Scrum Master could control is by live inside the boundaries and understand the philosophy of all the proportions. Throughout the article I am stressing Scrum Master is a Servant Leader, there is another term often we hear is “Scrum Master is an Agile Coach”. Coaching is one of the characteristic of Servant Leader. So Scrum Master needs to help the team and does anything possible to make the team perform at their highest level. To achieve this, Scrum Master needs to make sure that, there won’t be any impediments to reach the goals, to be a better communicator, be a better facilitator, make sure that team won’t overcommit, develop good harmony between product owner and the Team. Regarding picture, the only reason I kept more than two hands and two legs, just to show that Scrum Master should be capable to do more and to bring believability.

Summary

Scrum Master is a very key component in the Scrum Framework, one need to be a better agile coach or Servant leader to achieve goals and to deliver potentially a shippable product. Scrum Master is not a Project Manager, though he manages at some level; Scrum Master is a Leader with the capabilities and abilities to serve the Scrum Team as a Servant Leader.

Don’t forget to leave your comments below.

Starting at Red

Written by Duncan Watts on June 10, 2014. Posted in Articles. 7 Comments on Starting at Red

Anybody who has worked on projects for any length of time is familiar with this scenario: The project starts with lots of enthusiasm, there are no real issues yet and plenty of time available. Status reports are all “Green”. All is well in Project Management Land.

Then issues start to kick in and aren’t getting resolved fast enough. Still the status is “Green” because it wouldn’t look good to raise it to “Amber”, and anyway there’s still plenty of time to sort everything out and get back on track.

Eventually it’s clear that the project is not going to be able to meet the deadlines and the PM grudgingly pushes the status to “Red” where it remains…

I haven’t analysed it to death, but here’s a suggestion. Start at “Red”. Sounds crazy? Bear with me…

Code Red

When a project starts, the team is as far from delivering anything as it will ever be. Sounds pretty much like a “Red” scenario to me. What if the project remained at “Red” until the PM could justify downgrading it to “Amber” – based on progress achieved, and then eventually (hopefully) “Green”?

In theory it shouldn’t matter, but in reality it does. Why?

Why Green doesn’t work

The reason that “Green” is bad is that it means two different things.

At the start of the project we have no idea if we’re going to achieve our goals so saying the project is “Green” really means “we haven’t yet found a reason why we won’t deliver”.

If the project is still “Green” a week before delivery then – you would hope – that it now means “we will definitely deliver”.

If a project starts at “Green” and remains “Green” all the way through, at what point does it go from being “we haven’t yet found a reason why we won’t deliver” to “we will definitely deliver”? At some point it will have changed, but this is not recorded by a change of project status. Strange. Seems like an important distinction to make.

Keeping the PM honest

“Green” is a problem because reality doesn’t work like a textbook. It is usually very hard for the PM to change the project’s status. It can cause panic within a Project Board – and lots of extra work and unwanted attention for the PM. So PMs, particularly inexperienced ones, are very reluctant to change status.

Starting at “Red”, on the other hand, there is no need to worry about scaring the Project Board because a “Red” status is the norm. This clarifies that “Green” only means “we will deliver”, and no project can go to “Green” until it is clear that the progress made justifies the change of status.

The PM will naturally be keen to find reasons to change the status to “Amber” and then “Green”, but this will require delivering good news, and having positive conversations with the Project Board to justify the change – which is much easier than delivering the bad news required to go from “Green” to “Amber” to “Red”.

Empowering the Project Board

When a project is “Green” by default, there is very little for the Project Board to do until the moment when the PM is forced to acknowledge a problem and change the status. Starting at “Red” changes the dynamic. The emphasis of the board can now be on questioning what can be done, and how the board can assist, to go to “Amber” and then “Green” before there is a problem, rather than waiting until it is too late.

The Project Board needs to be vigilant about questioning any change of status by the PM to ensure it doesn’t go “Green” before it is justified. But again, the conversations would be about positive changes, rather than negative ones. A status of “Red” allows the board to focus on the things that are critical to success while there is still time to address the problems.

Creating a questioning environment

When a project is coasting at “Green” it is easy to lose track of what is critical to success and focus on working through a given task list, putting off difficult issues because there is time to resolve them later (we’re “Green” after all).

Starting at “Red” makes it easier to focus the team on the critical activities required to go to “Green”. Everything else is secondary. This is the kind of project environment that is usually only created when there is a serious problem. Why wait until then? Start with the attitude that the project is going to fail unless you take immediate action – because it is!

The challenge

On my next project I’m going to start all my reports with a status of “Red”, and refuse to change status until I have a good reason. When I’m asked why, I’ll carefully explain why it’s better this way. My challenge to all you PMs and BAs out there is this: Do the same. Try it out on your next project, and let me know how it works out.

Don’t forget to leave your comments below.

Eyes on Target

Written by Charles Gallagher on June 3, 2014. Posted in Articles. 9 Comments on Eyes on Target

“Concentrate all your thoughts upon the work at hand. The sun’s rays do not burn until brought to a focus.”
-Alexander Graham Bell

One of the toughest challenges a project manager has is to make sure the team is continually focused on the right tasks at just the right time. It is not really either one of those tasks that is very difficult. It is striking the precise balance to make both happen in tandem that is often extremely difficult to achieve. In my experience this can be accomplished via three techniques we will call the three C’s:

Cadence, Critical Path & Control.

Step #1 Cadence: The real power of cadence is in the habits it forms. Establishing the pace—, the rhythm of the project—is a key goal when establishing a productive working energy with your team. Set up a consistent meeting schedule, one that makes sense for your team—perhaps once a week or even once a day depending on the required velocity of the project. The goal is to get the team in the cadence of the Deming Cycle, Plan-Do-Check-Act until the task is done.

Step #2 Critical Path: The importance of understanding the critical path is the ability to keep the schedule in context of its priority. All tasks are not created equal, and often the most pressing tasks are not the ones that receive our proper attention. So often we attack the tasks that are low hanging fruit or the ones that fit into the rhythm of the project dynamics. And by default, we frequently leave for last the tasks most critical to overall project success. Even more, team members do not always have the same sense of urgency or situational awareness as the project leader or other key stakeholders who may be higher up the organizational food chain. By leading your team to the critical path, and keeping them on it, you can focus on the right tasks at the right time and establish a cadence to accelerate your project execution velocity.

Step #3 Control: The final step in the process is establishing control— a good grip on the team, the project, and the cadence as you stay focused on the critical path. This is very much akin to being a race car driver and knowing when to press on the gas or when to apply the brakes. If you find that your project is loaded with complexity consider separating out your weekly meetings into two: one for task updates and the other devoted strictly to critical thinking & project issues. When updating tasks, keep your team focused on the amount of time remaining to complete a task. When focusing on critical thinking & issues, keep your team focused on the facts and the scope of what the project is trying to achieve.

Give the three C’s a try on your next project. Set that cadence right out of the gate, find the critical path and grip that steering wheel for establishing good control of your processes. If you do this well you will keep your team in a productive rhythm, you will stay laser focused on the goals and you will ultimately achieve that sweet success which is to deliver just the right tasks at just the right time.

Don’t forget to leave your comments below.

My Projects Have to be Waterfall, What Can I do?

Written by Joseph Flahiff on May 27, 2014. Posted in Articles. 10 Comments on My Projects Have to be Waterfall, What Can I do?

People often say to me, “My projects have to be waterfall. Is there anything from the lean and agile movement that I can begin to use, to improve delivery, without changing how my projects are delivered?”

My answer is always the same, “Yes!”

There are a number of things that can be implemented by a manager or project manager within their domain of control that will immediately improve their ability to deliver without impacting the project from the perspective of an external observer. I have three favorites:

Improving teaming
Periodic Retrospectives
Mapping the value stream

In this article we will look at number 2: Periodic Retrospectives. A retrospective is similar to a Lesson’s learned exercise but different in some key areas. Traditional Lessons Learned sessions are useless for thee key reasons:

Items are Team / Project / Technology specific
They are held at the end of the project
If items are not team, technology or project specific, they are so vague they are useless.

Let’s look at each of these in turn.

Items on the Lessons Learned are Team/Project/Technology Specific

The majority of the items that come up on a lessons learned session are specific to the project/team or technology for that project. Typical items that come up in a traditional lessons learned are things like, “The ice-a-nator vendor didn’t understand our requirements” or “The XYZ and ABC systems were not compatible and we didn’t know that during planning.” These are not really helpful because, the same team will not be on the next project, the project itself and the issues of the specific context will not be the same on the next project, and the technology will be different on the next project. So, I find that any project, team or technology specific items are not useful in a lessons learned context.

They are held at the end of the project.

Traditional lessons learned are held when the project is completed. Presumably to learn from what went on during the project and not make these same mistakes on future projects. The problem with this approach is most people can’t remember what happened 2 weeks ago much less what happened six months or 2 years ago. Trying to dredge up useful lessons learned over that period of time is nearly impossible. Additionally as we noted above, if the items are specific to the project, but the project is over, there is nothing to do with the information, no one can learn from it, nothing can be done with the information to improve future projects. Two strikes on this one.

If items are not team, technology or project specific they are so vague as to be useless.

In order to deal with the above two issues people will often generalize the information to make it universally applicable to future projects. If we attempt to generalize the lessons learned to make them applicable to other projects they get so generic as to be useless. I hear things like, “Communication was a problem”, “Stakeholders should be more involved”, “Budgets should have been more controlled.” And things like that. While these statements may be true, they are useless because they make no recommendation of root cause or corrective action. How could they? Nearly every real problem that could/ should be addressed to improve production, is a tangled web of interdependent project, team and technology specific issues that interplay creating the issue. Every project has its own unique web of issues making general solutions very rare indeed.

So What can be learned from a Lean/Agile approach?

There is a fundamental difference between traditional lessons learned and the lean/agile approach, in how, when and why they are done. Traditional lessons learned are done to help future projects to not make the same mistakes made on the project. Lean and agile lessons learned (typically called retrospective or Kaizen events) are intended to make immediate improvements on the current project. Call them what you like they are frequently held events to improve the process of the current project by small steps over time.

Changing the purpose and frequency of the lessons learned sessions resolves the three issues that plague the traditional lessons learned. Let’s look at the impact it has on the problems of a typical lessons learned.

Items on the Lessons Learned are Team/Project/Technology Specific

The items identified are still specific to the team, project or technology, but that is ok because the team project and technology are currently in flight and the team in the retrospective/Kaizen has the knowledge and context to do something about the items identified.

They are held at the end of the project.

Lean/Agile sessions are not held at the end of the project, they are held frequently (every 2 – 4 weeks) throughout the project. This results in three key outcomes. 1) It is much easier to remember what went well and what needed improvement, to make changes over a short time period than a long one. 2) The sessions are held mid-project so the items can be acted upon by the team that identified them, in the context that they have relevance. 3) Another session will be held in a couple of weeks, which allows the team to inspect the results of the actions they took to rectify a problem and adapt a new solution if the last one didn’t fix the problem.

If items are not team, technology or project specific they are so vague as to be useless.

In a Retrospective / Kaizen event items are not generalized so much that they are useless. The meeting is not over until the problems, root causes and solutions are made very clear and are given specific actions that are planned into the project to improve the working of the group. Finally they are checked at the next retrospective / Kaizen to see if the action was taken and if it had the intended results.

Anyone can improve their teams ability to deliver by learning how lean and agile teams do lesson’s learned and starting to use them to incrementally improve over time, even if their project is managed with a traditional approach.

Don’t forget to leave your comments below.

7 Steps to Improve Collaboration in Your Team

Written by Amanda Kelly on May 13, 2014. Posted in Articles. 10 Comments on 7 Steps to Improve Collaboration in Your Team

kelly may13 Effective collaboration achieves what no single team member can on her own. As business magnate Richard Branson said, “A business has to be involving, it has to be fun, and it has to exercise your creative instincts.” The best collaborations do this—optimize each person’s skills by utilizing suggestions from around the table, inspiring cooperation and creative buy-in from all involved.

Here are seven effective ways to create stronger team collaboration.

Aggregate and adapt: Any good project manager will bring ideas and plans to the table. The most collaborative will be highly skilled at weaving in the suggestions, ideas and goals of their team for a best-of fusion. Complex, multidisciplinary projects need to employ agile methodologies, involving innovation from all stakeholders and parties to succeed. The use of real-time data to help participants understand what is and isn’t working allows adjustments to be made on the fly. Successful collaboration is an aggregate of the best ideas while remaining adaptive and flexible.
Listen first: An effective collaborator knows how to bridge differing ideas into workable solutions. Getting to the root of any new concept or suggestion involves active listening, and listening actively to everyone with a stake in the outcome before mapping a course. Active listening includes giving feedback to confirm and clarify the information that was shared, and having a discussion in real time. A great collaborator will be able to respond most effectively once all parties have been heard. Team members want to feel valued, and being heard is where being valued begins.
Energize: The best collaborators assume that others are working smart and working hard. An effective and collaborative leader can bring inspiration and energy into a meeting room or conversation by helping team members feel valued. They sincerely express appreciation for a job well done. When criticism is offered thoughtfully and in the spirit of “your work is important to this project’s success,” effective collaboration becomes second nature. Talking about issues that need to be addressed can be done in a way that gets the team motivated about what’s possible. A motivated, energized team is a project’s strongest asset.
Remain open: Great collaborators always keep an open mind and know that brilliant ideas come from the unexpected. Openness is also crucial in building an atmosphere of trust. Workplace relationships are successful when employees are comfortable enough to voice concerns and make suggestions. Satisfied employees comfortably voice concerns and ask questions, and they know where to find the answers. Remaining open to new ideas, accomplishments and thoughtful critique empowers the entire team. The result: Faster problem-solving, healthier teamwork, greater trust and ultimately improved performance.
Be transparent: The most effective collaborators are less concerned with titles and roles than they are with solutions. If a fantastic suggestion is made they give credit where credit is due, regardless of source. Furthermore, effective collaborators clearly define expectations and share information across the board. Clear and inclusive communication allows team members to know that they matter enough to be told the truth. Sharing details with the team increases a sense of workplace community, and adds to the spirit of collaboration. Teams thrive in environments that encourage trial and error and encourage participation.
Have fun! Plato is credited with saying that you can discover more about a person in an hour of play than in a year of conversation. An organization or project is more successful when morale, motivation and trust are high. Having fun together—from Tuesday lunches to a bowling night to meetings where humor and optimism have their place—make a positive difference in helping team members from different parts of any project feel connected. Healthy environments incorporate appropriate camaraderie-building events and attitudes, fostering a sense of connectedness and accountability that goes beyond schedules and deadlines.
Transcend insularity: The most effective collaborators will know that the strongest parts make up the strongest whole. Workgroups have a tendency to silo. But the workplace of today is best served by operating without boundaries. So instead, make collaboration the goal and hold each member of the team accountable for their participation.

Sustained dialogue, frequent opportunities to connect through technology and a mutual sense of purpose will help collaboration become second nature. Look for common ground and emerging issues of mutual interest, and encourage team members to connect and discuss.

What would be your #8 collaboration tip? Let us know in the comment section below.