Tag Archives: Retrospectives

Agile is Dead! The Rise of High-Performing Teams: 10 Lessons from Fighter Aviation

Software and hardware industry leaders are leveraging the lessons from fighter aviation to help their businesses navigate the speed of change and thrive in today’s complex and hostile environment. The emergence of the Observe-Orient-Decide-Act (OODA) Loop—an empathy-based decision cycle created by John Boyd (fighter pilot)—in today’s business lexicon suggests that executives, academia, and the Agile community recognize that fighter pilots know something about agility.

For example, Eric Ries, author of The Lean Startup and entrepreneur, attributes the idea of the Build-Measure-Learn feedback loop to John Boyd’s OODA Loop [1]. At the core of Steve Blank’s Customer Development model and Pivot found in his book, The Four Steps to the Epiphany, is once again OODA [2]. In his new book, Scrum: The Art of Doing Twice the Work in Half the Time, Dr. Jeff Sutherland, a former fighter pilot and the co-creator of Scrum, connects the origins of Scrum to hardware manufacturing and fighter aviation (John Boyd’s OODA Loop) [3]. Conduct a quick Google book search on “Cyber Security OODA” and you will find over 760 results.

This fighter pilot “mindset” behind today’s agile innovation frameworks and cyber security approaches is being delivered to organizations by coaches and consultants who may have watched Top Gun once or twice but more than likely have never been part of a high-performing team [4].

So What?

According to Laszlo Block, “Having practitioners teaching is a far more effective than listening to academics, professional trainers, or consultants. Academics and professional trainers tend to have theoretical knowledge. They know how things ought to work, but haven’t lived them [5].” Unfortunately, most agile consultants’ toolboxes contain more processes and tools than human interaction knowhow. Why? They have not lived what they coach. And this is what is killing Agile.

Teaming Lessons from Fighter Aviation

To survive and thrive in their complex environment, fighter pilots learn to operate as a network of teams using the cognitive and social skills designed by industrial-organizational psychologists—there is actually real science behind building effective teams. It is the combination of inspect-and-adapt frameworks with human interactions skills developed out of the science of teamwork that ultimately build a high-performance culture and move organizational structures from traditional, functional models toward interconnected, flexible teams.

10 Reasons Why Your Next Agile High-Performance Teaming Coach Should Have a Fighter Aviation Background

OODA (Observe-Orient-Decide.-Act). According to Jeff Sutherland, “Fighter pilots have John Boyd’s OODA Loop burned into muscle memory. They know what agility really means and can teach it uncompromisingly to others.”

Empathy. A 1 v 1 dogfight is an exercise in empathy, according to the award-winning thinker, author, broadcaster, and speaker on today’s most significant trends in business, Geoff Colvin. In his 2015 book, Humans Are Underrated: What High Achievers Know that Brilliant Machines Never Will, Geoff pens, “Even a fighter jet dogfight, in which neither pilot would ever speak to or even see the other, was above all a human interaction. Few people would call it an exercise in empathy, but that’s what it was—discerning what was in the mind of someone else and responding appropriately. Winning required getting really good at it [6]” Interestingly, empathy is baked-in Boyd’s OODA Loop.

Debriefing (Retrospective). The most important ceremony in any continuous improvement process is the retrospective (debrief). Your fleet average fighter pilot has more than 1000 debriefs under their belt before they leave their first tour at the five-year mark of service. In Agile iterations years, that is equal to 19 years of experience [7]. Moreover, when compared to other retrospective or debriefing techniques, “Debriefing with fighter pilot techniques offer more ‘bang for the buck’ in terms of learning value [8].” Why is this? There are no games in fighter pilot debriefs, no happy or sad faces to put up on the white board – just real human interactions, face-to-face conversations that focus on what’s right, not who’s right. Fighter pilots learn early that the key to an effective retrospective is establishing a psychologically safe environment.

