5 Whole-Team Workshops To Increase Developers’ Role In Sprint Planning

Run these activities with the whole team to increase not only the developers’ role in sprint plannings, but also collaboration, engagement, and value creation!

Tools have taken over the meaning. I need to chant “The card is a token for an ongoing conversation” over and over. (George Paci extremeprogramming@groups.io)

The devs had no say in what stories went into the sprint (David Kramer extremeprogramming@groups.io)

[ndlr: In Parallel to] The rise of the ‘Product Manager’ job, which is a strange combo of a member of the sales organization and a surrogate user. Engineers no longer can talk to users. (Slava Imeshev extremeprogramming@groups.io)

Nowadays, it looks like developers are often stuck in their development roles. They are rarely involved in product management decisions. In this context, they receive user stories like “tasks to do.”

From a rational point of view, we can explain this situation with two typical human biases:

• We tend to underestimate the importance of soft topics. Here, we overlook the impacts of collaboration, trust, understanding, and implication.
• We tend to keep things for ourselves because we want to stay in control.

Yet, as coaches, we see teams and developers suffering from this situation. Sure, we understand where this is coming from… We are humans, not 100% rational robots, though! As a result, it’s easy to fall into disillusion or rebellion!

Wouldn’t it be great if you knew ways to make all stakeholders – product experts, developers, and quality people – collaborate to plan what goes into the sprint?

Here are 5 whole-team workshops to build team spirit and trust between stakeholders. Eventually, they should make everyone collaborate towards the same direction:

1. Practice an Example Mapping kata
2. Agree on a scope with a Big-Picture Event Storming
3. Play the built-in quality game
4. Agree and improve a whole-team test strategy
5. Address technical debt from a business perspective

Each of these activities should increase the developers’ role in sprint planning. And guess what, greater collaboration on planning is not only good for developers! As a second-order effect, it will:

• Improve product management decisions
• Increase developer motivation
• Reduce developer stress
• And finally, increase the value creation.

It’s a clear win-win for everyone!

1. Practice an Example Mapping kata

Sample Example-Mapping cards on the introductory post about Example-Mapping, by Matt Wynne

I already wrote about how to inject Example-Mapping into your process. It is also possible to run a kata to learn Example-Mapping. Any kata with enough ‘domain’ will do. For example, the Mars Rover Kata is a great fit. Here is how to do:

• Invite the product and quality experts.
• Hand the kata specs to the product person, but don’t say a word to others.
• Make them run the example mapping to discover the specs.

If you don’t know the Example Mapping workshop yet, you can learn more about it in these posts.

2. Agree on a Scope with Big-Picture Event Storming

A new target is a perfect occasion to run a Big-Picture Event Storming. Propose one next time the team starts a new product, a new important feature, or some rearchitecting. There are at least three collaboration benefits:

1. Participants will collaborate closely during the workshop. As a consequence, all stakeholders will know and trust each other more. Trust is the foundation for more collaboration on planning.
2. Often, developers accumulate a huge domain-knowledge debt. Big-Picture Event Storming is an accelerated way to pay it back. With more domain knowledge, developers’ role in the sprint planning will increase.
3. Participants will map out all domain events on the design board. This makes negotiating the scope of the next milestone straightforward. It’s a perfect occasion for developers to have a massive influence on planning. Here is a post explaining how to use Big Picture Event Storming to agree on a target scope in more detail.

I’ve written a lot about Event Storming in the past. Misadventures with Big Design Up-Front is a good starting point. (Note: My colleague Matthieu Tournemire and I have created the Event Storming Journal, a blog dedicated to demystifying Event Storming)

3. Play the built-in quality game

From the Built-in Quality Game under Creative Commons Attribution-ShareAlike 4.0 International License

Often, developers are absent from planning by sheer ignorance. Many business stakeholders ignore the impact of omitting some technical practices.

Nobody Ever Gets Credit For Fixing Problems That Never Happened explains this situation. It concludes that serious games are a way to get everyone more aligned. The Built-In Quality Game could be such a game. We invented it as a fun alternative to formal training. It lets everyone experience how investing in engineering practices speeds up feature delivery.

Here are two other games to raise awareness about technical debt:

• Dice of Debt Game
• Catch the moon

Hopefully, these games should make business people care more about sound engineering. As a result, they should pay more attention to developers during sprint plannings.

The Built-In Quality Game is open source, and you can download all the material to run it from GitHub.

4. Agree and improve a whole-team test strategy

At work, many teams have the long-term goal of ‘inverting the test pyramid.’ Although a worthy goal, teams don’t necessarily know how to get there by themselves. Without enough collaboration, product, development, and quality experts were only optimizing locally. They need more coordination to tackle the problem as a whole.

We created and have now run the Test Strategy Workshop with a few teams. The goal is for them to embark on a test improvement journey together. It’s a multi-stage workshop that spans many short sessions. Here is how the workshop goes:

1. Introduction to the topic.
2. Homework and presentation of the different kinds of tests in the industry.
3. Drawing of the industry’s ideal test pyramid.
4. Drawing of the team’s current test pyramid.
5. Collaborative “Test Strategy Canvas” to agree on how the team is currently testing.
6. Solution Focused activity to define the next improvement to “invert their pyramid.”

Product and quality people take part in defining the next improvement. As a result, they are more likely to sponsor test improvement during sprint plannings.

It was also an occasion to learn more about our own tests. It was as if we climbed up a tree and saw the whole testing forest unfold before our eyes. (Mirna)

Even if some team members were already aware of testing techniques, testing best practices, this workshop gives the possibility to share a common vision between all the team members. (Patrice)

This workshop is Toyota’s Improvement Kata in disguise: it’s a long-term quest! Once a team delivers an improvement, they should re-run the workshop to agree on the next step! Every run will strengthen the collaboration among the stakeholders.

Tell me if you would like me to write about this workshop in more detail.

5. Address technical debt from a business perspective

In this talk, Jürgen De Smet presents a workshop to make everyone agree about how to deal with bugs. It uses bugs as the visible part of the technical debt iceberg. Its structure is close to that of the test strategy workshop I wrote about above:

1. The whole team gathers to agree on how to classify and deal with bugs. Some categories of bugs will be fixed, while others will be parked.
2. After a while, they meet again to analyze parked bugs. The goal is to identify a sub-system where refactoring would fix a lot of these bugs. 
3. They then run a Solution Focused activity to agree on a small refactoring increment.
4. They regularly go through the workshop to keep the momentum.

I have not yet tried this workshop with teams. Yet, Jürgen obviously did, and it looks promising enough that I mention it.

Call to action

Are you coaching a team in which developers are the mere executors of the business people’s plans? In this case, give these workshops a try!

The first one might not create a revolution, but it will start to move the needle. As you run more of these activities, the developers’ role in the sprint planning should grow.

What about you? Please share your tricks to increase the developers’ role at Sprint Plannings?

Other articles that might interest you

Here are other related articles that you read to dig further:

• How to convince your business of sponsoring a large scale refactoring
• If you want to learn other ways to inject DDD in your organization, check Organization refactoring: Event Storming and DDD injection
• If you want to read how we invented the Built-in Quality Game at work, read A serious game for learning ‘built-in quality at the source’
• My complete guide about how to run your first Big Picture Event Storming starts with Misadventures with Big Design Up Front
• How to run your first improvement kata
• A complete workshop for your team to see what’s a good test strategy

Stay up to date with content and upcoming products

I usually write about 15 minutes worth of reading per month. I won't transfer your email. No Spam, unsubscribe whenever you want.

As a gift for subscribing, you'll receive an illustrated mini-ebook "How to start a team coding dojo"!