All posts by Brian Rivera

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:

Why Your Next Agile Coach Should be a Fighter Pilot

As technological adoption and innovation accelerate through Mach 3, more business leaders will turn to fighter pilots to help their businesses survive and thrive in today’s VUCA world. For example, the cognitive and social skills naval aviators developed in the cockpit are in high demand in industries where teamwork is essential and team failures costly (e.g. healthcare, oil and gas, mining, energy, and commercial aviation). As more companies adopt a team-based approach to product delivery, and product and companies’ lifecycles shorten, the demand for proven team performance training and coaching will accelerate.

The cognitive and social skills (nontechnical skills) fighter pilots learn are rooted in what is considered to be one of the success stories of modern psychology and cognitive engineering: Crew Resource Management (CRM). CRM training, affectionately known as “Charm School,” covers crucial aspects of resilience including the topics of situational awareness, mission planning, team dynamics, workload management, effective communication, and leadership. CRM was developed in response to the realization that the kinds of errors that cause plane crashes are invariably errors of teamwork and communication (nontechnical skills).

A 50,000 foot view of CRM

  • CRM is the foundation of a human-systems approach, Threat and Error Management (TEM), designed by Human Factors engineers to help us understand and direct human performance within complex operating systems.
  • Human Factors is the applied science of how humans relate effectively and productively with one another in highly technological settings.
  • Crew Resource Management (CRM) is defined as the use of all available resources—information, equipment, and people—to achieve safe and efficient flight operations.

Fighter Pilots as Agile Coaches?

In the 1950s, John Boyd, a fighter pilot and military strategists, developed a decision cycle that changed the “The Art of War.” The decision cycle Boyd developed is known as the OODA Loop and refers to Observe-Orient-Decide-Act. In business, the speed at which the OODA Loop is executed allows the company to get “inside the decision cycle” of its competitors or valued customers. The OODA Loop is an exercise in empathy.

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. 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. 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, mentions that the origins of Scrum are Boyd’s OODA and the Toyota Production System.

Scrum is based on my experience flying F-4 Phantoms over North Vietnam… Fighter pilots have John Boyd’s OODA Loop burned into muscle memory. They know what Agility means and can teach it uncompromisingly to others.

-Jeff Sutherland, co-creator of Scrum

What’s missing from today’s Agile Coaching toolkit is the proven human-interaction skills (nontechnical) developed for technical teams who operate in complex environments, CRM. The Agile community is making the same assumptions fighter and commercial pilots made pre-CRM: That effective teams can be built without any formal guidance or instruction. “Leaving it up to the team” is a recipe for failure.

Fighter pilots, unlike some agilists, are horrible marketers. Crew Resource Management is not your DaD’s Scaled Agile Framework (SAFe) nor does it tell you how to do more with LeSS; CRM is a proven approach to building agile at scale. CRM does not replace Scrum but provides the tools an enterprise needs to transition command-and-control managers into servant leaders and build effective and efficient teams. CRM is the “Science of Teamwork.”

9 Cognitive and Social Skills Fighter Pilots Bring to the Agile Fight

1. Adaptability. 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. The success of a mission depends upon the team’s ability to alter behavior and dynamically manage team resources to meet situational demands.

2. Empathy. Empathy? Fighter pilots and empathy? Yes. John Boyd’s OODA is really about empathy. According to Geoff Colvin, empathy is “discerning what some other person is thinking and feeling, and responding in some appropriate way [1].” OODA is an exercise in empathy. Moreover, according to Geoff Colvin, empathy is the foundation of all other abilities that increasingly make people valuable as technology advances [1].”

3. Assertiveness. One’s willingness to actively participate, state and maintain a position, until convinced by the facts that other options are better.

4. Decision Making. The ability to choose a course of action using logical and sound judgment based on available information.

5. Leadership. The ability to direct and coordinate the activities of other team members or wingman and to encourage the team to work together.

6. Mission Analysis. The ability to develop short-term, long-term and contingency plans and to coordinate, allocate and monitor team resources. Effective planning leads to execution that removes uncertainty and increases mission effectiveness.