Psychological Safety. Psychological safety “describes a climate in which people feel free to express relevant thoughts and feelings [9].” Fighter pilots learn to master this leadership skill the day they step in their first debrief where they observe their flight instructor stand up in front of the team and admit her own shortcomings (display fallibility), asks questions, and uses direct language. Interestingly, according to Google’s Project Aristotle, the most important characteristic to building a high-performing team is psychological safety [10]. Great job Google!

Teaming (Mindset and Practice of Teamwork) [11]. Although not ideal, fighter pilots often find themselves in “pickup games” where they find a wingman of opportunity from another squadron, service, or country—even during combat operations. Knowing how to coordinate and collaborate without the benefit of operating as a stable team is a skill fighter pilots develop from building nontechnical known stable interfaces. These stable interfaces include a common language; shared mental models of planning, briefing, and debriefing; and being aligned to shared and common goals. Yes, you do not need stable teams and you they do not need to be co-located if you have known stable interfaces of human interaction.

Empirical Process. The engine of agility is the empirical process and in tactical aviation we use a simple plan-brief-execute-debrief cycle that, when coupled with proven human interaction skills, builds a resilient and learning culture. The inspect and adapt execution rhythm is the same around every mission, whether it be a flight across country or 40-plane strike into enemy territory, we always planned, briefed, executed the mission, and held a debrief. There is no room for skipping steps—no exceptions.

Adaptability/Flexibility. The ability to alter a course of action based on new information, maintain constructive behavior under pressure and adapt to internal and external environmental changes is what fighter pilots call adaptability or flexibility. Every tactical aviator who strapped on a $50M aircraft knows that flexibility is the key to airpower. Every flight does not go according to plan and sometimes the enemy gets a vote – disrupting the plan to the point where the mission looks like a pick-up game. 

Agility. Agility is adaptability with a timescale.

Practical Servant Leadership Experience. Fighter pilots have practical experience operating in complex environments and are recognized as servant leaders. But don’t take my word for it; watch this video by Simon Sinek to learn more.

Fun. Agility is about having fun. Two of my favorite sayings from my time in the cockpit are “You cannot plan fun” and “If you are not having fun, you are not doing it right.” If your organization is truly Agile, then you should be having fun.

So, who’s coaching your teams?

Brian “Ponch” Rivera is a recovering naval aviator, co-founder of AGLX Consulting, LLC, and co-creator of High-Performance Teaming™, an evidence-based approach to rapidly build and develop high-performing teams.

[1] “The idea of the Build-Measure-Learn feedback loop owes a lot to ideas from maneuver warfare, especially John Boyd’s OODA (Observe-Orient-Decide-Act) Loop.” Ries, E. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. (Crown Publishing, 2011)

[2] “…Customer Development model with its iterative loops/pivots may sound like a new idea for entrepreneurs, it shares many features with U.S. warfighting strategy known as the “OODA Loop” articulated by John Boyd.” Blank, S. The Four Steps to the Epiphany. Successful Strategies for products that win. (2013)

[3] “In the book I talk about the origins of Scrum in the Toyota Production Systems and the OODA loop of combat aviation.” Sutherland, J. Scrum: The Art of Doing Twice the Work in Half the Time. New York. Crown Business (2014).

[4] I do not recommend the movie Top Gun as an Agile Training Resource.

[5] Block, L. Work Rules! That will transform how you live and lead. (Hachette Book Group, 2015).

[6] Geoff Colvin. Humans are Underrated: What high achievers know that brilliant machines never will, 96, (Portfolio/Penguin, 2015).

[7] Assuming two teams with iteration length of two weeks. And 100% retrospective execution.

[8] McGreevy, J. M., MD, FACSS, & Otten, T. D., BS. Briefing and Debriefing in the Operating Room Using Fighter Pilot Crew Resource Management. (2007, July).

[9] Edmondson, A.C. Teaming. How organizations Learn, Innovate, and Compete in the Knowledge Economy. Wiley. (2012)

[10] Duhigg, C. Smarter Faster Better: The Secrets to Being Productive in Life and Business. Random House. (2016).

