Probably most people have seen one of the videos or memes where people draw something on the back of another person, which simultaneously has to re-draw the exact same thing as good as humanly possible. In case you haven’t seen one, here is an example:
Besides it being a fun game for children (and adults), it realistically represents the difficulties in current software development processes. Alberto Brandolini correctly assessed that
It’s not the experts' knowledge that goes into production, it’s the developers' interpretation.
During a recent team coaching session with former Dutch Special Forces operators, they shared something with us that spiked my interest. I was immediately intrigued to try it out with my team at my current assignment.
But first, what do the Special Forces and developers have in common? And how can something they have incorporated into their routines help developers achieve better results? Once you boil it down to the essentials, it becomes quite obvious:
- Both operate in cross-functional teams
- Each team member is ideally T-shaped, meaning that he/she specialises in a certain skill but has basic to good knowledge in the remaining demanded skill set.
- Both have stakeholders that decide on the course of action.
- Both get assignments to complete, yet how they achieve this is not predefined in the assignment.
Further, it does not need special mention that if a Special Forces team misunderstands the mission and executes something completely different than originally intended by their commanding officers (stakeholders), things may go haywire and result in dire consequences.
Eventually they came up with a simple way of preventing such misunderstandings. Whenever they receive a new assignment and finish discussing the details of it within the team, in the end one of them summarises the whole thing once more in his/her own words.
Wow - such a simple measure, yet it can have an enormous impact on the whole process. Let’s clarify briefly with an example why this simple step in the planning process triggered me so much.
During an assignment kick-off, your stakeholder repeatedly draws an 8 on the board and naturally assumes that it is 100% clear to everyone in the team what he means. Yet, half the team views the 8 in a 90° angle and assume the stakeholder is talking about ∞ (infinity). Without the Special Forces process step, the team might never realise that half of them think that they need to work with infinity, whereas the other half assumes it is an eight they need to focus on.
A few weeks ago, we introduced this simple step into our team’s standard process of a story kick-off, and we immediately saw it bearing fruit. Due to the fact that you need to summarise the story, acceptance criteria, technical solution design, possible pitfalls, third-party dependencies and so much more in your own words, we see the following benefits:
- All team members pay attention during story kick-off.
- Everybody makes sure they understand every aspect of the story.
- More questions are being asked during the kick-off.
- Increased velocity during the sprint.
- Less actively participating team members take a more active role when they need to summarise an assignment.
- Almost 100% mutual understanding of the assignment, and hence less misunderstandings and misalignments.
So, what did we change? Not much. What did we gain? A lot! I would invite every development team to try this at least a few times and witness for themselves how much actually changes.