Ron Eringa

The Agile Culture gap is the nr. 1 cause for immature Agile implementations. You should read this blog if you want to understand how culture affects Agile transformation.

This is the last in a series of 3 blogs presenting the result of an interesting research study from Sam Walker.  Walker discovered that the most successful sports teams that ever existed all shared one single element: They all had a team captain with 7 overlapping traits that made them extremely successful.

What can a Scrum team learn from the World’s Greatest Sports Teams? In this the second of 3 blogs I'm sharing the character traits of an Elite Team Captain.

What can a Scrum team learn from the World’s Greatest Sports Teams? This is the first in 3 blogs that will share a number of Leadership lessons that can be used to build high performing Scrum teams.

What can you do as a Leader to help your Scrum Teams to become mature? Discover a 5-level maturity pattern that you can use as a reference.

What is the difference between a traditional and an Agile Manager? Keep reading, if you want to learn how a manager evolves.

Development Team was removed from the Scrum Guide in the 2020 release. However, the ideas expressed in this blog still provide value when understanding the dynamics of the Scrum 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 recognize that the path to success is difficult. Many factors influence your team and its dynamics. It takes a lot of courage and resilience to walk this path. But despite 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 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 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 A real 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 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 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. 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 Evolution of the Product Owner

In my last post, I explained the pattern of the evolution of the 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? Would you like to know how to grow in your role? Then you should probably keep reading. Successful 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 relationship between the speed & 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 Scrum Team members? Should they have technical skills or be more of a people manager? The answer to these questions is 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 at implementing the Scrum Master role, organizations often start with one of the members of the Scrum Team (maybe he used to be the 'team leader'). Since they have proven to be good at organizing stuff, we think that this person can easily pick up some extra tasks ('how hard can it be to be a Scrum Master, right?'). While their main responsibility is operational work on the Sprint Backlog, being a Scrum Master is something they do in their spare time. On a day to day basis, the Clerk typically removes a lot of administrative duties from the Developers (like updating the Sprint Backlog, burndown graphs, preparing the Sprint Planning, etc). A Clerk has limited benefits since they are mostly focussed on themselves & the inferior values of the Agile manifesto (tools, processes, documentation, etc). The Puppet Master The Puppet Master is aware of the values in the manifesto (working software, collaboration, interaction & embracing change). They understand how the mechanisms in Scrum can help with reaching these values. They try to pull different strings to make team members move in 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 this sort of Scrum Master still supports the team in doing technical work, a Puppet Master often does not have the time to focus on anything but their own Scrum Team. The Organizer Compared to the Clerk & the Puppet Master, the Organizer has managed to make their team aware of the Scrum Values (Commitment, Focus, Openness, Respect & Courage). They has realized that by doing all the complex technical work themselves, they actually prevent the team from learning (there is no need for other heroes when you already have Superman). So instead of being Superman, they step aside. He/she facilitates that the team can do it themselves ('We don't need strings to make the puppets move!'). As a result, this type of Scrum Master can focus on teaching people about Scrum. They make sure they actually live the values. The Organizer is focused on making sure that all Scrum events have an optimal result. They also make time to provide data, so people can start acting on facts instead of gut feeling. Although the Organizer acts with the Scrum Values in mind, their team is still learning. The team still needs the Scrum Master's full attention. The Coach A Scrum Team that works with a Coach is able to run Scrum themselves. Sometimes still a little mechanical, but most of the time they really start living the values. As a result, the Scrum Master 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 their knowledge, while the Organizer only used this knowledge themselves. He/she doesn't only listen to their own voice. They are able to empathically listen to others. They are able to make people connect to their passion and take action towards that goal. He/she helps people to find new viewpoints & evolve. Besides using data to make decisions, the Coach starts to listen to their intuition. The focus of a Coach gradually shifts from the team towards the rest of the organization. However, they still struggle to find solid ground with management & 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. They succeeded in creating\enabling empowered Scrum Teams. As a result their focus has now shifted towards the organisation. They fixe impediments on the organizational level. They use data, but mostly they act on intuition. The Advisor helps new Scrum Masters with a lower evolution level to grow. They are 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 they might also be the Scrum Master for the Nexus Integration Team). While they learn 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. They use their unconscious competence and intuition to advise\coach others on making decisions. The Expert has a connection with all parts of the organization. They give advice to managers and HR professionals. They lead the organization towards agility. The Expert helps in creating new rules & standards. Some of the Experts are still part of a Scrum Team, because they love the atmosphere of being part of a team. 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 coaches'. They show up at events and are often respectable members of 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. 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, Product Owner and the Agile manager? Keep reading the upcoming blog posts, there is more to come!!

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? Who is the right person to fill in the role of the Product Owner? Do they come from marketing, sales or maybe from the IT department? Or maybe it's that perfect project or product manager? All these questions will pop up, once you start implementing Scrum. The answer to this question is not that simple. It is hidden in the evolution 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 evolution 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 Scrum 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 easy to take the first step towards implementing Scrum and we can get started with the creation of a Product Backlog. However, a Scribe has limited benefits, since they often need 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 still coming from the IT department. The focus of a Proxy shift from creating Product Backlog items towards creating Product Increments. The expected benefits of a Proxy are slightly better since they are 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 a 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 is still the real authority. The Sponsor Once a Business Representative has felt the pain of continuously asking the business departments to make decisions, they 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 the 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 fewer hick-ups, context\task switching & largely improved flow. The Developers can focus more, and get things done. The issues of a Sponsor mostly come down to a need for lobbying for a 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. They are 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, this kind of Product Owner is still a rare species, since organizations are often not ready to delegate this kind of control. If you would like to use the personas described in a workshop, you can download them here.