[11] Edmondson, A.C. Teaming. How organizations Learn, Innovate, and Compete in the Knowledge Economy. Wiley. (2012)

Share This:

Agile Retrospectives: High-Performing Teams Don’t Play Games

Scrum, The Lean Startup, Cyber Security and some product development loops have fighter aviation origins. But retrospectives (debriefs)—the most important continuous improvement event—have been hijacked by academics, consultants, and others who have never been part of a high-performing team; sure, they know how things ought to work but haven’t lived them. We have.

Learn what’s wrong with current retrospectives and discover how an effective retrospective process can build the high-performance teaming skills your organization needs to compete in today’s knowledge economy.

Special thanks to Robert “Cujo” Teschner, Dan “Bunny” O’Hara, Chris “Deuce” Alexander, Jeff “T-Bell” Dermody, Ryan “Hook-n-Jab” Bromenschenkel, Ashok “WishICould” Singh, John “Shorn” Saccomando, Dr. Daniel Low, and Allison “I signed up for what?” Rivera.

Brian “Ponch” Rivera is a recovering naval aviator, co-creator of High-Performance Teaming™ and the co-founder of AGLX Consulting, LLC.

Share This:

What the Agile Community Should Learn from Two Little Girls and Their Weather Balloon

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.

14416510384450*Photo copied from the article on GeekWire.

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:

  1. What were they trying to do? (Goals)
  2. How did they plan to do it? (Planning / strategy)
  3. What did they actually do? (Execution – what actually occurred)
  4. What were their outcomes? (Results of their work)
  5. 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:

  1. I want to bake peach scones which are light, fluffy, and taste good. (Goal + acceptance criteria)
  2. 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)
  3. 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)
  4. 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)
  5. 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, ScrumMaster, recovering developer, and co-founder of AGLX Consulting, who spends too little time rock climbing.

Share This:

An Agile Approach to Process Management

Does your business process do what it’s supposed to do?

This is a common question for those involved in business process management, and of course there are many existing methodologies designed to address this. Additionally, process improvement can be carried out at both the macro and micro levels. At the macro level, the business develops processes at the organizational level in order to achieve strategic goals. At the micro level, individual teams, departments, or individuals may develop processes (both formal in informal) to help them accomplish their work.

The issue with existing process development and analysis methodology is that it remains relatively waterfall-ish. Define all of the requirements, develop the process, communicate and implement, then occasionally analyze and change (improve) as needed. The cycle time involved with this approach can be considerable, and especially at the formal, macro level, once initiated the process may be particularly challenging to analyze or change.

An iterative approach to process design and management.

What if we considered process design in an adaptive, iterative way?

In other words, design a narrow process around the first, most important requirement, enabling rapid creation and implementation, feedback, and improvement, while developing toward additional requirements.

This serves two important purposes: first, it enables us to rapidly design and implement a process to satisfy the most important business need, while, second, enabling the process manager to receive fast feedback about the usefulness of the process as implemented thus far.

Once the critical first requirement has been met, the process can be adapted through iteration to satisfy additional requirements, again enabling feedback on the utility of the process overall.

Let’s look at an example of process improvement in new hire onboarding.

CDE Company has a challenging and sub-optimal process in place for onboarding new hires. CDE Company knows this because it is the number one pain point new hires relate about their experience joining the company. Let’s help CDE Co. improve their process through the application of Agile practicies – the same ones their Scrum teams are currently using to develop their products (so everyone is already familiar with and can use them!).

Step 1 – for an existing process, conduct a Process Retrospective

  • Define the goals of the process itself – what is the process supposed to do? “Minimize the amount of time new hires need to get up to speed quickly and become productive.”
  • Analyze the current process plan (how it is supposed to work). “New hire is welcomed and given a desk; requests are sent to create and activate their email account and grant access to the folders, tools, and utilities which they will need to do their job; new hire is added to email lists, meetings, and taken out to lunch; new hire will work alongside another developer to understand the code base and standard practices, and will be given an overview of the main products on which they’ll be working; new hires begin to work.”
  • Gather feedback on the actual current process and how it is executed. “New hire is welcomed and requests are sent; email and access to environments/tools takes anywhere from a couple of days to a week; being added to email lists/meetings requires finding the owners and asking to be added individually; buddying with another developer works ok; lunch is always good.”
  • Identify the lessons from analyzing the current process, the intended plan, and the actual goals. “Onboarding is slower than it should be and we are not achieving the goal of getting new developers up to speed and working quickly; getting email / account / tools / utilities / environments access is too slow and holds developers up; our buddying model works well once the new developer has the access needed; getting the new developer into meetings / email lists is fractured and takes too long.”
  • Transfer those lessons into a plan of action. “We need to re-prioritize and redesign the process to address the issues found in Lessons Learned. Specifically we need to plan to get access for the new hire on Day 1; we need to have email lists / meetings cleared up prior to Day 1; we should maintain the onboarding buddy system.”

Step 2 – hold a Process Improvement Planning Session

  • Set a Timebox for this process improvement / development cycle (1 or 2 weeks should generally be enough time – otherwise you’re taking on too much work).
  • Using the process owner(s) as a sort of Product Owner, determine what the most important requirement(s) of the process is in terms of either the Lessons Transferred from the Retrospective or the needs of the business, team, or individual. “Get the new developer access to email / development tools / environments on Day 1.”
  • It is important to note that the size / number of planned improvements should be something achievable within the agreed timebox. (Just to re-iterate: 1 improvement implemented is better than 5 improvements “in work”.)
  • Plan how to achieve the requirement identified, and name an owner. “Develop a consolidated list of tools / utilities / environments and work with infrastructure & engineering leads to create account permissions according to that list for new hires at Day 1 minus 2; on Day 1 minus 1 Operations places the account in a password reset state; on Day 1 new hire completes password reset process and has access to email and all required tools & utilities.”

Step 3 – implement the Plan 

The next new hire through the door gets to use the new process.

Step 4 – conduct the next Retrospective and Planning Session

Retrospect and then prioritize any new lessons along with the existing work which is still in the backlog and waiting to be done (such as improving new hires getting added to email lists and meetings). Moving forward to the next planning session, plan improvements for the next highest priority item(s) which can be achieved within the timebox.

An iterative approach to process improvement also provides the opportunity to stop working on process improvements once the process has been improved enough to be generating sufficient utility – regardless of whether every conceived improvement has been implemented.

Although certainly feasible, the majority of business value will likely be derived from implementing a portion of the desired improvements to a process, but not necessarily all. If we can determine that the Pareto principle (80% of the value of our process is delivered by 20% of the features/work) is indeed applicable to our process, then eliminating sub-processes or work not required will further contribute to business capacity by eliminating waste.

Whatever process you’re seeking to implement or improve upon, an Agile approach can help you build and deliver faster and with greater effectiveness. Payroll, feature request intakes, customer polling, software bug remediation, hardware certification, inventory management, data analysis and reporting – it is challenging to think of a single process which couldn’t benefit in some way from utilizing an iterative, Agile approach to design and continuous improvement.

Share This:

Six False Assumptions That Are Killing Retrospectives

These six commonly accepted (but false) assumptions about retrospectives are killing innovation and hindering your teams’ future execution.

  1. Retrospectives are meetings
  2. A retrospective length is dependent on sprint/iteration length
  3. Retrospective variety ensures team members do not get bored
  4. There are three basic questions in a retrospective
  5. The Scrum Master or Agile Coach must facilitate the retrospective
  6. A retrospective is designed independently of other Scrum/Agile events

1. Retrospectives Are Not Meetings

Retrospectives are not meetings. Retrospectives are events. Why is this important? We know that words have meaning and if you look at the definitions of “meeting” and “event” you will see that a meeting is an assembly of people for discussion or entertainment. An event, on the other hand, is something that occurs in a certain place during a particular interval.  Meetings start late and end late, and to be honest, meetings are typically a waste of time. Events are structured, start and end on time, have a purpose, and dare I say it, follow a process or method.

