I was working with a very Agile experienced business unit recently, they were having some issues with “momentum” in building a new product offering.
Within the business unit, there were 5 teams working on the minimum viable product offering, and 2 teams working on other products. The teams had all participated in incepting the work, and by all accounts it was a successful inception. Each team consisted of established team members, who together were high-performing and agile knowledgeable. There was one product backlog where features were defined. Each team was capable of delivering all the way to production. All the elements for success, it seemed was there.
They were tackling a brand new build, new technology and 5 teams all working on the same product. They launched into their sprints full of energy and enthusiasm. However, after several sprints, no business value was delivered, and their enthusiasm was replaced by stress.
Losing the forest for the trees
So what happened to this high-performing business unit? It turns out it only took a couple subtle but powerful wrong turns through the forest to lose their way. With such a big new, complicated product, and multiple teams working on it, this can happen quite easily.
Let’s look at ways to diagnose what’s happening, and get to root causes before seeing how this business unit walked themselves out of the forest.
Start with the basics: 12 Agile Principles
- Satisfy the customer through early and continuous delivery of value? FLAG: No customer value was being delivered, yet the teams were delivering software. The MVP (Minimum Viable Product) itself was very large, and product owners did not want to release to the customer until all of the MVP was satisfied.
- Welcome changing requirements? Yes.
- Deliver working software frequently? FLAG: The teams believed they were delivering working software to production each sprint. However the software was API’s and components, and not integrated with a customer journey. It was delivered in production toggled off. This doesn’t meet the intention of “working software” in the principles.
- Business and developers work together? Yes but: Each team had a PO but there was an overall PO owner with a broader view. There was a single backlog defined, but each team had a custom view of only those things assigned to them.
- Motivated team? Yes.
- Face to face communication? Yes.
- Working software is a primary Measure Progress? FLAG: Their measurement of progress was faulty. Working software must represent a customer journey or portion of the customer journey.
- Sustainable pace? Yes.
- Technical Excellence and Good design? Yes.
- Keep it simple, maximize the amount of work not done? FLAG: Component software was being developed and deployed, so it was impossible to know if what was being built was too little, or too much for the customer journey. Also, any software that was built is considered waste as it sits unused in production.
- Self-organise? Yes but: Specialist skilled team members grouped together around the components.
- Reflect and adapt? Yes but: Most of the teams and their product owners didn’t see that they were off track on customer value or working software. It could have been because they saw their own backlogs but lost the big picture.
Root Causes
The biggest red flag above was lack of customer value being delivered. Why was this?
The story map for this product was posted and visible. It took up an entire hallway.The product itself was huge and complex, with many proposed releases planned. The Minimum Releasable Product alone was sized at approximately 5 teams x 8 months duration. This was the bare minimum set of features the business would agree to have, in order for the company to release it.
As the backlogs were being created, the product owners allocated parts of the story map to each team. It seemed so logical. The development teams concurred with this as it helped them focus on one functional area, to work together to complete something they believed was of value.
Each team worked furiously at their parts of the story map. The highest levels of technical excellence were adhered to. All the software developed had tests, passed through all testing environments and were moved to production. Each functional piece was being iterated on and perfected.
So it was hard for them to see, and harder still to accept that they had organised as functional teams rather than feature teams, making it difficult to deliver value and learn faster.
Root Cause: Not following the customer journey.
Secondary Root Cause: Having a very large Minimum Releasable Product made it easier to get off track. Teams believed that it didn’t matter if they approached development by component, as it ALL must be done prior to release.
Another contributing factor was having multiple backlog views. While the teams all had the same backlog, each team had a filtered view. Keeping the entire backlog visible and through joint planning, teams can avoid this.
Lessons:
On your story map, ensure you are cutting across the steps in a user journey, with your first slice being a walking skeleton of the system you are building. It’s the bones on which you can add value.
Visual by: Jeff Patton @ associates
If you find you are working on a single functional thing, raise a red flag. Find the value. What is the customer journey you are working on?
Finding their way back
Working with Scrum Masters, Product Owners and Architects we ran workshops on story slicing, and one team volunteered to run a very visible experiment to show that building end to end delivers more value. There was also the problem of having specialists grouped into one team rather than distributed to allow a team to deliver independently. This would require a wholesale team change.
Together, the group did the following:
- Re-introduce the customer personas and journeys
- Define several slices that would validate the system and get to a walking skeleton.
- Run an experiment doing a “full slice” from the story map.
- Run a self-selecting event to reorganise teams around user journeys.
Through this process, teams learned more about story slicing, and about building to reduce risk early in development. It was also wonderful to see how powerful self-selecting events can be for all involved.
For more information on this case study, or on how we can help your business accelerate value, contact jeanne.armstrong@agilitysystems.coach