7. Situational Awareness. The degree of accuracy by which one’s perception of the current environment mirrors reality. Maintaining a high level of situational awareness will better prepare teams to respond to unexpected situations.

8. Communication. The ability to clearly and accurately send and acknowledge information, instructions, or commands and provide useful feedback. Effective communication is vital to ensuring that all team members understand mission status.

9. Workload Management. The implementation of a strategy to balance the amount of work with the appropriate time and resources available. It includes making sure those people are alert and vigilant (preventing fatigue); figuring out who does what delegation; teaching people how to manage interruptions (and limit interruptions at critical moments; prioritizing tasks and avoiding task oversaturation; and avoiding pitfalls such as continuing a project, flight, or activity even when it’s becoming clearer and clearer that it is dangerous to do so. Workload management in high-reliability industries also means doing all of the above under stress.

While putting this list together I came up with more than 50 examples of why a fighter pilot should be your next Agile Coach. Please feel free to add more or comment on my choices for this article.

Brian “Ponch” Rivera is a recovering naval aviator and co-founder of AGLX, LLC, a Seattle-based Agile consultancy that melds the proven principles of High Reliability Organizations with today’s Agile practices.

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

Share This:

Leading Agile Organizations: Lessons from the Flight Deck

Have you ever been part of an organization where the product owner, manager, or CEO failed to accept input from a junior or rookie team member and the project or initiative failed? Imagine being part of a team where either failing to share information or not acting on critical information is found to be the root cause behind flying an actual project, an aircraft, into the ground.

In the cockpits of today’s commercial airliners and military aircraft, open communication and the ability to respectfully question authority(perceived or explicit) are essential cognitive and interpersonal skills every crew member must learn so as a team, make that a high-performing team, they can mitigate the unforgiving risks inherent in their complex environment. However, thirty years ago cockpit culture was the poster child for management 1.0 (control) — the very problem impeding agile transformations around the globe.

In the 1970s a rash of commercial airline accidents led NASA and the National Transportation Safety Board (NTSB) to investigate how to fix the complex aviation system. The tipping point in commercial aviation came on December 28, 1978 when United Airlines Flight 173 (UA-173) crashed in a Portland suburb, killing 10 passengers.

UA-173, a DC-8 with 181 passengers on board, circled near the Portland, Oregon airport for an hour as the crew tried to troubleshoot a landing gear problem. The flight engineer, the crew member responsible for monitoring the aircraft systems, unsuccessfully warned the captain (the flying pilot) of the rapidly diminishing fuel supply. The captain—later described by one investigator as “an arrogant S.O.B.” –waited too long to begin his final approach and as a result UA-173 ran out of fuel and crashed.

United-173-e1404804178495

Following the UA-173 investigation, NASA discovered that 60-80% of airline accidents were caused by human error. Digging deeper, and not just settling on human error as a singular cause, NASA identified failures in alignment, leadership, interpersonal communication, and decisiveness as root causes behind several commercial airline disasters including UA-173.

The hierarchical, command and control culture commonly found in the front office (flight decks) of 1970s era commercial airliners including that of UA-173 were no different than those cultures found in many of today’s legacy companies. Following the crash of UA-173, the aviation industry with the help of NASA realized through deep retrospection that the top-down predict-and-control paradigm of managing in complex environments needed to change.

The hierarchical “chain of command” system in place at the time of the accident [UA-173] did not always provide for effective flight crew resource management. Additional training was identified as being needed to ensure the flight crews recognized the value and merits of flight crews breaking down the more formal hierarchical structure. This approach leads to a more participative and collaborative process to ensure that all members of the flight crew feel free to speak up and provide the captain with all relevant information relating to the safety of the aircraft [1].

This change came in the form of Crew Resource Management (CRM), a leadership training system that “encompasses a wide range of knowledge, skills and attitudes including communications, situation awareness, problem solving, decision making, and teamwork,” according to CrewResourceManagement.net. CRM liberated the cockpit environment so every member, regardless of rank, position, skills set, age, time with the company, etc., was empowered to truly collaborate around a shared objective or explicit purpose.

In today’s turbulent markets business leaders are desperately trying to become more “Agile” yet most fail because traditional company cultures—hierarchical, command and control bureaucracies—do not provide knowledge workers the support needed to innovate, adapt, and ultimately delight customers with valued, rapid product releases. Applying aviation lessons learned to Agile transformational challenges is not new; for those of you who have read my posts you are aware that commercial and military aviation have profoundly influenced Agile, Scrum, The Lean Start Up, and elements of design thinking.

Adding leadership patterns from CRM to your Agile toolbox will help transform managers into Agile leaders and coaches–rather than the perceived or actual impediments to organizational agility. In part 2 of this post, I will share more CRM information and provide ideas on how it can help remove the “S.O.B” from your cockpit before a project or your company crashes into the ground.

Warning: You may be the S.O.B.

Brian “Ponch” Rivera is a recovering Naval Aviator and current Enterprise Agile Coach and Executive Consultant based in Seattle, WA.

[1] FAA Website http://lessonslearned.faa.gov/ll_main.cfm?TabID=1&LLID=42&LLTypeID=7

Share This:

500% Productivity Increase in One Day: Lessons from a Stand-down

Last month, seven software development teams (35+ members) stepped away from their sprint for one day and participated in Sprint Stand-down. The problems the teams were trying to solve during the Stand-down were technical—the teams recognized they had a collective knowledge gap and needed to slow down to speed up.

During the Stand-down retrospective, we discovered the teams increased productivity by over 500% in one day—an unexpected and welcomed event outcome. The retrospective provided us an opportunity to examine the how and why behind the hyper-productivity realized in this unfamiliar, one-day training event.

The lessons we learned were not revolutionary; instead, the lessons reinforced the values and practices found in the Agile Manifesto, Scrum, Extreme Programming, CrossLead, Flawless Execution, Crew Resource Management and Threat and Error Management.  In one day, a Sprint Stand-down provided undeniable evidence to developers, product owners, managers, directors, VPs, and the CIO that empowered execution trumps the traditional command-and-control approach to product delivery.

The transferable lessons learned from the Stand-down fall into familiar categories:

  • Shared Purpose/Objective
  • Workload Management/Limit Work in Progress (WIP)
  • Leadership/Teamwork
  • Execution Rhythm or Cadence
  • Communication

Before going deeper into the lessons learned, I want to share a little bit about the origins, concept and our approach to a Sprint Stand-down.


Sprint Stand-down

You will not find a Sprint Stand-down in the Scrum Guide. A Stand-down is not found the Project Management Institute’s (PMI) vernacular nor is it part of any Agile or current trending management methodology. A Stand-down is a training evolution commonly used by elite military units, commercial aviation, and other high-reliability organizations (HRO) to accelerate team performance.

The purpose of any Stand-down is to promote knowledge-based training along with personal discipline and responsibility as essential elements of professionalism. It is designed to empower and inspire a community of professionals to continuously seek knowledge, integrate new information in everyday practice, and share new findings with others within the company and industry.

Stand-down Planning

The event was a self-organized undertaking where a small team of eight people were accountable for event execution. Planning for the event followed a rapid planning processes inspired by Crew Resource Management (CRM) and Threat and Error Management (TEM). The objectives of this Sprint Stand-down were to inform, inspire, educate, and motivate the teams—admittedly weak objectives as they lacked clarity and measurability.

With a shared understanding of the Stand-down objective(s), the planning team used a liberating structure to capture anticipated threats and the resources needed to overcome those threats, and reviewed lessons learned from previous events that were similar to a Stand-down. A Stand-down plan was formed in less than 35 minutes where each planning team member knew who would have to do what by when to ensure flawless Stand-down execution.

Stand-down Execution

The Stand-down included in-house subject matter experts and one external trainer with 35+ team members in one room for 6.5 hours. Team members treated the Stand-down as an offsite, declining all meetings and turning on their Outlook out-of-office replies. Team members were randomly assigned to one of two Stand-down teams as determined by the type of gift card they received when they entered the Stand-down room. Two additional gift cards were given to all participants for the purpose of regifting —team members were encouraged to give away their gift cards to other team members for any reason. Team members were warned that over lunch (provided by the company) they may be called upon to share with everyone to whom they gave a gift card to and why. The CIO provided an impromptu leadership moment which included the distribution of additional gift cards to team members who were nominated by their peers.

500%

An outcome of the event was an increase in productivity by 200% to 700% depending on the metric used (e.g. story points, stories done, stories in progress and stories done, etc.). However, it is likely, based on stories “done” during the Stand-down, 26, versus average stories completed during a normal sprint day, 5, the increase in productivity was 500%. In one day.

For argument’s sake, let’s just say the productivity outcome for this one day event was 20%, a palatable number for those who have not embraced the power of Scrum or empowered execution. What if we could take the lessons learned from this event and apply them to how we work during our normal workdays to get a productivity increase of 5% in the next two weeks?


Sprint Stand-down Lessons Learned

Shared Purpose/Objective

  • A team needs a shared purpose or common objective. Objectives should be clear, measurable, achievable, and aligned to a focus area, strategic line of effort, company vision, etc.
  • A shared purpose builds unity of effort. Teams were observed self-organizing throughout the day and reported a reduction in duplication of work and an increase in cross-team knowledge-sharing.

 Workload Management/  Limit WIP

  • Limit WIP. Individuals reported being happier as they felt part of a team of teams working toward one goal.
  • Context Switching is bad. Most team members reported that they did not check their email during the six hours. Team members reported that the internal Stand-down disruptions (we played music during frequent shout-outs) slowed them down and were absolutely disruptive.
  • Protect the teams from out-of-band work. Team members reported that they had no out-of band work during the day.
  • Empower team members to push back on work that is not aligned to the objective.
  • Pairing works. Teams paired all day. Some mobbed.

Leadership

  • Say “Thank You.” Team members should recognize and acknowledge the importance of others in task performance.
  • Leaders need to be visible but not intrusive. Checking-in to say “thank you” to individuals carries more weight than email.
  • An invisible leader is a visible problem. Team members noticed those leaders who failed to stop by to see how the day was progressing.
  • Unscripted leadership is the best kind. The CIO’s visit was received as genuine.
  • Recognition from leaders is great, but peer recognition of important contributions is even better.

 Execution Rhythm or Cadence

  • Stand-down tempo is not sustainable but the practice is sound when a knowledge gap exists.
  • Stand-downs should not exceed six hours.
  • Schedule Stand-downs as required. No more than once a month.

Communication

  • Face-to-face communication remains the gold standard.
  • Keep work visible. The teams shared one electronic backlog.
  • Co-locate teams to maximize the value of osmotic communication.
  • Cross-team pollination builds trust.

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.

Share This:

What Agile Teams Can Learn from Flight Crews

Small, cross-functional teams working together with devices, focused on a shared objective, surrounded by complexity and frequently changing conditions. Welcome to the world of software development. And commercial aviation. Think the similarities between software development and aviation end here? Think again.

Aviation continues to have a profound influence on software development, organizational agility, cyber security, and transforming managers into leaders. For example, the complexity-busting framework, Scrum, used by technology companies to build complex software, comes from fighter aviation and Lean manufacturing. The Lean Startup, a popular business-model framework used by today’s hottest Silicon Valley startups, is based on John Boyd’s OODA Loop, an empathy-driven decision cycle that captures how fighter pilots “get inside” their opponent’s decision cycle to gain a competitive advantage.  Similarly, OODA (Observe, Orient, Decide, Act) is used to rapidly design products and in the burgeoning business of cyber security. On the management front, aviation is reported to be the inspiration behind the Holocracy movement, a social system where authority and decision-making are distributed throughout self-organizing teams. But you already knew all of this, right?

Next Time You Fly on a Commercial Carrier…

Commercial aviation flight deck and cabin crews follow the empirical process of plan, communicate, execute, and assess on each leg of their assigned trip (mission). Similarly, software developers around the globe follow the same empirical process found in Scrum—Sprint Planning (plan), Standups (communicate), Sprint Execution (execute), Review and Retrospective (assess). A sprint or iteration is a time-boxed mission (one to four weeks long) where potentially shippable software is delivered. With empowered team members and solid execution, Scrum builds a culture of continuous learning and innovation.

There’s more?

The human interaction skills needed on the flight deck and on software development and business teams are exactly the same; these cognitive and social skills include empathy, collaboration, discipline, communicationleadership, situation awareness and teamwork. Moreover, the silent killer found in the cockpit is also the top threat among software development and business teams.

Slow and insidious, poor Workload Management is the silent killer. However, software developers and Lean experts refer to Workload Management as Work in Progress (WIP). When business and software teams try to do too much (too much WIP), or do not have a shared purpose or objective, rapid value delivery (effective productivity) and quality decreases—detriments to business survival.

Prioritization of work in and out of the cockpit is an imperative but flight deck and cabin crews have a marked advantage over software and business teams: flight crews are trained on the effective use of all available resources needed to complete a safe and efficient flight; software and business teams are not. The non-technical skills training flight crews receive is called Crew Resource Management (CRM) and Threat and Error Management (TEM).

CRM, affectionately known as “Charm” school, teaches the cognitive and social skills individuals need to be part of high-performing teams in complex, rapidly changing environments. TEM is a human-system approach to building habits and skills team members need to manage threats and errors within complex operating environments.

What if technology teams applied the cognitive and social lessons learned from CRM and TEM to the world of software development?

Instead of “Scaling Agile,” what is needed is a Crew Resource Management- and Threat Error Management- influenced Agile Operating System–a system that builds leaders and empowers teams and individuals at every level. This operating system should enhance Scrum through a simple, repeatable, proven, and scalable set of interconnected and interdependent planning, communication, execution, and assessment processes that drive innovation, create leaders, and build a continuous learning culture. Think of this human operating system as the non-technical skills teams need to overcome complexity—those skills that flight crews have burned into muscle memory.

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.

(c) Can Stock Photo

Share This:

“Charm School” – The 9th Reason Your Next Agile Coach Should Be a Fighter Pilot

It has been a year since I wrote my first LinkedIn article, 8 Reasons Why Your Next Agile Consultant/Coach Should be Fighter Pilot, and although I still stand behind the original article, I have to admit I overlooked the most the important reason why you should hire a former fighter pilot to lead your agile transformation: “Charm School.”

As I was reading From Command to Team, one of the best chapters in General Stanley McChrystal’s new book, Team of Teams: New Rules of Engagement for a Complex World, I realized the most important leadership practices I learned in tactical aviation—group dynamics, leadership, interpersonal communication, and decision making—were missing from my 2014 list. Fortunately, the special operators who wrote Team of Teams recognized the value aviation “Charm School” has in how small teams should operate in complex environments and, thankfully, included the lessons learned from aviation in how they operated, and still do, as high-performing teams in near chaotic conditions [1].

What is “Charm School?”

CRM aims to foster a climate or culture where the freedom to respectfully question authority is encouraged.

In the most general sense “Charm School” or Crew Resource Management, also known as Cockpit Resource Management (CRM), is a system of simple training procedures focused on the cognitive and interpersonal skills needed to lead in complex environments.  According to Wikipedia, “the primary goal of CRM is enhanced situational awareness, self-awareness, leadership, assertiveness, decision making, flexibility, adaptability, event and mission analysis, and communication. Specifically, CRM aims to foster a climate or culture where the freedom to respectfully question authority is encouraged. It recognizes that a discrepancy between what is happening and what should be happening is often the first indicator that an error is occurring.”

An Example: Applying CRM Lessons to Delivering Digital Products

The other day a project manager (PM) wanted to discuss with me why members of two teams were not aligned on a new approach to delivering a product—an approach which was disseminated 24 hours earlier via email, an email which “everyone should have read.” Putting this command and control approach aside, I mentioned to the PM that just because an email was sent and read, it does not mean it was understood. Using lessons learned from “Charm School” I explained what this fire and forget approach to communication would look like in a cockpit of a commercial airliner.

Imagine you are a passenger on a flight from San Diego to Hawaii and flying your 757 today is Pilot A, a crusty command and control, my-way-or-the-highway manager. If Pilot A is in control of the aircraft (flying the aircraft) and turns to Pilot B and says, “You have control of the aircraft,” and pilot B does not hear or respond to Pilot A’s communication,  who is flying the aircraft?

In the example above, would you want to be a passenger on this flight or any aircraft knowing this is how pilots communicate? (Unfortunately, this is probably how most people in your organization communicate.) The good news is all pilots are required to go through “Charm School” so they can learn how to communicate with internal and external team members in their technical and complex environment. However, even with CRM, human error remains the cause for around 80% of aircraft accidents—are you ready for autonomous flying vehicles now?

Back to your digital product. From the Agile Manifesto, we know “the most efficient and effective method of conveying communication to and within a team is face-to-face conversation.” However, leaving the team to “figure it out,” the organic approach to building self-organized teams, is absolutely absurd given what we know about human behavior. Instead of recreating the wheel, teams can accelerate their agile journey by incorporating leadership practices from aviation “Charm School.” These individual and team practices include how to:

  • Establish Team Goals
  • Monitor the internal and external environments for threats (to include poor teamwork)
  • Cooperate and communicate
  • Establish feedback practices
  • Learn from failure, rather than adopting a failure-avoidance culture
  • Build a shared mental model, organizing knowledge in meaningful patterns (adopt repeatable, self-similar processes in planning, stand-ups, & retrospectives)

Here are a few practical steps to get you started with better CRM today:

  • Communicate face-to-face, following-up with a email only when necessary.
  • Encourage discussion, questioning, and debate – you might learn something yourself.
  • Respect the thoughts and opinions of the other people on your team, even when you disagree – the stronger argument, not the person with the most authority, wins.
  • When in doubt, seek advice – everyone needs a skilled wingman.

Organizations that are adopting an Agile approach to combat complexity will find solutions to their networked teams’ communication, leadership, decision making and situational awareness challenges in aviation’s CRM, a.k.a. “Charm School.” After all, two of the most recognizable approaches or frameworks to becoming Agile have fighter aviation origins.

Your next Agile Coach should be a fighter pilot.

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.

[1] McChrystal, S. A., Collins, T., Silverman, D., & Fussell, C. (2015). Team of teams: New rules of engagement for a complex world.

[2] Reynolds, R., Blickendderfer, E. (2009) Crew Resource Management and Shared Mental Models: A Proposal.  Journal of Aviation/Aerospace Education & Research, 19(1), 15-24.  Downloaded from http://commons.erau.edu/cgi/viewcontent.cgi?article=1380&context=jaaer

Photo Courtesy of Team Oracle, 2004.

Share This:

High-Performing Teams: Four Lessons From the Blue Angels

What do Seattle area technology companies and the U.S. Navy Flight Demonstration Squadron (Blue Angels) have in common? Aside from the fact that Seattle’s tech community and the Blue Angels continue to “Crush It” when it comes to delighting their customers, there is a deeper, relatively unknown bond that connects Seattle’s techies to the six Boeing F/A-18s they will see performing over Lake Washington this weekend.

Software and business teams including those at Capital One Investing, Alaska Airlines, Amazon, Tableau, Expedia, Nordstrom, Microsoft, T-Mobile, Qumulo, REI, Starbucks, Boeing, Getty Images,  and Wikispeed are using Scrum, the complexity-busting, productivity super weapon inspired by fighter aviation to help them rapidly deliver products to their customers in today’s turbulent market.

So how does Scrum connect to the Blue Angels? That’s easy. According to Dr. Jeff Sutherland, the co-creator of Scrum, “Scrum is based on [his] experience flying F-4 Phantoms over North Vietnam.” Furthermore, Scrum is not about software development but is a simple framework designed to fight complexity. Dr. Sutherland recognized the cognitive challenges faced in the technical and near chaotic environment of fighter aviation are the same as those faced by knowledge workers. Just as the Blue Angels plan, brief, execute, and debrief each performance and practice, Scrum teams in Seattle follow the same empirical process in each of their sprints.

So what else can Scrum and other small teams learn from the Blue Angels? The list is long but here are four lessons to consider over this airshow weekend.

1. Unstable Systems (Teams) are the Most Agile 

The Blue Angels are not an unstable bunch, as far as I know, but the Boeing F/A-18s they fly are inherently unstable. Unstable aircraft are highly maneuverable (agile) but require a skilled pilot and onboard flight computers (a management system) to coordinate the movement of the various flight control surfaces during routine and dynamic flight. Similarly, according to the authors of Team Genius: The New Science of High-Performing Organizations, unstable or volatile teams (the central paradox of teams) are the most productive and successful when held together by a skilled leader [1].

Bottom Line: Diverse teams, when led by a skilled leader, are the most agile. 

2. Team Size

The two pizza rule made famous by Jeff Bezos is a nice heuristic to describe the ideal team size—usually around 6-8 people. The Blue Angels fly in a formation of six but have eight customer-facing core members whose combined appetite will break the Amazonian two pizza rule—naval aviators can eat a lot. The optimum team size, according to current research, is 5-7 members but effective teams have 4-9 members [2].

Bottom Line: The ideal team size is 4-9 members.

3. Pairing

Imagine losing 50% of your team each year…all at the same time. Will you be able to deliver at the same level your customers are used to?  At the end of this season, CAPT Tom Frosch, the current Blue Angel #1 and team leader will be replaced by CDR Ryan “Guido” Bernacchi.  In addition to having a new leader in 2016, the team will add a new #3 and #6 while the current #3 moves to #4 and current #6 moves to #5. So how does the team deal with this much change? They have smaller pizza parties.

Early in the season, before the team flies in a Diamond (four-ship) or Delta (six-ship) formation, the team will break into smaller teams, or pair-teams. Blue Angel #2 will coach his boss on how to lead the formation. Blue Angel #4 (the old #3) will coach his replacement while learning a new position. And Blue Angel #5 (the old #6) will train the incoming #6. By pairing, veteran team members serve as advisers and transfer knowledge to new members through open and honest criticism in and out of the debrief.

Bottom Line: Pairs are the “basic bricks from which the edifices of larger teams are built [2].”

4. The Power of Proper Debriefing

The most important event in any continuous improvement or innovation cycle is the debrief (retrospective).  At the end of each and every flight, the Blue Angels follow the same debrief process where they leave their rank and egos at the door and focus on what is right, not who is right. You will not find Post-it notes or a ScrumMaster facilitating their debrief. Instead, team members will follow the same proven debriefing process they have been using their entire careers. This complex team learning process (debrief) builds culture, team resiliency, and improves future execution.

Bottom Line: Learn how to conduct a debrief and stop playing retrospective games.

Conclusion

Fighter aviation has a profound influence on how Scrum and high-reliability organizations approach their day-to-day work. Unfortunately, some people who want to build high-performing teams using Scrum (or other agile frameworks) continue to deny or discount that the many lessons learned in fighter aviation can and should be applied to their practice. According to a recent BBC report, psychologists recognize that human behavior is the same across technical environments, and applying the lessons learned from aviation will help mitigate group cognitive biases in any organization.

Ready Break. Ready Roll.

Brian “Ponch” Rivera is a recovering Naval Aviator, a 2003-2004 F-14 Demonstration Team Member, 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] Rich Karlgaard & Michael  S. Malone. Team Genius: The New Science of High-Performing Organizations (Harper Business, 2015).  Pg. 74

[2] Rich Karlgaard & Michael S. Malone. Team Genius: The New Science of High-Performing Organizations (Harper Business, 2015).  Pg. 97

BBC report: http://www.bbc.co.uk/programmes/p02x3vwh

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: