An Agile organization, let’s lose all the managers?!

Many managers think that their job will become obsolete, once their organization starts adopting Agile. However, we need Agile Leaders more than ever! The Agile philosophy is fundamentally different from what we are used to. We need Leaders with focus on turning the old organisation-reality into the new one. He/she resides in a continuous state of organization-transformation, enhancing team-ownership and cultural improvement. The role will change, but it will not become obsolete!

How managers were successful

As a manager in a traditional organization you have a number of roles: planner, quality-guard, director, budgetkeeper and human resource manager. All these tasks carry a large responsibility and are crucial for operating the organization. The most important responsibility is to maintain stability, planability and predictability.
These responsibilities are often obtained by a proven track-record of results, full business-awareness, measuring outcomes and guiding your people’s careers. Schedules are packed with bilaterals, steering committees, content meetings and in parallel you’re trying to keep up with all emails on content and process questions. And last but not least, you need to make sure that everyone stays within yearly budgets and plans!

Why organizations choose Agile

Changing market conditions, rapidly evolving IT-environments and increasing competition drives many organizations to choose the Agile approach. Organizations face an increase of complexity that requires more flexibility, transparancy, creativity and customer focus than ever. That is where Agile and Scrum kick in. Agile organizations are seen as a living system, evolving in an unpredictable and fast changing world. Agility has focus on customers and provides a stable, but flexible way of organizing.

Teams hit the glass ceiling

By applying Agile and Scrum, responsibilities will gradually shift. Once teams understand their role, they will want to:

Select their own team members
Have conversations on appraisals and rewards
Collaborate on plans and budgets together with the Product Owner
Make their own technical\quality related choices

Leaders will feel the limitations of the previously applied leadership style. They are not used to be rewarded for the structural improvement of the ecosystem and the teams: knowing the maturity level of the team and guiding them to the next phase.
In many cases this is where the Agile transformation stops or locks down, because Leaders experience this as a threat to their status quo. The experience of loosing the influence you have build up in many years can lead to frustration. In this phase you hear sentences like “we have been Leaned” or “Agiled” and that “the transformation was only meant to happen in the lower ranks and in the teams”.
The Leader will experience an identity crisis and a sense of emptiness. Am I still of any value for my organisation?….YES!!!!!

A different, but crucial Leadership Role

It is the Agile Leaders job to turn Transactional Management into Transformational Leadership. In other words: You Manage Things, but you Lead People. He/she has the crucial role to bring the organization from “Doing Agile” to “Being Agile”. This is reverse career making: You are focused on Teams and not at the career ladder itself.His daily job is to increase Team maturity by providing them a dose of freedom they can handle. Or maybe a little more than that. Too much or too few freedom might cause chaos, illness, burn-out or bore-out and increased turnover.
Coming back to Lean: When Leaders and Teams focus on improving, they probably won’t even notice that they are in a transformation. While continuously improving you make deliberate choices, guided by a common vision: on what to do and also on what NOT to do.

You Manage Things, but you Lead People

Your role as Transformational Leader

This is how a Transformational Leader operates:

Determine direction/vision/greater goals: Only speak in terms of WHY. You leave the HOW and the WHAT to the teams
When employees approach you, give trust: Do not solve it for them, but ask a question back or give them a hint
Provide clear boundaries: Clear boundaries provide teams with clarity and freedom to do what is needed for customers
Grow and Develop Teams: Apply a structured, step by step approach for Growing Team Maturity
Always blame yourself and show example behaviour: Not the organization or the teams were to blame. Only you are. In this way you set a new culture of responsibility
Protect your teams: for managers, steering committees, processes, systems and procedures
Measure and test customer results: You still measure, but now in terms of Customer Value and Employee Learning Capacity
Facilitate the organization: Create an environment where teams can excel and be successful. Daily improve the ecosystem

What competences do you need as an Agile Leader?

Facilitator: Modest, giving meaning, emotionally intelligent, creative, hungry, curious, open minded. You Lead but you also serve. Focused on the organization as a whole.
Connector: Team focused, sensitive, holistic view on processes and complex issues, helicopter view, down to earth. Focused on the internals of the organization.
Coach: Making contact, delegate but follow-up, good listener, sensitive to others’ needs, creating a safe environment, a good sense for putting the right person in the right place.

Back to everyday reality

As you can see the Agile Leader is a crucial element in creating autonomous teams. New responsibilities will replace old ones. The Agile Leader is responsible to make the organization understand why change is happening. Only with the support of executive management, human resources, business and other departments he can create space to learn new and unlearn old behaviour.

In an Agile organization we replace Management by Leadership and this will not happen overnight!

Typical Pitfalls

A typical pitfall is to not involve the teams in defining the the WHY, HOW and WHAT questions. This often leads to confusion and a disconnect to the greater goal of the organization.
An Agile Leader always asks himself if he has the right people on board, before he starts asking questions. So the order is WHO -> WHY -> HOW -> WHAT.
Only when this is the case, people will actually help to improve and work on the vision. It creates involvement, ownership and energy in the workplace.

Most organizations have a vision, but it only lives at the board and management levels.
Self-organizing teams can only be created by involving people to the company mission…and that will cost time and paying attention!

More info

This article was co-created with Jeroen Stoter, at ‘Nederlandse Spoorwegen’ (the Dutch Railways). If you have any questions based on this blog? Don’t hesitate to contact me or join my Professional Agile Leadership training.

Ron (info@roneringa.com)

Leadership Lessons from Extremely Successful Sports Teams

In this blog I will share a number of Leadership lessons from the World’s Greatest Sports Teams.
It is based on research that Sam Walker (founding editor of the The Wall Street Journal’s sports section) published in 2017 in his book: ‘The Captain Class’.

Finding Extremely Successful Teams

