Hindsight. Painful but useful
I was recently asked (spontaneously) to present a topic. A topic that I’m very passionate about. In that moment and without any preparation, I defaulted to writing bullet points on a flip chart as I explained each area of the topic. Whilst I did what was asked of me, I know I could’ve done a lot better. I replayed this event in my mind countless times; each time thinking of how much better I could’ve presented, how I could’ve made it more engaging and interactive, how I should’ve been more passionate. Next time I’ll use these mental replays and this hindsight to do better.
Replaying events, knowing that you could’ve done something better is a painful experience but a valuable one. We shouldn’t dwell on the fact that we could’ve or should’ve done things better. Instead, we should know that next time the situation arises, we’ll be perfectly prepared.
In scrum, we look back over the last sprint during the retrospective. We often (hopefully) uncover some uncomfortable truths. Some things didn’t work very well, perhaps some things failed badly. It’s important that the team feel safe enough to acknowledge these failures, “warts and all”. It’s human instinct to feel guilty when we don’t achieve what we planned or we encounter issues that we didn’t foresee. But as the excellent Jurgen Appelo explains – we need to allow our teams to “eat some dirt” from time to time to build up their immunity. Jurgen draws the analogy from our modern obsession with protecting children from germs and ironically leaving them more vulnerable. Each time we reflect on the bad things, the failures and the problems we actually strengthen the team’s immunity. Acknowledging a problem is like vaccinating against a problem. It might not prevent it but it drastically reduces the chances of it happening again. We shouldn’t catch the same cold twice – We shouldn’t be talking about the same issue in two consecutive retrospectives.
Travel forward in time
A useful trick is to travel forward in time in our minds. Imagine the perfect sprint; the user stories burn down at a delicious flow, the team are happy, acceptance criteria is perfectly written, the team have no impediments. What would we need to do to make this a reality? Next, imagine the worst possible sprint; the team are continually impeded by a hardware problem, a tester is off sick, the product owner is not available… What can we do to prepare for this? What happens, how does it happen, what does it feel like? When we do this we identify future roadblocks and future challenges so that when we do encounter them we’ve already prepared for them. We’re vaccinated!