2. Retrospective Length is Independent of Sprint/Iteration Length 

The time needed for a retrospective is independent of sprint or iteration length. For example, a four-week sprint does not require a four hour retrospective.  A one hour retrospective is enough time for a high-performing team to identify the handful of action items required to improve their future execution, regardless of the sprint length. An average team, on the other hand, may need up to two hours to help them build individual and team retrospective muscle memory.

To maximize the amount of work not done, a team only needs to gather data (what went well/ what didn’t go well) for five events (planning, standups/communication, sprint execution, review, and retrospective) and this can be done in as little as ten minutes—shorter with a well-practiced team.  Analyzing sprint execution (generating insights), conducting a root cause analysis, and developing action items (lessons learned) are where the team needs to spend the majority of the hour.

Consider this: a four week sprint will have more standups and more execution days than a one week sprint, but this does not equate to a 4x increase in the amount of time needed to gather data in a retrospective. A high-performing team should be able to glean all their learning points from a 2-6 week sprint within the span of an hour. Anything more is a disrespectful waste of the organization’s money and the team members’ time.

3. Retrospective Variety is NOT the Spice of Organizational Life

Boredom: “an aversive state of wanting, but being unable, to engage in satisfying activity.”  

The idea of trying out a new retrospective activity (game) so team members do not get bored is misguided. The perceived or actual boredom displayed by individuals or teams toward retrospectives may be (1) a result of the type of work the team is doing, (2) a lack of understanding of the retrospective activity and/or a failure to achieve actionable outcomes, or (3)  the fact that great retrospectives are hard as they challenge people to be open and honest—we also know that boredom is a result of being too challenged.

Let’s assume that knowledge workers are challenged each sprint or iteration and their work is not the source of the perceived boredom. How does changing the retrospective activity (game) address the averse state of wanting to be engaged in a satisfying activity? And if retrospectives are perceived as being too challenging, then why would one believe that changing the activity would pacify this root cause of boredom?

Consider these points if you continue to believe changing up retrospectives in the name of boredom is a smart idea:

  • Inconsistent retrospectives, in structure and/or frequency, lead to mediocrity. According to Jim Collins, “The signature of mediocrity is not an unwillingness to change. The signature of mediocrity is chronic inconsistency [1].”   
  • Repetition. Repetition. Repetition. Learning something new, awkward, and difficult requires some repetition. It takes a while to get used to opening up, being self-critical, and learning how to respectfully challenge each other in and out of a retrospective.   
  • According to Doug Sundheim, “Debriefing (Retrospective) is a structured learning process designed to continuously evolve plans while they’re being executed.”
  • Culture is a product of retrospection. Edgar H. Schein points out that “culture is the result of a complex group learning process [2].”
  • Innovation is a product of interactions, and common processes that accelerate those interactions are necessary. According to a recent McKinsey Quarterly article, “…innovation is a complex, company-wide endeavor, it requires a set of crosscutting practices and processes to structure, organize and control it [3].”
  • So not only will “variety” in your retrospectives not produce desired results, it will also have a negative impact on your team’s ability to improve.

4. The Two Most Powerful Questions in a Retrospective Are:

  1. What was the primary objective?
  2. Did we achieve what we set out to do? Did we achieve that objective?

Why are these the most powerful questions during a retrospective? Simple: alignment. If the team is not aligned, if individuals cannot succinctly restate the sprint objective, then we (organization, leaders, Agile Coach, Product owner, etc.) have failed to establish the necessary conditions for the team to become empowered [4].

With an aligned team, the answer to the second question should be binary (yes/no) assuming the primary Sprint objective is clear, measurable, and achievable. Moreover, the primary Sprint objective should be connected to the external effects on the economic system (i.e. business value) and not an internal measures of performance (e.g. ready stories, velocity, burndown, etc. ).

