Evolution of the Agile manager

ByRon Eringa, 12 Jun 2017
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.

Agile manager

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

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

Director
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

Director
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

Director
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

Director
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.

More info

Read my other blogs in this series:

Looking for more reads\background information on this topic:

Evolution of the Development Team

ByRon Eringa, 14 Dec 2016
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 development team

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:

Evolution of the Scrum Master

ByRon Eringa, 29 Jun 2016
evolution 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:
evolution 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

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

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

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

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

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

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.

More info

Read my other blogs in this series:

Would you like to join my Professional Scrum Master trainings? You can register here!
If you would like to use the personas described in a workshop, you can download them here.

Want to know about the evolution of the developer, development team and the Agile manager? Keep reading the upcoming blog posts, there is more to come!!

Evolution of the Product Owner

ByRon Eringa, 12 Jun 2016
Evolution 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 beeing 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

evolution product owner
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:
expected benefits product owner

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

The Scribe

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

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

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

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

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.

More info

Read my other blogs in this series:

Do you want to learn more on the characteristics of a good Product Owner? Have a look at these blog posts.
Would you like to join my Product Owner trainings? You can register here!
If you would like to use the personas described in a workshop, you can download them here.