This is a process I’ve tried a few times over the years and wanted to share, its great for teaching your team to teach themselves about common problems and blockers they have, and also getting them to understand how to work better as a team rather than a group of individuals.

This is how it goes:

Take a medium-sized story, put the team in a room, and get them to try to do it in a single day working together. Most of the time they will fail, but they’ll learn.

This helps answer the question, why can’t we get a story done in a short period of time?

Why is this important? During a two-week sprint, sometimes you have to wait for things, so you wait and go work on something else, and it doesn’t matter because you have a full 2 weeks, right? You don’t notice or try to fix these things. These things slow you down, examples are:

• The flaky CI that you rerun a few times and 6 hours later it’s ready.
• The code review ping pong that goes for 6 days.
• The multiple systems that need to merge/deploy in order because for 1 story you need to change 3 systems.
• The systems that take a whole day to get working on your laptop because you haven’t touched them in a month.

On top of finding the problems, the team also learns how to collaborate on a single story. This helps with not only faster delivery but also sharing of knowledge within the team.

This is good if you see this type of behaviour in your team:

• At the start of the sprint, each dev picks up a single story and works in isolation
• Standup meetings seem unimportant because everyone is working on different things
• During the day your team is not talking; in office situations, they may put headphones on and ignore the rest of the team for the whole day
• When questioned, you consistently get feedback “we can’t get more than one person working on this”, which usually means they’ve never tried

Note: It’s ok for devs to do short periods in isolation, they should not be “pairing all day” as some extreme companies encourage, but an entire day or more is a warning sign.

Expanded Process

1. Pre-exercise briefing (if it’s the first time)
   – Set expectations and explain the purpose.
   – Get buy-in from the team; if they don’t believe it’s a good idea, they will make it fail.

2. Story Selection:
   – Team agrees on a medium-sized story that would typically take several days to complete.
   – The story should be challenging but potentially achievable.
   – Choose a number of man-days similar to the people in the team if you use man-day estimation.

3. Team Composition:
   – Ensure the team has diverse skills to cover all aspects of the story.
   – Possibly including people that are needed for code review approval, deployment, etc.

4. Environment Setup:
   – Prepare a dedicated workspace where the team can work without interruptions.
   – Book a large meeting room.
– Set up Pairing Stations for a day.

5. The Day:

   – Set a strict one-day time limit, e.g., 8 hours.
   – Begin with a brief planning session to break down the story into tasks, 30min time box.
   – Execute, encourage pairing, and regular communication, time box 7 hours.
   – Call it on time, tell the devs “hands/pens/keyboards down”, at the end of the day, the goal is to learn rather than finish, don’t let them work into the evening, even if they want to. You need time for retro.
   – Conclude with a team retrospective to discuss learnings, challenges, and insights, 30min time box. This is the most important part, they can run overtime on this 🙂

Implementation Notes:

1. Frequency: Implement this approach periodically, not as a daily practice.
2. Follow-up: Use insights gained to improve regular work processes.
3. Balance: Combine with other agile practices for a well-rounded approach.