What Went Well? What Didn’t go well? What can we do better? These three questions are commonly used and thought of as a proven retrospective design or process instead of as techniques that are helpful in gathering data and deciding what to do. Caution,  a real danger exists when asking a team “What they can do better?” if they do not share a common picture of “What” happened, understand “How” that something happened and, more importantly, “Why” it happened (root cause analysis). In a later post I will go into more detail on how a self-similar activity used in strategy and product development (What-How-Why) can be a powerful tool in building action items in retrospectives.

5. Who Facilitates?

A lot of people look to the ScrumMaster or Agile Coach to facilitate a retrospective, and indeed, when a team is just learning how to conduct and participate in a retrospective, this is important. However, the retrospective should be viewed as a leadership episode, where leadership is valued over facilitating the event.  In complex systems, leadership “takes place during interactions among [team members] when those interactions lead to change in the way those [members] expect to relate to one another in the future [5].”  How members relate to each other in the future is directly connected to how a leader (a person in an actual or perceived position of some authority) establishes a safe environment during the retrospective (a leadership episode).

The Product Owner’s position on the team is better suited for establishing this safe environment as they generally have over 51% of the vote when it comes to the product vision and backlog. On the other hand, the ScrumMaster or Agile Coach are often contractors or viewed as event facilitators, protectors of the framework, thus making the crucial step of setting the tone (establishing psychological safety) problematic. Development team members are also great candidates for leading the retrospective and should be given the leadership opportunity when the team is comfortable with a proven retrospective process.  It is perfectly acceptable for the ScrumMaster or Agile Coach to coach whomever is leading the retrospective during the actual  retrospective execution and then follow up with a one-on-one retrospective using a self-similar process.

6. The Leadership Pattern within a Retrospective Should be Tightly Coupled with Leadership Patterns of Other Events

Iteration or Scrum events should be viewed as a whole and not as standalone parts of a system. Just as Scrum exists in its entirety, the leadership patterns of each Scrum event should be tightly coupled (have interdependencies) where the relationships among those patterns work together in some fashion. Combining an off-the-shelf retrospective game with an ad hoc planning process (the letting the team figure it out approach), for example, is counter to basic Systems Thinking.  Leadership patterns within system events need to be connected. How a team plans, how it conducts its standups, and how it executes its sprint must be connected to how the team holds its retrospective.   

To illustrate this point, consider Russell Ackoff’s example of taking the best parts from 450+ different cars (best transmission, best tires, brakes, cooling systems, belts, spark plugs, etc.,)  and trying to put those best parts together to make the best car. The parts do not connect and therefore you do not have a car, you have a mess. The proliferation of retrospective games, ones that are designed independently of other Scrum events, are the equivalent of those incompatible best parts – they only contribute to an Agile mess.

 

Brian “Ponch” Rivera is a recovering Naval Aviator and Commander in the U.S Navy Reserve. He is the co-founder of AGLX, LLC, a Seattle-based Agile Leadership Consulting Team, and a ScrumTotal Advisory Board Member.

 

References:

[1] Jim Collins, Good to Great: Why Some Companies Make the Leap…and Others Don’t (HarperCollins, 2001)

[2] Edgar H. Schein, Organizational Culture and Leadership, 3rd Ed. (Jossey-Bass, 2004)

[3] Marc de Jong, Nathan Marston, and Erik Roth, The Eight Essentials of Innovation. McKinsey Quarterly April 2015

[4] Senge, P. M. (1990). The fifth discipline: The art and practice of the learning organization. New York: Doubleday/Currency.

[5] Hazy, J. Goldstein, J, & Lichtenstein, B.B. (2007). Complex Systems Leadership Theory: New Perspectives form Complexity Science on Social and Organizational Effectiveness. http://emergentpublications.com/documents/9780979168864_contents.pdf?AspxAutoDetectCookieSupport=1

Agile <a href=”http://www.canstockphoto.com“>(c) Can Stock Photo</a>

Share This: