The biggest
flaw in how teams adopt Scrum might be the “protect the team” mentality. It can
prevent teams and organizations from reaching their true high performing
potential.
At the same time,
there are very valid reasons why the “protect the team”-mentality happens in
the first place, and these issues need to be addressed.
This
combination makes “protect the team” a very
interesting topic!
The different aspects of protecting the team are:
- protect the team from others
- to protect the team from itself
- and finally the need to stop protecting the team!
Let us
explore in more details each of these different situations:
This is the obvious one. Many teams struggle to be able to get the peace and time to actually do their work. I have seen months and years of waste due to constant reprioritization, stakeholders directly poking team members, too many stakeholders, silo oriented organization, big up front design, big up front detailed specification (that turn out to be all wrong), constant changes in team composition to name some.
The answer is to find the right balance: a development process based on few and simple principles, which create a heartbeat and fits the organisation’s needs. The most common improvements in order to help to protect the team from “outsiders” have I found to be:
- Train organisation to commit to sprint goals
- How? By repeatedly ask the question: can this wait two weeks?
- What: Prevents random disturbances and constant reprioritizing
- Reduces work in progress
To see issues that can not wait until next sprint is rare. I have yet to see it, even in teams that are responsible for systems in production for millions of users. If this is an issue, the first remedy to try is start having shorter sprint. The point of keeping focus within the sprint is essential.
- Use the backlog:
- If it is not in the backlog it will not be done
- How? By having a simple process that works on grooming the backlog (get the right items in, prioritize it right, and reduce the number of items, not include too much details in the stories except the ones for the current and next sprint)
- Help on basic meeting hygiene
- How? Start with being explicit about the purpose of every meeting and stick to it. Keep a parking lot for everything else. (rather than having a shared parking lot, it is often better that meeting participants write down follow up items for themselves in order not to bring everyone’s attention to side track items)
- Reduce the need for handover
- Typical symptom: people from other departments bugging the team with requirements and needs. Why does the team feel this as “bugging”? Because it is “out of scope”. Should it be out of scope? Probably not. The solution then is to get the right skillset into the team. The people with their hands dirty are the ones that needs to have the skills and knowledge to solve what they need in order to deliver something potentially shippable
2) Protect the team from itself
This might be less obvious, but still common and important:
- Starting on important but “random” work that is not part of the sprint goal
- What: the team starts to pick random items of the backlog to start working on, or start working on technical items of their mind
- This can be a symptom that technical items are not prioritized. The solution is to train the team and product owner to add technical items as part of the regular system development process. Then the team has their say in an amount of time that makes sense to them and the rest of the organization. I have often seen approximately 20% of the total time, but this varies a lot based on the situation.
- This can also be a symptom that the team does not know the business goals, the customer or domain very well. The solution can be to use lean startup techniques and get the customers closer into the development process.
- Need training to take unconditional responsibility
- This is a chicken-and-egg issue: teams that take responsibility get trust from the rest of the organization, organizations that lack trust are preventing teams from taking responsibility
- Culture changes are more in depth reaching than anything else. This is about a culture of taking responsibility to make the best out of any situation –difficult or not
- Team members need to have the confidence that they know the best how to do their work
- The best way for a team to gain trust from the organization is by transparency and continuous delivery of stories that are ready for production.
- Many teams need training on taking responsibility for the whole team and sprint goal delivery, and not optimizing for individual team members and hand over within the team.
- Gold plating: being afraid of early releasing
- Over and over I have seen how difficult it is to let go of our baby. Even when it comes to internal releases. This might be a matter of habit and mindset. As an agile coach, I spend much of my time in helping teams to get to the point where they want to deliver on a frequent regular basis.
- Start getting used to the feeling of being “not ready”. Software is never going to be completed anyway
3) Stop
protecting the team
When you are mastering the workflow so that you do not have any big issues related to 1 and 2, then it is time to grow further:
- Optimize the whole
- Shielding the team from the rest of the organization is optimizing for a too low level. It is time to facilitate for optimizing for the whole looking at the bigger picture
- Keep shortening the feedback loop and keep involving more of the customer journey into the software development process
- Be aware of complacency
- A high performing team that has worked hard and now sees the results from their agile approach might fall into the trap of thinking they know it all
- The solution is to focus on continuous improvement and learning, also from the rest of the organization and from the customers
- Address the root cause of organizational issues
- Protecting the team from outsiders is a short-term solution to organizational flaws. In order to get a high performing organization, we need to find and solve the true cause of these pain points
This is my take on "protect the team". What is your experience?
