“Protect the team” is a double-edged sword

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:

1) Protect the team from others

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?

How to optimize the whole: Do you know your customer journey?

Lean has been essential to many successful businesses for decades. It is a learning experience, and in this post, I will show you how I have come to discover more and more what the lean principle “optimize the whole” means:

 

 

2003:  Optimize the whole = Optimize project deliveries

I started out thinking it was much to gain by optimizing the project delivery process. We focused on how we could deliver software that was tested and that fulfilled the requirements from operations -doing it as effective and as fast as possible. 

Handover - Tableatny @ Flickr

2007: Optimize the whole = Optimize the sw life cycle

Around 2007 I realized that we had so much more to gain by optimizing the whole development life cycle: from idea via concept, implementation, testing, installation in production, upgrading and rollback. (yes, moving away from waterfall.)

It was popular to start using more agile development approaches, Scrum and Kanban. I got to work in agile teams; the concept phase, implementation, test and deployment happens within short sprints, even in some large organizations. This is a great improvement, and it is a delivery thing. Getting the software out there, in order to be used, not stored, being able to focus on the features that are actually used! and getting better and better at devilvering the right features. Fantastic!

What a great difference!!

2012: Optimize the whole = optimize the customer journey

What if you are great at producing the right features and great at deploying it easily to production, but the customer never get to hear about the product in the first place? Or the customer is not able to get started? Or it is almost impossible to buy the product?  

I learned that the whole customer journey was what really matter to the customer. To me, this is the next step if you are into advanced lean thinking: Optimizing the whole value chain, seen from a customer point of view.

So what can you do to get better at this? This is what we did:

1. Identify the customer (define the relevant personas)
2. Identify the steps in your customer journey
3. What works well?
4. What are your weak spots? where do you lose your customers?
5. Any low hanging fruits?

 

The customer journey

The best organizations consists of units that support the whole customer journey, they are able to handle, improve and truly optimize for the whole. (not only the whole software development process, but the whole customer journey)

Pitfall: I have worked in a team where too many people was looking into step number 4, and unfortunately, the areas of most interest was outside the responsibility of our business unit. This is not a good situation, it is damaging to the motivation of the individual and it prevent the team’s ability to deliver if the focus is on what you cannot change. In an ideal world, anything can be changed, and anything can be changed easily. 

Top performing organizations will change according to what makes sense, but the larger it is, and the more silos you have, the longer time it take. It also require sweat and lots of hard work, and some tears. Trust is a key word in agile software development, and the same goes for lean leadership; each employee must be able to trust that the top management is handling flaws between business units.

Trust

 

Where in the lean journey are you?

What is your next steps?

What is pitfalls have you experienced?