In the last 18 years I worked with many software and leadership teams. Every now and then these teams are awesome, highly energized and delivering high value products to their customers. However, most of them never get to taste this kind of success.

My gut feeling tells me that only 5% of these teams can be classified as extremely successful.
I felt a growing desire to answer two questions: “Can I measure how successful these teams are?” and “Can I find a pattern or magic formula that explains this success?”
Measuring the success of these teams is almost impossible, since in most cases my data is lacking, incomplete or the teams no longer exist.
Finding a pattern or formula is even more difficult without this measurement.
A little frustrated by this dilemma, I started looking for different ways to answer them.

A few months ago I was reading ‘The Captain Class’ by Sam Walker and I got really excited about his discovery!
As the founding editor of The Wall Street Journal’s sports section, Walker had access to a large amount of data on the most dominant sports teams in history.
From thousands of teams that ever won a title, he systematically eliminated those with some or incidental successes. He ended up with no more than 16 teams (which he called the Tier 1 teams), marked worldwide as the best sports teams that ever existed.On this Tier 1-list are teams like the New Zealand All Blacks, the New York Yankees, Barcelona’s football team and the Soviet Unions ice hockey team. All teams that dominated for at least 4 consecutive seasons, winning every worldwide recognized competition.
Walker’s research exposes some very interesting lessons about leadership and creating successful teams.

The Formula to Extreme Success

Once the most successful teams were identified, Walker started looking for a success-formula.
He researched all probable causes that could have made these teams so successful:

The presence of a superstar in the team
The level of overall talent in the team
The amount of financial resources
The quality of upper management \ institutional excellence
The impact of the team’s coach
The team cohesion

Walker could not point at either of them as the linking pin between all teams in Tier 1 (called the Alpha Lions).
While investigating the influence of individuals to the teams’ successes, he made an astonishing discovery:
For all 16 teams, 1 person’s presence overlapped precisely with the success period: the team captain.
After an extensive search to find more overlapping factors, the team captain was the only factor that connected all 16 teams in Tier 1.

So what kind of Leaders were these 16 team captains and what character traits separates them from their peers in Tier 2?

Seven traits of elite team captains

If we would summarise the character traits of a typical sports team captain like Michael Jordan the list would probably contain a combination of attractiveness, strength, talent, skill, charisma, charm and fair play.
However a thorough analysis of all 16 team captains in Tier 1 has led to different insights. Their character traits are in many cases the complete opposite of what you would expect.
In total, Walker discovered 7 character traits that made these captains so successful in leading their teams.

Trait 1: Extreme persistence and focus

Unlike you would expect, most of the captains in Tier 1 were not the most talented people in their team. On the contrary, they were often described as average or even lousy when they started their career.
Despite of their average skills, all captains possessed the will to keep pressing, until they achieved mastery. They all had a desire to play at their maximum capacity and to win at any cost.
This persistence in achieving results also had a positive influence on team members: it motivated team members to push harder.

Trait 2: Aggressive play that tests the limits of the rules

From a Leadership perspective we would expect a team captain to be a advocate of fair play, to set an example for the rest. However, the captains in Tier 1 were often pushing the frontiers of the rules.
Their actions weren’t always impulsive, but in some cases premeditated and intentional. They were acts of ‘instrumental hostility’ with no intention to injure or harm, but a determination to achieve a worthwhile goal.
These captains understood that sometimes you have to push the rules to the breaking point to win, without worrying how they were perceived by the public.

Trait 3: A willingness to do thankless jobs in the shadows

Many ‘Tier 1’-captains lived their career in the shadow of the stars. They were not the best athletes and had no interest in becoming famous. They had only one interest: winning.
Walker discovered that the most effective team leaders are those wo do (or arrange to get done) whatever is critical for the team to accomplish its purpose.
The great captains lowered themselves in relation to the group whenever possible, in order to earn the moral authority to drive them forward in tough moments.
According to Walker: “The easiest way to lead, it turns out, is to serve!”

Trait 4: A low-key, practical, and democratic communication style

We all know the image of the team leader, who calls his team together and motivates them when some impossible challenge needs to be faced.
The ‘Tier 1’-captains were not talented in giving motivational speeches. In fact, they avoided them.
Instead, they created a culture of continuous feedback, strengthened with sophisticated forms of body language (gestures, stares, touches, etc.).

Trait 5: Motivating others with passionate nonverbal displays

On top of a different communication style, most of the captains in Tier 1 had an intuition for showing non-verbal, positive aggressive displays.
One of the most famous displays of this phenomenon is a routine that the New Zealand All Blacks (the only ’Tier 1’-team with 2 bursts of success) were using: “The Haka”.
These gestures created deep powerful connections among team mates, releasing an energy that lead to amazing results.

Trait 6: Strong convictions and the courage to stand apart

All of the superior captains in Tier 1 had moments where they had to stand up to their superiors or break the rules, in order to improve or protect the team.
With the risk of being perceived as trouble makers or displeasing superiors, they all aimed to increase team dynamics and cohesion.
As great leaders they found themselves in the middle of conflict, holding a delicate balance.
They created moments of positive dissent that lead to more open discussions and improved their team’s capability of solving problems.
They also understood how to avoid moments of negative dissent that decreases trust, cohesion, commitment and performance.

Trait 7: Ironclad emotional control

The captains in Tier 1 all demonstrated an exceptional level of emotional resilience, that enabled them to overcome setbacks without being defeated from it.
Some of the captains where born with this ability and some developed it during their career, with patience and practice.
They developed a kill switch for negative emotions.

So, what can software teams learn from Sam Walker’s research?
And…if you are responsible for creating high performing teams, who do you select to be the team captain?

Leadership Lessons for creating High Performing Scrum Teams

The Scrum Master role has a lot of overlap with the team captains from Walker’s research.
Another overlap with Walker’s research is the role of the sports Coach: the Agile Leader, responsible for the Scrum Teams.
So, what lessons can Agile Leaders or Scrum Masters learn from these sports teams?

Lesson 1: Scrum Masters make the difference between Good and Great teams

Walker’s research proves that having an inside-Leader (or team captain) is the most important factor in making a team successful.
It wasn’t strategy, management, money or superstar talent that made the difference: 106 Teams had similar characteristics but all ended second place (the so called Tier 2 teams). It was the presence of a Leader, fighting on the battlefield with the team, who made the difference between good and great.

In Scrum, it is the Scrum Master role who has most overlap with the captains from Walker’s research.
In times of high pressure and when things get rough, the Scrum Master is the leader, working with the team from the trenches. For this reason he will have the most impact on the teams’ performance.
No coach, manager or process can help a team better in these circumstances than the Scrum Master.

Lesson 2: Agile Leaders enable Scrum Masters to Lead

Many Scrum Masters I encounter, only take up day to day routine tasks (such as hosting Scrum events and planning meetings), because their manager handles all leadership-related work.
The ‘Tier 1’-captains in Walker’s research proved that their Leadership was most effective, because they were part of the team. The duty of their coach was to create an environment that allowed this to happen.

An Agile Leader should help Scrum Masters to develop the character traits of a ‘Tier 1’-captain, so Scrum Masters can also become Agile Leaders. While some Scrum Masters might have a natural talent to Lead, some will develop these talents along the way. The challenge for the Agile Leader is to understand when to delegate these responsibilities, once the Scrum Master becomes more mature.

Alex Ferguson, the legendary coach of Manchester United once said: “As hard as I worked on my own leadership skills, and as much as I tried to influence every aspect of United’s success on the field, at kickoff on match day things moved beyond my control.”

Lesson 3: Scrum Masters are Servant Leaders

We have come to expect that the best leaders are often those with:

Exceptional talent
Mesmerizing characters
High market-value
Superstar ego’s

The evidence Walker presents (the best team captains are Servant Leaders), proves that this is a distorted picture.

Many Scrum implementations I have seen reflect that same distortion. We often think that Scrum Masters are highly technical super-heroes that follow orders from an even greater hero-leader. As a result Scrum Masters are often selected on their technical skills and their super-hero status.
The most effective Scrum Masters I encountered, had the character traits that Walker found in his research.

Walker’s research proves that Scrum Masters do not have to be superstar heroes with deep technical skills. Instead, they should be humble, have a relentless drive to learn and play to win. While doing this, they should support team members in growing and becoming technical experts.

Lesson 4: Agile Leaders are also Servant Leaders

Walker could not find any evidence that the sports coaches (the equivalent of the Agile Leader) of the ‘Tier 1’-teams had a direct impact on their success. With regard to the contribution of the coach, his research lead Walker to a number of conclusions:

the coaches were not prizewinning strategists
most were not inspirational figures
the coaches did not have a big impact on a player’s performance
changing coaches had no\low impact (many of the ‘Tier 1’- teams coaches came and left during the burst of success)
there were no real unifying principles\character traits like with the teams’ captains

What these coaches did have in common:

They gave their captains the room to be a leader for their team
They all enjoyed close and contentious relationships with their captains
They all had been decorated captains before moving to their management position

This allowed them to understand what makes a good captain and identify the perfect person to lead the players.

All coaches of the ‘Tier 1’-teams understood that to achieve great success, they needed a player on the field who could serve as their proxy.

The consequence of delegating Leadership to a Scrum Master is that the role of the traditional manager will change. The focus of an Agile Leader might be different, but the roles and required skills\character traits have a lot of resemblance.
True Agile Leaders are also Servant Leaders. They work closely together with the Scrum Masters and dare to step aside, once the game is on.

Lesson 5: Agile Leaders create a Learning Environment

Walker’s research shows us that being a great leader is not (always) genetically determined, it can be learned.
All ‘Tier 1’-captains started off with having early struggles in their captaincy. These struggles lead to a breakthrough moment that left no doubt about their desire to win.
As a result they focused, worked hard and pushed themselves and others to keep learning.
Coaches and managers of Agile teams need to create an environment where it’s safe to fail and where people get enough opportunity to learn from their mistakes.
It is the Scrum Masters job to show the team how to be persistent in reaching their goals and learn from their mistakes.

Lesson 6: Positive dissent is essential

Scrum uses closed feedback loops as a mechanism to continuously improve, eliminate waste and create incremental value.
All ‘Tier 1’-captains from Walker’s research understood that their teams needed positive dissent in order to make such a feedback loop work.
Like the captains in Tier 1, a Scrum Master needs to create an atmosphere in his team where conflicts are not driven by ego’s but by the will to win.
To achieve such an atmosphere, a Scrum Master needs to act on the edge of the status quo.
To be excellent, it is sometimes necessary to challenge existing processes, bad decisions or test the limits of existing rules.

Conclusion

One of the biggest struggles in becoming a true Agile Leader is to delegate responsibility.
Walker’s research shows that Leaders who are able to delegate these responsibilities to their Scrum Masters, create the most successful teams. If the Agile Leader and the Scrum Master work closely together, they can achieve amazing things!

Did you become curious to the role of the Agile leader? Come and experience it in my Professional Agile Leadership (PAL-E) training!

Leading Scrum Teams to maturity

How can an Agile Leader facilitate his teams to maturity?
In a series of 5 blog posts I am going to share some experiences.
In this blog I will introduce a maturity pattern that describes the evolution of a Scrum team.
This pattern is based on personal experiences and insights from Spiral Dynamics.
You can use this pattern as a benchmark for Leading Scrum teams towards more maturity.
As a followup I will present 4 blogs that each describe the transition between the described maturity levels.

If Scrum is done well…

If Scrum is done well, a Scrum team self-organizes, creates value on a regular basis and is highly efficient:

The Scrum Master serves the Scrum team and the Organization in understanding the theory, practices, rules and values. He helps team members to grow and coaches his peers towards success.
The Product Owner owns the Product, optimizes the value of the product and manages the Product Backlog. He helps team members to collaborate with stakeholders and creates a vision that is aligned to the stakeholders’ needs.
The Development Team owns the work and turns Product Backlog Items into valuable Increments. They are responsible for the quality of the product and have all the skills to organize their work.

If Scrum is done well, a lot of traditional responsibilities will move to the Scrum team.
For those new to Scrum it is often hard to believe that this transfer will ever take place. And to be honest, I don’t blame them!

Most organisations were not built on principles of self-organisation. They thrived in a time where management owned the plans and development teams owned only the execution.
But times are changing……The world has become so complex that responsibility needs to be owned by those doing the work. Only then can they be fast, flexible and creative.
And they can’t do that without the help of a Leader who shows them the way.

If Scrum is done well, you will need good Agile Leadership!

Leadership & Scrum

Many people understand Scrum nowadays, but fail in getting the best out of it.
This is often a result of:

Misinterpretations of the Scrum roles, their responsibilities and required skills
Organisational politics that prevent Leaders from focussing on what really matters
Having never seen a team transfer from ‘Following the rules’ to ‘Self-organising and shaping the rules’
Fear of loosing control and transfering autonomy

The idea of a self-organising team is fairly new the world of IT, but has proven most successful in sports and military situations. In the military there is a famous saying that states “There are no bad teams, only bad Leaders”.
And there is hope for IT organisations as well!
The best compliment a manager once made to one of my Scrum teams: “I don’t have to worry about you anymore. I just worry about the environment around it, so you can do what you have to.”
What if you could learn from what these teams did to accomplish this? What is the growth pattern that leads to such maturity?
And how can you as an Agile Leader use it to guide your teams to success?

A 5-Level Maturity Pattern

The key to leading successful Scrum teams is to focus on growing the maturity of the Scrum roles by providing them with an environment where they can flourish.
Many leaders focus on the processes and rules in Scrum, while it is the people and the roles that make the difference.

A team can only be as great as the people working in it!

I never met a mature Scrum Team that claimed its success to its ability to follow rules. The credits always go to the greatness of the people, the maturity of the roles and the values they share.
The most successful teams share a pattern, based on 4 important roles: the Scrum Master, Product Owner, Development Team member and Leader.
Although the Agile Leader is not an official role in Scrum, he plays a crucial part in the teams’ success in the organisation.

The pattern:

The Leader is responsible to set the boundary conditions for a Scrum team to increase their maturity.
I created a poster with detailed characteristics of each role on each level. You can download the poster here!

About the Maturity Pattern

The pattern is evolutionary

In my Scrum trainings I teach how Scrum is done well: on level 5 of the Maturity Pattern.
Most people have a hard time figuring out how to do that because they just arrived at level 1 or 2. I have never seen anyone jump to the highest level after finishing a training. You will have to walk the path trough all the levels. It requires hard work, perseverance and good Leadership to achieve level 5!
As an Agile Leader it is your responsibility to guide the Scrum roles from one level to the other.

Hard Structures determine Mindset

Successful Scrum teams act as autonomous cells within the boundaries of the organisation. This level-5 mindset cannot be accomplished when the organisations’ hard structures (mandate, processes, rules, buildings, organisations, KPI’s, etc) are still at level 1.
The way people think & act is determined by their working conditions. How each Scrum role acts and thinks on every level is determined by the hard structure provided by the Leader.
As an Agile Leader it is your responsibility to shape the hard structure of your organisation is such a way that people can make a shift in their thinking system.

Agile Leaders go first!

Many Scrum teams get stuck at the first 3 levels of the Maturity Pattern. All teams I observed at level 4 and 5 had one thing in common: their Leader supported and guided them there. Leaders need to create an environment where people can work with commitment and focus without fear of making mistakes.
If a Leader is not able to guide his team to the next level, there will be friction, wrong expectations and dysfunctional Scrum.
As an Agile Leader it is your responsibility to set an example and lead the way.

The weakest Link

The success of an entire team is determined by its least mature role. A Scrum team will only show the expected results on each level when all the roles are at least on the same level of maturity.
As an Agile Leader it is your responsibility to facilitate the growth of each role in a team in order to make the whole team grow.

How to use the pattern?

The pattern gives insights in how the Scrum roles become mature.

Warning: The pattern should be used as guidance to help people determine their personal growth path. Do not use it as an incentive, since it will prevent people from actually walking the path!

Training

If you want to experience what it takes to be an Agile Leader, you can sign up for my Scrum.org PAL-E training.

More info

Read more about the evolution of the evolution of the Scrum roles:
Evolution of the Scrum Master
Evolution of the Product Owner
Evolution of the Development Team
Evolution of the Agile Manager

Evolution of the Agile manager

How will the role of the manager change in an Agile organisation?
This is a question that keeps every manager busy when they start their Agile journey.
In this blog I describe the pattern of a changing management style. The behaviour is based on my observations when coaching the Agile manager.

The Pattern of an Agile Manager

A crucial part of an Agile transition is the mindset and acting of the manager.
Many managers have a hard time changing. Not because they don’t want to change, but mostly because the world around them isn’t ready for it.
Agile managers need teams to self-organise. Especially when it comes to operational, detailed, day to day activities. Daily, operational work is too complex to be involved in every detail.
However, self-organisation doesn’t just happen overnight!
Agile managers need to create an environment where people\teams organise themselves. Traditional management roles will evolve into leadership roles.
The pattern below describes 5 stages. In every stage the manager changes behaviour and lets go of an old behaviour.

Each of the stages has a relation to the maturity-level of the Scrum team. An Agile manager cannot grow when the Scrum Master, Product Owner and Development Team are not growing along.

The Director

The Director wants to be in control. He has a highly directive management style and tells people what to do; sometimes, even how to do it. The Director compares a Scrum team with a factory or an execution-machine.
The organisation is a top-down hierarchy. Plans are made at the top of the hierarchy. The Director makes sure that people below in the hierarchy (Product Owners included) focus on execution.The Director gives people individual targets to ensure efficiency, quality and responsibility for the outcome.
Profit and shareholder happiness are the main measurement for progress. Teams commit to time, scope and budget to make sure plans are executed.
Directors in a transition to the next stage have difficulties, since:

The whole organisation is so used to this management style that it is very hard to change it.
Targets are still efficiency\shareholder driven.
People in (Scrum) teams are not used to self-organise (although they might be open for it).
Teams aren’t stable enough to continuously learn and become self-organised.

The Influencer

Being a Director in a world with uncertainty and change is stressful. At some point he needs to delegate stuff to people he can trust. That’s the moment where Directors become Influencers. A Manager needs some maturity from the Scrum Masters, Product Owners and Development teams to make that shift.
The Influencer still has a need for control. He still makes the top-down plan and then tries to get buy-in on these plans.
Once he has buy-in, he delegates the less critical tasks. In this way the Influencer can focus on escalations and high important\long term decision making:

The Influencer delegates Planning execution to the Product Owner.
Product Owners have to provide frequent progress reports.
The Influencer imposes improvements on Scrum Masters by providing guidelines on processes and tools.
The Influencer ensures quality by setting up predefined standards for the teams.
He challenges teams to increase their velocity.
He adds extra resources if this is not possible.

As a result of delegating work, people will start to feel responsible for some of the work. The Influencer creates more room for self-organisation, but people still struggle to get in control.

The Facilitator

When Scrum Masters succeed in building good teams, standards and responsibility grows. An Influencer needs this to feel comfortable enough to delegate more work and responsibilities. Influencers turn into Facilitators when this happens.
The focus of the Facilitator shifts from staying in control\ensuring compliancy towards keeping employees and customers happy.
The Facilitator takes strategic decisions, but leaves the details to consensus and mutual agreement:

Planning decisions are an agreement between Product Owners, stakeholders and himself.
Product Owners become the spokesmen to customers and stakeholders.
He tracks progress by frequently visiting Sprint Reviews.
In Sprint Reviews he participates as stakeholder or helps stakeholders to make the right decisions.
He provides the boundary conditions for teams to setup their own quality-practices.
He uses velocity as an indicator for fixing issues instead of enforcing it to the team.

The directive management style of the Facilitator management has changed into a supportive approach.
People feel responsible and in control. They now want full control over their work.

The Advisor

Once the Facilitator dares to let go of critical decision making he becomes an Advisor.
In this stage he only gives advice. Decisions are made by the people doing the work:

Scrum Masters decide on the processes, tools and improvements to be made.
The Advisor consults or helps the Scrum Master in solving difficult problems.
Product Owners decide on product planning & stakeholder management. The Advisor has no need to be in between.
Instead, he facilitates interaction between Product Owners, Stakeholders and Development Team.
Development Teams are responsible for quality and how they do their work (using the Definition of Done)
The Advisor facilitates the Development Team to get the resources for building high quality products.

There is a big overlap in the work of a Scrum Master and an Advisor. While the Scrum Master is focussed on coaching the teams, Advisors coach the Scrum Masters and\or Product Owners.
Once in a while the Advisor inquires if decisions do not lead to issues. He is still responsible for budgeting, but leaves the decision making with the people doing the work.

The Servant Leader

Mature Scrum teams feel ownership for the full value chain. The Servant Leader feels safe enough to hand over full control to these teams. Instead, he has has a holarchical view on the organisation, while teams continuously improve on their own level in the holarchy.
This is what real self-organisation looks like:

Development team members are responsible for product quality.
The Servant Leader randomly samples if customers are satisfied with the quality.
Product Owners are responsible for budgets, profit and loss of their product.
Scrum Masters are responsible for continuous improvement of the team and the organisation.
The Servant Leader facilitates entrepreneurship at every employee.
He makes sure everyone in the organisation has focus on creating customer-value.
He focuses on capturing opportunities, solving problems and getting results.

The Servant Leader provides guidance, possibilities and resources for new\unexperienced people to grow as a professional.
The major responsibility of the Servant Leader is to prevent the environment from re-creating old paradigms. Employees need enough room for experimenting with the values in the Agile manifesto.

Tips for the Agile manager

Traditional managers have a hard time becoming Agile leaders since many organisations still run on old, top-down, directive paradigms.
A Servant Leader stands out by breaking through these political power-hierarchies.
A few tips if you are planning to walk this path yourself:

If you work in an organisation that is still based on these old paradigms, make sure that you are supported by ‘someone above’.
It is often easier to become a Servant Leader in a small organisation. If your organisation grows, make sure that new employees also become Servant Leaders.
Focus on growing people….You can’t do this alone! You need Product Owners, Scrum Masters and Development Team members to grow with you.

Training

If you want to experience what it takes to be an Agile Leader, you can sign up for my Scrum.org PAL-E training.

More info

Read more about the evolution of the evolution of the Scrum roles:
Evolution of the Scrum Master
Evolution of the Product Owner
Evolution of the Development Team

Some good books on the role of a Professional Agile Leader:

Our own book on Professional Agile Leadership
Good2Great – Jim Collins (no Agile book, but highly recommended for understanding level 5 leadership)
Creativity, Inc. – Ed Catmull (one of the best describe case studies on how to lead creative people)

Evolution of the Development Team

What are the characteristics of a good Development Team and how does a Development Team evolve when it is using Scrum?
In my previous two blogs I described the pattern of an evolving Scrum Master and a Product Owner.
This blog describes how a Development Team typically evolves.

10 Years ago I had the privilege to be a developer in a Scrum team. This was a real revelation for me: the atmosphere and the excitement were great and we were actually delivering valuable software! Now, 10 years later I am still infected by the Scrum virus. I see many teams going through that same excitement and it is still a joy to watch.
However, I see more teams that get stuck somewhere half the way, not reaching their full potential. For those teams I would like to present the gift of this blog that describes a pattern that most teams go through in their adoption of Scrum.

The pattern

People who were once part of a successful team will probably recognise that the path to succes is difficult. Many factors influence your team and its dynamics. It takes a lot of courage and resilience to walk this path. But despite of the effort and energy: once you’ve been there, you’ll never want to go back.
Some of the characteristics are software specific, but a large number of them could hold for any team that you work in (even if you don’t use Scrum).

Evolution stages of the Development Team

The pattern is incremental, where at each step in the evolution the expected benefits of the team grows. Each of the stages in the teams development is an upgrade of its predecessor and it contains all characteristics of the previous stages.

The Group

Group

All new teams start as a Group. In this early stage people are looking for stability, rest and a sense of belonging to the Group.
Team members are still discovering each other and their place in the team. As a result they have a wait-and-see attitude and do not show their true selves.
Team members are mostly focussed on themselves and committed to their personal goals. Each independent individual in the group has his own standards. These individual, personal standards determine if people respect each other.
Members of the Group typically join the Scrum-events, but they often let the Scrum Master guide them towards a result.
Each individual brings his own practices to the team and applies them himself. Forcing these practices to other team members feels overwhelming. Conflicts are felt internally but not expressed until they feel safe.
If there is a Definition of Done, it is mostly a collection of personal practices from the most experienced team members.
Within the Sprint each individual typically works on his own items. Once done, he/she picks up stuff that is in his area of expertise.

The Storm

Storm

Once people feel safe in the Group, they will start looking for a common understanding. In the presence of safety, members gradually open up towards each other. Although opening up, people only trust themselves. They start to learn on how to become accountable to each other.
As a result of being more open, people start to learn their differences, disagree and conflicts will appear. Resolving conflicts means letting go of old dogmas:
* When dogmas disappear, respect is earned. Multiple opinions can lead to new insights about each other.
* When dogmas stay, people will try to convince others to start using ‘their’ practices. Their quest for influence could lead to personality clashes, more conflict, losing respect and people closing again.
The feeling of security and safety will either increase or go down after people had their first conflicts.
Now that people know each others standards, they start to form an opinion about the best standards. A first mutual ‘Definition of Done’ appears on paper. This DOD is often not actively used because people still struggle to adopt the newly gained insights.
Since there is no common understanding\goal yet people find it hard to commit to a sprint goal.

The Team

Team

A Team will emerge when individual members can overcome their personal differences. Conflict, egos & dogmas make place for new insights and finding common ground. This common ground leads to shared goals, more clarity and focus in a Team.
Goals and standards are becoming clear and they get captured.
Success is actually measured and commitment gradually grows with it. Some of the Development Team members start showing real accountability.
Mutual respect and trust is being earned on a daily basis. The increased safety leads to a need for more intimate relationships & friendships. Team members start sharing personal stuff and take part in regular social events. A Team starts admitting mistakes and learns from these mistakes.
The team has had a number of conflicts. Conflicts are therefore considered unwanted and members try to avoid them. Teams want the stabilisation to complete, so members are sometimes afraid to share the more controversial ideas.
Practices like Pair Programming, TDD & CI move from a personal to a team practice.
Retrospectives become a place where people don’t only complain but actually discuss improvements and new standards. The Definition of Done is now actually used on a regular basis by each team member. In the Daily Scrum, people ask for help and offer help to their peers.

The Family

Family

In a Family there is respect for each member of our Development Team. We have learned to overcome our differences and trust is the basis of everything we do.
In a Family we see a rise of constructive conflict; members are carefully mentioning conflicts in order to become better in everything they do.
Every member of the Family is committed and accountable. People are starting to develop accountability at the team level as well. Sprint goals are set during the Sprint planning and team members dare to speak up when the Sprint goal is under pressure.
KPI’s are not only ‘management porn’, but they are really driven by team behaviour (“we make sure we finish what we agreed”). Team members measure their performance and improve KPI’s in order to be more in control. The first, real tangible results appear in the form of frequent value delivery.
The events are running smoothly now. Every team member knows the purpose of each Scrum event and the Scrum Master does not need to point this out anymore.
Successes lead to an increase of people’s self-esteem and drive for accomplishment. People become more motivated, knowledgable and competent. Team members regularly visit events and go outside to learn new practices and share knowledge.
A few Development Team members are showing autonomous behaviour, they make decisions without a need for supervision. More and more intuitive decision making, based on experience is allowed. People also allow more dissent, because they see that a variety of opinions lead to more options and better solutions.
Multiple disciplines in the team start taking over each others work, because they value reaching Sprint goals above working on their own discipline. Techniques like swarming (team members collectively finish ongoing tasks before moving to new tasks) and team-wide pair-programming appear.
Continuous Delivery and Continuous Integration are becoming default team standards. The team starts experimenting with team-wide sharing of practices and new, improved standards. The Definition of Done is continuously used, challenged and updated if necessary. It is ok to make mistakes, as long as people learn from it.

The Wolfpack

Wolfpack

Living in a Family already felt great, but once you are in a Wolfpack you will experience what an awesome Development Team is all about. Team members in a Wolfpack are courageous, they stand out from the crowd. They dare to be different and swim against the tide.
Instead of living by the rules, people in the Wolfpack make the rules; they continuously determine new practices or refine existing ones. Team members teach each other, but also people outside the team about good practices and what works well. The Definition of Done might be on paper, but the Wolfpack doesn’t need paper: good practices are in each individuals mind all the time.
New work is being delivered to the archive a few times a day and with one press of a button the team is able to deliver high quality, valuable functionality to the customer.
There is no more fear for conflict and people demand debate. There is accountability and a willingness to continuously confront each other with difficult issues. Team members trust each other blindly and respect is in the DNA of each team member.
Mistakes are mandatory and when they are made, they are celebrated. There is no greater good than continuous learning, creativity and achieving one’s full potential.
People in a Wolfpack are highly knowledgable and autonomous. Dissent is expected, because that is what you need to become better.
Each event has a clear outcome and the rules of engagement are in the minds of everyone. Almost every Sprint the team reaches their goals and sometimes they exceed expectations. Beside a clear goal, the Wolfpack has a vision for the future. They help their customers become more successful.

Conclusion

Now you’ve seen the evolutionary pattern of a Development Team, see where your team is. Figure out what steps to make and be aware that it is no shame to be in a Group or a Storm: every Family & Wolfpack has gone through these phases. A good Scrum Master will understand that teams need to go through these phases. However, avoid getting stuck in the early phases, because this is a reason why many teams do not succeed or even dissolve over time.
Creating a Wolfpack is a tough job and a rewarding one and maintaining a Wolfpack is even harder, since teams are continuously challenged with outside influences!

More info

Read my other blogs in this series:

Some good books on the role of the Professional Scrum Master and Professional Scrum:

Evolution of the Scrum Master

In my last post I explained the pattern of an evolving Product Owner. This blog is about the evolution pattern of a Scrum Master.
Do you want to know more about what it takes to be a good Scrum Master and how to grow in your role? You should propably keep reading.

Succesfull Scrum

In the last 10 years I have helped a number of organizations to implement Scrum.
For a lot of these organizations the Scrum implementation either takes a long time or they never reach the real benefits of Scrum (happy stakeholders & maximum valued products with high quality).
There is a close relation between the progress\success of the Scrum implementation and the maturity of the Scrum Master role.

The pattern

So who is the perfect person for this role? Is it a (project) manager, a team leader or maybe one of the development team members? Should he have technical skills or is he more a people manager?
The answers to these questions are not simple. These answers are hidden in the way many of these organizations have implemented the Scrum Master role. Another pattern appears, that describes the evolution of the Scrum Master:

The more mature the Scrum Master becomes, the higher the expected benefits. Each of the versions in the graph is an upgrade of its predecessor and incorporates all qualities of the previous version:

The Clerk

As a first attempt of implementing the Scrum Master role, organizations often start with one of the members of the development team (maybe he used to be the ‘team leader’). Since he has proven to be good in organizing stuff, we think that this guy can easily pick up some extra tasks (‘how hard can it be to be a Scrum Master, right?’). While his main responsibility is operational work on the Sprint Backlog, beeing a Scrum Master is something he does in spare time.
On a day to day basis the Clerk typically removes a lot of administrative duties from the Development Team (like updating the Sprint Backlog, burndown graphs, preparing the Sprint Planning, etc).
A Clerk has limited benefits, since he is mostly focussed on himself & the inferior values of the Agile manifesto (tools, processes, documentation, etc).

The Puppet Master

The Puppet Master is aware on the values in the manifesto (working software, collaboration, interaction & embracing change). He understands how the mechanisms in Scrum can help him reach these values.
He tries to pull different strings to make team members move into the right direction: everyone in the team needs to follow the Scrum rules by the book. This often results in a very mechanical Scrum implementation, where people do all the events, roles & artifacts in Scrum, but not really live them.
Since he still supports the team in doing technical work, a Puppet Master often does not have the time to focus on anything but his own Development Team.

The Organizer

Compared to the Clerk and the Puppet Master, the Organizer has managed to make his team aware of the Scrum Values (Commitment, Focus, Openness, Respect & Courage). He has realized that by doing all the complex technical work himself, he actually prevents his team to learn (there is no need for other heroes when you already have Superman).
So instead of beeing Superman, he steps aside. He facilitates that the team can do it themselves (‘We don’t need strings to make the puppets move!’). As a result he can focus on teaching people about Scrum. He makes sure they actually live the values.
The Organizer is focussed on making sure that all Scrum events have an optimal result. He also has made time to provide data, so people can start acting on facts instead of gut feeling.
Although the Organizer himself acts with the Scrum Values in mind, his team is still learning. They still need his full attention.

The Coach

A Development team that works with a Coach is able to run Scrum themselves. Sometimes still a little mechanical, but most of the times they really start living the values. As a result he has enough room to also focus on the Product Owner and the environment around the team (stakeholders, management, etc).
The Coach is able to impact others with his knowledge, while the Organizer only used this knowledge himself. He doesn’t only listen to his own voice. He is able to empathically listen to others. He is able to make people connect to their passion and helps them take action towards this passion. He helps people to find new viewpoints and evolve.
Besides using data to take decisions, the Coach starts to listen to his intuition.
The focus of a Coach gradually shifts from the team towards the rest of the organization. However, he still struggles to find solid ground with management and other parts of the organization (marketing, sales, operations, you name it…).

The Advisor

