As reported by GeekWire, over the weekend two Seattle sisters, Kimberly (8) and Rebecca (10) Yeung, launched a small weather balloon to the edge of space (roughly 78,000 feet). They have the GoPro video from two cameras to prove it.
While this is certainly an impressive, if not amazing, feat for two young girls to have accomplished (despite some parental assistance), what is perhaps most impressive (at least to me) is the debrief (or retrospective) they held after the mission. While I’m not fortunate enough to have been there to witness it personally, I can see from the photo of their debrief sheet (as posted in the GeekWire article) that it was amazingly productive and far surpasses most of the agile retrospectives (debriefs) I’ve witnessed.
Apart from the lesson about their Project Plan (“We were successful because we followed a Project Plan & Project Binder”), this sheet is astonishingly solid. Even given the fact that I think it is a misconception to attribute success to having had a project plan, for an 8 and 10-year-old, this is awesome work!
My friend and fellow coach Brian Rivera and I have often discussed the dire lack of quality, understanding, and usefulness of most agile retrospectives. I might even go so far as to call the current state of agile retrospectives in general “abhorrid” or “pathetic,” even “disgraceful.” Yes, I might just use one of those adjectives.
For teams using agile methodologies and frameworks focused on continuous improvement (hint: everything in agile is about enabling continuous improvement), the retrospective is the “how” which underlies the “what” of continuous improvement.
Supporting the concrete actions of how to improve within the retrospective are the lessons learned. Drawing out lessons learned during an iteration isn’t magic and it isn’t circumstantial happenstance – it requires focused thought, discussion, and analysis. Perhaps for high-performing teams who have become expert at this through positive practice, distilling lessons learned and improving their work may occur at an almost unconscious level of understanding, but that’s maybe 1% (5% if I’m optimistic) of all agile teams.
So what does a team need to understand to actually conduct a thorough and detailed analysis during their retrospective? Actually only a few things:
What were they trying to do? (Goals)
How did they plan to do it? (Planning / strategy)
What did they actually do? (Execution – what actually occurred)
What were their outcomes? (Results of their work)
What did they learn, derived from analyzing the results of their efforts measured against the plan they had to achieve their goals? (Lessons learned)
A simple example:
I want to bake peach scones which are light, fluffy, and taste good. (Goal + acceptance criteria)
I plan to wake up early Saturday morning and follow a recipe for peach scones which I’ve found online, is highly rated, and comes from a source I trust. It should take 30 minutes. (Planning – who / what / when / where / how)
I wake up early Saturday morning and follow the recipe, except for the Baking Powder. It can leave a metallic taste behind, so I leave it out. (Execution)
It took almost an hour to make the scones, and they did not rise. They tasted alright, but were far, far too dense and under-cooked internally, partially due to being flat. (Outcomes)
I didn’t allocate enough time based on the fact that it was my first attempt at baking scones and I was trying to modify a known good recipe (reinventing the wheel, root causes: experience). Although I wanted light, fluffy scones, I didn’t get them because I deliberately left out a key ingredient necessary to help the dough rise (good intention – bad judgment, root causes: knowledge / discipline). (Lessons learned)
Perhaps a bit overly simplistic but this is exactly the type of concrete, detailed analysis into which most teams simply never delve. Instead, retrospectives for most agile teams have devolved into a tragic litany of games, complaining sessions, and “I liked this / I didn’t like that” reviews with no real outcomes, takeaways, or practical concepts for how to actually improve anything. Their coaches leave them with simple statements such as “we need to improve.” Great. Thanks.
Taking what we know from Kimberly and Rebecca’s plan to send a weather balloon into outer space, let’s do a little analysis on their retrospective. I can tell you already it is not only solid, but will ensure they’re able to improve not only on the technical design itself, but also improve their team’s “meta” – the ways they work, their collaboration, their teamwork, their research – everything which enables them to actually continually improve and produce powerful results.
Bigger balloon – create more lift – ensure faster rate of ascent (Technical / work – related but important. They have learned through iterating.)
Remember to weigh payload with extra – more accurate calculations – correct amount of helium (Technical but also process-related, this draws root causes arising from both knowledge and experience, enabling them to adapt both their work itself and their meta –how they work.)
Don’t stop trying – you will never know if you don’t ask. Eg GoPro (Almost purely meta, reflecting a great lesson which builds not only a team mindset but also reflects a core value, perseverance!)
Washington Geography – Map research on launch locations taught us a lot of geography (This is both technical and meta, addressing their research data and inputs/outputs but also learning about how to learn and the value of research itself!)
Always be optimistic – We thought everything went wrong but every thing went right. Eg. SPOT Trace max altitude mislead [sic] our expectations. Eg. We thought weather cloudy but it was sun after launch. Eg. Weight. Thought payload too heavy for high altitude. (Are you kidding me?! Awesome! Lessons about situational awareness and current operational picture, data inconsistencies, planned versus actual events, planning data and metrics, and the importance of outlook/attitude! #goldmine!)
Be willing to reconstruct – If you find out there is a problem, do not be afraid to take it apart and start all over again. (Invaluable lesson – learning to embrace failure when it occurs and recover from it, realizing that the most important thing is not to build the product right, but to build the right product!)
Have a redundant system – Worry less. (Needs no explanation.)
SPOT Trace technology awesome – Very precise (This is a fantastic example of a positive lesson learned – something that is equally important to acknowledge and capture to ensure it gets carried forward and turned into a standard practice / use.)
Live FB updates – add to fun + excitement (Yes yes yes!! To quote an old motto, “If you’re not having fun, you’re not doing it right!” This stuff should be fun!!)
Speculation – Don’t guess. Rely on data. (Fantastic emphasis on the importance of data-oriented decisions and reflects another potential team core value!)
Project Plan – We were sucessful [sic] because we followed a Project Plan + Project Binder. (The only lesson I disagree with. I would advocate a good 5 Whys session on this one. My suspicion is that the project was successful because they as a team worked both hard and well together [high-performing], had fun, and iterated well [based on the lesson about not being afraid to reconstruct / start over]. I have serious doubts that their mission was a success because they had and followed a project plan. Regardless, this is far too small a point to detract from the overall impressiveness of their work!)
Take a few lessons from two girls who have demonstrated concrete learning in ways most adults fail miserably to even conceptually grasp. If you are on a team struggling to get productive results from your retrospectives, stop accepting less than solid, meaningful analysis coupled with clear, actionable results. The power is in your hands (and head).
If you are one of those agile coaches who thinks retrospectives are just for fun and celebration, who plays games instead of enables concrete analysis, and who wonders why their teams just cannot seem to make any marked improvements, get some education and coaching yourself and stop being a part of the problem!
(Written with the sincerest of thanks to Kimberly and Rebecca Yeung, and the Yeung family for their outstanding work, and to GeekWire for publishing it!)
*Chris Alexander is an agile coach, thinker, recovering developer, and co-founder of AGLX Consulting, who spends too little time rock climbing.