Our scrum team are battling to self-organise. How do I help them?
What you need to do is understand the concept of self-organisation itself. Many people push back against the concept of self-organisation because they don’t really understand what we mean by self-organising teams.
Self-organisation is about the teams deciding how to solve problems. They get to decide what the solution looks like. They don’t get to decide what problems they are solving because they aren’t self- governing.
In the agile world we use to talk about self-organising and now we refer to it a self-managing teams, but really, we are speaking about the same thing.
A team who decides how to solve a problem that the organisation, via a product owner if you are doing scrum, places in front of them.
Some people don’t like it because it is scary. They are used to being told how to do their job. Some people don’t like it because they feel that they should own the problem as well and decide what to work on, and you need to approach these in different ways.
Owning the problem and deciding what to work on
So, for those who feel that they should be owning the problem and deciding what to work on, that’s ok, it is called self-governing and it is a perfectly reasonable approach.
Are you working in an organisation that is willing to dedicate that authority to you. Willing to allow you, as a team, to determine which problems are the most compelling to solve and to decide how you are going to approach and solve that specific problem.
Are you working in an environment that empowers you to choose which products and features need to be built and in what order those products and services should be built?
If so, great, you simply need to work with stakeholders such as customers, product owners and business analysts to work out which of the problems are the most urgent and to align the team’s efforts with organisational goals and objectives.
Within that framework, you can determine what the problem is and how best to move forward.
In my experience, this is not going to happen.
What we need to do is help the team to understand that self-governing teams are incredibly rare and remind them that agile frameworks, especially scrum, is about empowering the team to work in the style that best serves them but ultimately, it is the product owner and customer that are being served by the work they do.
It is the customer who decides what problems are the most compelling and which products are the most valuable to them, not the team.
The team can want to own the problem and take control of the entire process, that is great to see that level of ownership and commitment from the team, but it isn’t a valuable way to work for the organisation, the customer and the product stakeholders.
As a scrum master and agile coach, we need to help the team understand that they can’t and won’t be given that level of authority. Help them to understand the boundaries between what they can and can’t do.
Very often, all that requires is an honest and open conversation with the team, and no more.
Having a conversation with the team and the stakeholders in the room allows you to discuss what the team would love and what the stakeholders are willing to give. It becomes a negotiation and as an honest and open discussion, both stakeholders and the team are informed by the discussions.
It allows us to talk about what good looks like for this team, in their specific context.
It isn’t an easy conversation to have but it is incredibly important that you do have the conversation.
In fact, it is so important, it is one of the first things I recommend you do when you first form a team. Help them understand where the boundaries lie and what a great working relationship with product owners, product stakeholders and customers look like.
Introducing the concept of self-management to a team
The other group that I come across are individuals who simply don’t understand the concept of self-management and organisation.
They want to be told how to solve the problem or build the product.
Maybe, they come from organisations where traditional line managers decide how the team are going to solve a problem and assign work or tasks to each individual on the team. Very much like a project manager delegating work within a traditional project management environment.
This is a hard place to find yourself as a scrum master or agile coach, but it is very common, especially when companies make the decision to transition to more agile styles of working or adoption of a formal agile framework.
What we need to do is help the individuals on the team understand that they, as a team, can make decisions.
This is about safety. Psychological safety and helping the team understand that they have job security despite the presence of tough conversations, challenging assumptions, and deciding on the best approach to solving a problem or building a new feature.
Often, the people on these teams have learned that making decisions is dangerous. Pushing back on an instruction or task that is assigned to them has severe consequences. They have learned to accept what is assigned and to execute against the order that has given rather than attempt to solve the problem using their own creativity, initiative and collaboration capabilities.
In the early days of an agile adoption, these are the most common problems we face as a scrum master or agile coach.
Individuals who will not step outside of their comfort zone or explore how they could best solve a problem, based on their own expertise and experience.
They come from environments where project managers, line managers, and stakeholders have been telling them what tasks to do, when to do it, and how to do it regardless of whether those people are best placed to know the answer or provide the recommendations they do.
These people have learned that success, in their career, is to keep silent and do as they are told, when they are told.
So, with these teams, we need to give them a bit of a cuddle and handle them, initially, with velvet gloves. We need to nurture them and cultivate psychological safety within the team.
We need to work with product owners, product stakeholders and leaders within the organisation to help them understand the value of agile principles and values, the importance of psychological safety for the team, and the value in allowing the experts to make decisions during the product development process.
We need to build the team up, grow their confidence and reinforce that they are in a safe environment that values their expertise, creativity and problem-solving capabilities.
We need to help the team have good, honest and open conversations about what the problem they are solving is and how best to solve that problem. Help them to understand why they are building a new feature or product and what the purpose of that new product or feature is.
Help them understand why it is valuable to customers and how it aligns with the product goal.
In the early days, individuals are going to go to third parties for direction and guidance but as you grow the team and they mature as a team, you will find that the concept of self-management becomes more appealing and almost second nature to the team.
Acknowledge that individuals on the team are going to third parties for assistance and direction, don’t ignore it, just acknowledge it and help the team refocus on the concept of making decisions internally and taking action that aligns with what the team have decided is the best approach.
Slowly, their confidence will grow and as they begin to deliver great work, more consistently, they will embrace the opportunities and benefits that come with self-organisation and begin to build momentum as a team.
You are also going to have conversations with people outside of the team to help them understand how they can best support the new team. Help them understand what Agile looks like and how their contributions can help the team become more independent and autonomous.
You will also be having those conversations with leaders and executive teams.
So, in closing, there are a number of ways you can help a team become more self-managing and it requires that you teach, coach and mentor the team through the process.
If you like the idea of becoming an agile coach and would value mentored, coach-driven skills development, visit our Agile Coach Academy.
If you like the idea of becoming a scrum master, visit our Certified Scrum Master course.
If you are already a scrum master and want to upskill, visit our Advanced Certified Scrum Master course.
If you have several years’ experience as a scrum master and want to both validate and certify your professional skills, visit our Certified Scrum Professional Scrum Master course page.
For more information on John McFadyen, visit https://www.johnmcfadyen.com or connect with John on LinkedIn at https://www.linkedin.com/in/johnmcfadyen/
#agile #scrum #scrummaster #agilecoach #agileprojectmanagement #selfmanagingteams #selforganisingteams #teamwork #scrumteam #agileleadership