In Continuous Reteaming and Self-Selection, I gave a general overview of the system of work I experimented with for 18 months. I will now detail various parts, starting with the planning day.
Planning day format
Our planning day is essential to achieve our goals: self-selection and self-organisation. It follows the following structure:
- Agenda & intro to the day
- Last quarter achievements
- Target outcomes
- Presentation of the enabling constraints
- Iterations to form the teams
- Broadcast of the plan
Agenda & intro
This workshop is going to be new for at least some of your colleagues. It is important to remind people what is the intent behind this day, tell them what to expect in terms of timings for the various activities and any rules that might apply (ex: why not make it a screen-free day?). Most of the work for the next few months will be driven by the structure that has been established during the day, so people should take this day seriously. But hopefully, some level of preparation went into this, so it should not be a total surprise to your audience.
Also, since the day is going to be intense, plan various breaks for people to relax a bit.
Last quarter achievements
Once the admin stuff is covered, what better way to start the day than celebrate recent achievements?
To do this, each team will take turns and share progress on their outcomes over the last 3 months. People are genuinely curious and will be keen to find out what happened in other parts of the organisation. I give people two guidelines for those presentations:
- Make it as fun as possible / don’t take yourself too seriously. It is the start of the day. People may still need a coffee to wake up, the funnier it is, the more you’ll get everyone’s attention and energise the room. For instance, it is a great time to share anecdotes about some of the problems you had during the quarter.
- You should focus on outcomes, not outputs. One thing I keep repeating to my teams is that I don’t care if a feature is in staging or production. I want my users to tell me that it made their life better somehow. Focus on this. Some engineers think they have been hired to write code, but that’s not true. They have been hired to solve someone’s problem. If they can do that without writing code, even better!
3 months for a team of 3 to 6 is a long time. If you are unable to demonstrate some business impact after that period, either something went wrong, or you may have sliced your target outcome the wrong way. Get back to the drawing board and think about what is the smallest increment that could deliver value.
Last but not least, we also highlight any significant piece of work that is still in flight so that it can feed into next quarter prioritisation (or be dropped).
We aim for ~7mins of presentation per team or 1h total. Each team should spend a couple of hours in the previous days preparing their slides.
Next, are the demand side presentations. Each key stakeholder will go on stage and present what business impact they are after. Their goal is to provide the maximum context in a few minutes:
- Why is this important?
- Why now?
- Who will benefit?
- How will we measure success?
Stakeholders will generally have a grand vision for the area they own, awesome! But more likely than not, only a tiny bit of it is achievable in a few months. This is why I ask them “What does a great quarter look like?”. In my experience, asking this simple question grounds the stakeholder in your current reality. They know things take time. They know that with this system of work, they may only have engineering bandwidth for the quarter, no more. It forces them to have more realistic expectations, focus the effort of the team and make tough calls on prioritisation.
Q&A form an important part of the exercise. Anyone from the audience can ask the presenter to clarify something about the target outcome or context.
The more surprising hindsight though is that this benefits as much the supply as the demand side. It is very common for stakeholders to find out about their respective demands only on the planning day. Congratulations, you are connecting the dots!
In the weeks before your planning day, you may need to coach your stakeholders on what to deliver during their speeches. They probably have specific things in mind, maybe a todo list. Perhaps they want a blue button on that grid. Or a new pdf report. They have ideas, that’s great, some of them might be useful. However, they need to take a step back and frame the problem in terms of business impact. You are not running a software factory:
In doing so, you will be more able to measure progress. Everyone in the team will contribute ideas and solutions, and I guarantee that you will end up with something quite different from your initial plan. This mindset shift might be hard for some of your stakeholders, but it has a high return on investment.
Projects coming from the supply side
How about technical projects, you may ask? Or projects that aim to improve your process? Quite simply, your team should present them as part of this activity. The same rules apply, really. For instance, switching your build system from Maven to Gradle is not a business impact. Halving build times or decreasing by 10x the time it takes to make a fleet-wide change to your microservices builds are a lot better. Sure, that may not impact your company revenue directly, but those are proxy metrics for how fast you can make changes to your codebase and deliver value to the business. Time is money.
Recording the conversation
Last but not least, during all those presentations, members of your teams will need to write themes and ideas on post-its and stick them on the walls. That will be the basis for the main activity of the afternoon.
We spend a maximum of 15mins per stakeholder, including Q&A and ~2 hours in total.
This concludes the first part of the day. In the following post, I’ll talk about how we use constraints to ensure that the new team structure is acceptable. To be continued.💗Did you like this post? Please let me know by clicking 👍 below, or leave a 💬!