The Advisor has acted as a Coach for more teams in the past. He succeeded in creating\enabling empowered Scrum teams. As a result of that his focus has now shifted towards the organisation. He fixes impediments on the organizational level. He uses data, but he mostly acts on intuition.
The Advisor helps new Scrum Masters with a lower evolution level to grow. He is often asked by managers to help them fix difficult issues.
In an organization with complex, large products, the Advisor is typically the Scrum Master for a number of scaled Scrum teams (in a Nexus he might also be the Scrum Master for the integration team).
While he learns a lot about the organizational dynamics the Advisor still struggles in making organizations more responsive as a whole.

The Expert

The Expert Scrum Master is highly competent & committed. He uses his unconscious competence and intuition to advise\coach others on making decisions. The Expert has a connection with all parts of the organization. He gives advice to managers, HR professionals. He leads the organization towards more Agility. The Expert helps creating new rules & standards.
Some of the Experts are still part of a Scrum team, because they love the atmosphere around there. These teams are often high performing, skilled and an example for the other teams in the organization.
Experts in an Agile organization often call themselves ‘Agile coach’. They show up at events and are often respectable members in a community of Experts.
Unfortunately, many organizations do not recognize these Experts or don’t understand how to keep them motivated. If they eventually leave, it will be a hard job to fill the vacuum they leave behind.

Training

If you want to experience what it takes to be a good Scrum Master, you can sign up for my Scrum.org PSM training.

More info

Read my other blogs in this series:

Some good books on the role of the Professional Scrum Master and Professional Scrum:

Evolution of the Product Owner

What is a good Product Owner and am I the right person to fill in this role?
If you have ever struggled with this question, you should probably keep reading.

The advantage of being a trainer and a consultant at the same time is that you get the chance to meet a lot of Product Owners. I hear the stories of Product Owners struggling with their daily challenges. Sometimes these stories are beautiful & inspiring, but mostly they look like an episode of ‘House of Cards’ (meaning it’s ugly and full of politics and tough decision making).
Looking at all these stories you can see an evolutionary pattern appear, describing how a Product Owner grows in his role.

The pattern

Many Scrum minded organisations are trying to create a good implementation of the Product Owner. But where do you start? What is the right person to fill in the role of the Product Owner? Does he come from marketing, sales or maybe from the IT department? Or maybe it’s that perfect project or product manager? All these questions will popup, once you start implementing Scrum. The answer to this question is not that simple. It is hidden in the evolutionary pattern, that describes how many organizations have implemented the role of the Product Owner.
The pattern describes the required ‘features’ of a Product Owner. It’s an incremental pattern, where at each step in the evolution the expected benefits of the role grows. It’s like a Russian nesting doll that becomes more beautiful and richer the more it grows.

Five levels

The evolutionary pattern contains 5 levels of Product Owners that I encountered. These levels can be described by a graph that we use in the Professional Product Owner training:

Each of the PO-versions in the graph is an upgrade of its predecessor:

The Scribe

As a first attempt of implementing the Product Owner role, organizations often start with someone who has strong analytic skills. This is often a member of the Development Team that was used to writing requirement specs or someone who used to be the ‘Business Analyst’. Since this person typically comes from the IT department, it is an easy to take first step towards implementing Scrum and we can get started with the creation of a Product Backlog.
However, a Scribe has limited benefits, since he often needs others (marketing, sales, product/project managers, steering committees, etc) to answer difficult questions. This delegated decision making often leads to a disruption of the flow, bottlenecks, large piles of stocked work and a slow generation of business value.

The Proxy

In order to solve the communication problems of a Scribe, organizations update the Product Owner role with a senior analyst that has strong communication skills. This person is like an account manager that is mostly still coming from the IT department. The focus of a Proxy shifts from creating Product Backlog items towards creating Product Increments.
The expected benefits of a Proxy are slightly better, since he is more connected to the business than the Scribe. Although the delays, waiting time and hick-ups will decrease, many of those remain.

The Business Representative

A problem that is often heard with the Proxy (and also the Scribe) is that the business (often marketing & sales) is disconnected from the IT department. Once organizations understand that they need to break down the inter-departmental barriers, they send in someone from marketing/sales/product management to fill in the Product Owner role. This upgrade to Business Representative is the next step in the evolution. From this moment on the Scrum team consists of people from all parts of the organization, and not only from the IT department.
The expected benefits increase again, since there is a broader collaboration. Now there is direct availability of functional knowledge & stakeholder expectations. Yet, the Business Representative still has limited autonomy, since marketing\sales\product management department are still the real authorities.

The Sponsor

Once a Business Representative has felt the pain of continuously asking the business departments to make decisions, he will probably fight to get some mandate. Once the business departments dare to give control to and trust the Business Representative, the next step in the evolution is made and the Business Representative is upgraded to a Sponsor.
It works better if the person is not only from business, but also has the trust and the mandate to take decisions (on the spot). A mandate is a signal that the role is taken more seriously. The Sponsor is often allowed to spend more time as a Product Owner, leading to less hick-ups, context\task switching & largely improved flow. The Development Team can focus more, and get things done.
The issues of a Sponsor mostly come down to a need for lobbying for budget. A sponsor still needs to negotiate to free up money from the different business departments. Maybe he can already decide on how to spend the money for his own department, but there are still other departments that need to be convinced.

The Entrepreneur

The last step in the evolution of the Product Owner is to make him fully responsible for functionality and budgets. This makes him a real Entrepreneur, whose job is to create as much Business Value for his customers as possible. He’s like a mini-CEO, a real owner over the product.
The Entrepreneur is responsible for all aspects, like marketing, competition, users, legal & finance within the scope of his product. His professional life is dedicated to the well-being of the product.
Unfortunately, these kind of Product Owners are still a rare species, since organizations are often not ready to delegate this kind of control.

Training

If you want to experience what it takes to be a good Product Owner, you can sign up for my Scrum.org PSPO training.

Professional Scrum Product Ownwer

More info

Read my other blogs in this series:

Some good books on the role of the Professional Product Owner and Professional Scrum: