Retrospective on the value stream of your software delivery

In this article I’ll introduce a retrospective format that you can use to evaluate a team’s ability to deliver software in a healthy manner. I used the structure of a value stream, like we see in value stream mapping or value stream analysis. Value stream mapping is often used to capture process performance, by capturing metrics, and to visualise process bottlenecks. I borrowed this structure, not to map metrics, but to guide a retrospective workshop. Skip to the workshop steps if you just want to dive in.

Why I think alternating retros is good

Agile ideology has taught me to be cautious of routine behaviour and to embrace change. Many organizations have used agile ideology as crowbar to create some disturbance in the organization. Agile is used to break with entrenched bad practices, feuds in teams, abundance of management layers, and unhealthy routines. Although agile ideology can be misused, there are many success stories where organizations have made a beneficial transition.

However, we have to be careful not to get too comfortable in our ‘new’ everyday agile processes. Often the transition to a new way of working was the catalyst for these new found healthy business processes. After months or years of ‘doing agile’, one has to be perceptive of newly formed unhealthy routines. I am suspicious about certain parts in the Scrum Guide about creating highly predictive outcomes by promoting repetition and limiting changes to the team, and its context. It never felt natural to pursue this kind of robustness for such a creative job. It leads to creating fragile processes with an unhealthy fear of change.

I experienced that ‘forced’ alterations to your agile/DevOps processes can help you to keep the creative juices flowing. A team retrospective is something for which you can easily introduce variety. Variety leads to evaluation, exploration and learning. In recent years, we have seen a surge in tooling to support and automate variety in CI/CD pipelines and in operations. Tools like the Simian Army and Chaos Monkey enable a team to explore their software. To discover unknown unknowns. I believe we also need these antifragile boosting tools at our process levels.

The value stream retrospective

Using value stream mapping or value stream analysis to evaluate performance is certainly not new. It is a good tool to map and measure the Four Key Metrics being: lead time for changes, deployment frequency, time to restore service, and change failure rate. However, properly measuring this takes significant time.

Whether as alternative or addition to value stream mapping, a value stream retro can help a team to evaluate performance during a retrospective and to identify positive changes. It can be useful in these situations:

• Evaluate the overall team performance after five or more sprints.
• Help team members who often find it difficult to contribute to basic retro formats (pizza, or simple retro).     
• When there is unbalance in maturity or social capabilities in the team. Sometimes retros can get too focussed on technology, or not focussed on the actual delivery of the software at all. Offering more structure can create room for more ideas.

Workshops steps

I will provide a rather big value stream, but you can decide to use more generic segments or to provide focus areas if you only want to the evaluation to focus on a specific (problematic) area.

Value stream retrospective map

1. Start by hanging a depiction of the value stream on the wall. You can use the picture above as inspiration.
2. Make sure there is a collaborative understanding of all the parts of the value stream.
3. Give team members 10 minutes to write up positive and negative experiences, ideas, and improvements on stickies. To enhance overview, differentiate with colors.  
4. Make sure everybody has got enough opportunity to share ideas.
5. Gather around with the team, go over every part and discuss what’s on the wall.
6. The review of stickies can take some time. Make sure to alternate team members running point on the review.
7. For each step, identify stickies that your team would like to pick up. Isolate them for future reference.
8. Recap the stickies that were selected as improvements and put them on your sprint board or backlog them accordingly

A retrospective like this can easily take between one and two hours. Because you will likely use this kind of retro to evaluate multiple sprints, I would recommend performing such a retro on a quarterly level. The most important thing is to start experimenting and have fun doing it!