Tag Archives: Scrum

A Shallow Dive Into Chaos: Containing Chaos to Improve Agile Story Pointing

In May 1968 the U.S.S. Scorpion (SSN-589), a Skipjack-class nuclear submarine with 99 crewmembers aboard, mysteriously disappeared en route to Norfolk, VA from its North Atlantic patrol. Several months later, the U.S. Navy found its submarine in pieces on the Atlantic seabed floor. Although there are multiple theories as to what caused the crippling damage to the submarine, the U.S. Navy calls the loss of the Scorpion and her 99 crew an “unexplained catastrophic” event [1].

The initial search area stretched across 2,500 NM of Atlantic Ocean from the Scorpion’s last known position off of the Azores to its homeport in Norfolk, Virginia. Recordings from a vast array of underwater microphones reduced the search area down to 300 NM. Although technology played an important role in finding the U.S.S. Scorpion, it was the collective estimate of a group that eventually led to the discovery of the destroyed submarine. The U.S.S. Scorpion was found 400 nautical miles southwest of the Azores at a depth of 9,800 ft., a mere 220 yards from the collective estimate of the group [2].

The group of experts included submarine crew members and specialists, salvage experts, and mathematicians. Instead of having the group of experts consult with one another, Dr. John Craven, Chief Scientist of the U.S. Navy’s Special Projects Office, interviewed each expert separately and put the experts’ answers together. What’s interesting about the collective estimate is that none of the expert’s own estimates coincided with the group’s estimate—in other words, none of the individual experts picked the spot where the U.S.S. Scorpion was found.

A Quick Lesson in Chaos

According to Dave Snowden, Chaos is completely random but if you can contain it, you get innovation. You do this by separating and preventing any connection within a system. And when done properly, you can trust the results. Skunk Works projects and the Wisdom of Crowds approach made popular by James Surowiecki are great examples of how to contain Chaos [3].

Dr. Craven’s approach to finding the U.S.S. Scorpion is a controlled dive into Chaos; preventing any connections within the group, protecting against misplaced biases. Moreover, by bringing in a diverse group of experts, Dr. Craven ensured different expert perspectives were represented in the collective estimate.

To contain Chaos, three conditions must be satisfied [4]:

1. Group members should have tacit knowledge—they should have some level of expertise

2. Group members must NOT know what the other members answered

3. Group Members must NOT have a personal stake

Story Point Estimates: Taking a Shallow Dive into Chaos

Agile software development teams frequently estimate the effort and complexity of user stories found in their product and iteration backlogs. Individual team members “size” a story by assigning a Fibonacci number to a story based on their own experiences and understanding of the user story. A point consensus is not the aim but, unfortunately, is frequently coached and practiced.

To reduce cognitive biases, contain Chaos, and accelerate the story pointing process, AGLX trains and coaches clients’ software development teams to ask the product owner questions using various Red Teaming techniques, to include Liberating Structures. Once all team members are ready to assign points to the story, team members place their selected Fibonacci card or chip face down on the table.

On the “Flip” in “Ready…Flip,” team members turn their cards over and the ScrumMaster rapidly records the individual points. When all points are registered, the ScrumMaster takes the average of the points scored and assigns that number to the story (rounding to the nearest integer, if desired). No need to waste time re-pointing or trying to come to a consensus.

Example. A six-person software development team assigns the following individual points to a story.

Cards

The average is 6.5 (7 if rounding). In this example, none of the individual estimates match the group’s estimate. And, the group’s estimate is not a Fibonacci number.

In some High-Performing Organizations where psychological safety is well established, some development teams will have the team members who pointed the story with a 3 and 13 (using the example above) to present their reasoning using a complex facilitation technique—time-boxed, of course. The point behind this ritual is not to re-point the story but to have team members listen to the story outliers or mavericks for the purpose of identifying possible insights. Caution: This is an advanced technique.

Innovative and Resilient Organizations

Containing Chaos requires expert facilitation and will not happen overnight. However, simplifying your story pointing approach by not allowing consensus or team consultation (Condition 2) when it comes to story pointing is a small step to becoming an innovative and resilient organization—if that is what the organizations desires.

Although the loss of the U.S.S. Scorpion and her 99 crew was a tragedy, by sharing the story of how the collective estimate of a group of diverse experts found the submarine on the seabed floor is a great example of the power of cognitive diversity and containing Chaos.

Brian “Ponch” Rivera is a recovering naval aviator, co-founder of AGLX Consulting, LLC, and co-creator of High-Performance Teaming™ – an evidence-based, human systems solution to rapidly build and develop networks of high-performing teams. Contact Brian at brian@aglx.consulting.

[1] Sontag, Sherry; Drew, Christopher (2000). Blind Man’s Bluff: The Untold Story of American Submarine Espionage. New York:

[2] Surowiecki, James (2005). The Wisdom of Crowds. Anchor Books. pp. xv. ISBN 0-385-72170-6.

[3] Snowden, D.  KM World 2016 Keynote.  http://cognitive-edge.com/resources/slides-and-podcasts/

[4] Ibid

Share This:

Kanban vs. Scrum: Why This Argument is Futile

Kanban is a Group Tool or Group Methodology.

Scrum is a Team Framework.

Confused about the difference?  It all has to do with the definition of a team. The Agile community loves to talk about teamwork and teams but does not share a common definition of a team. Is this a problem? It is if you are trying to coach a group of people to function as a team when their work/tasks have a low level of interdependency.

Team

A distinguishable set of two or more people who interact dynamically, interdependently, and adaptively toward a common and valued goal/ objective/ mission [1].

Kanban

Kanban is a great group methodology that allows you to start where you are and focus on flow. However, Kanban is not time-boxed like a sprint in Scrum. Why does this matter? Look at the second part of the above definition of a team: “…shared and valued goals/objective/mission” imply time. Think back to SMART goals (by-the-way I hate SMART goals). Can you have a goal to lose 10lbs without a time-box? You can in Kanban. I’m on that diet now and I have not lost a pound.

Scrum

Scrum is a great team framework that exists in its entirety and is a container for other practices, techniques, and methodologies. You can use elements of Kanban in Scrum without renaming Scrum as long as Scrum exists in its entirety (three roles, five events, three artifacts).

Scrum is ideal for a set of two or more people who work interdependently toward a common goal. But hold on a minute, we all know that there are three roles in Scrum. So does a two-person Scrum team violate the definition of Scrum?

But there’s more…

According to research conducted by R. Wageman, placing a team framework on people whose work or tasks have a low-level of interdependency is a bad idea [2]. There is danger in thinking a pull system designed for the simple domain can be applied as a framework for teams who work in the complicated, complex and chaotic domains.

Bottom line

Kanban is a great group methodology and Scrum is a great team framework.  They are not perfect, they have flaws, but knowing where to use them is as simple as understanding what a team is and what a team is not.

 

Brian “Ponch” Rivera is a recovering naval aviator, co-founder of AGLX Consulting, LLC, and co-creator of High-Performance Teaming™ – an evidence-based, human systems solution to rapidly build and develop networks of high-performing teams. Contact Brian at brian@aglx.consulting.

References

[1] Salas, Eduardo; Stephen M. Fiore; Letsky, Michael P. (2013-06-17). Theories of Team Cognition: Cross-Disciplinary Perspectives (Applied Psychology Series) (Kindle Locations 7794-7796). Taylor and Francis. Kindle Edition.

[2] “But if managers inadvertently create hybrid groups by importing group processes into a high-performing system with individual tasks and reward systems, they may find that what they have actually have brought in is a Trojan Horse.” Wageman, R. (1995). Interdependence and Group Effectiveness. Administrative Science Quarterly, 40(1), 145-180. doi:1. Retrieved from http://www.jstor.org/stable/2393703 doi:1

Share This:

7 Ways to Hack Your Daily Stand-up to Create Psychological Safety

Data from Google’s Project Aristotle, a multi-year study of why some of the company’s teams were successful while others were not, revealed that psychological safety is the secret sauce behind its highest performing teams. (Psychological safety, according to Julia Rozovsky, an analyst with Google People Operations, is the dynamic that addresses: “Can we take risks on this team without feeling insecure or embarrassed?”[1])

But the multi-million dollar, 180-team study did not provide details as to how psychological safety is created. Fortunately, this teaming “discovery” by Google is not new. Thanks to human factors research in aviation and health care, creating psychologically safe environments is relatively simple — though not necessarily intuitive.

A psychologically safe environment cannot be established by simply proclaiming: “This is a safe environment.” And, as far as I know, Google does not possess a magic wand. Psychological safety, according to Amy Edmondson, a professor of leadership and management at Harvard Business School, must be created by leaders through simple behaviors and actions. Those leaders include perceived, functional and, most importantly, managers in the middle of the organization.

Before introducing key behaviors and actions that promote a psychologically safe environment, leaders should understand the benefits of establishing this critical condition that enables individuals working in groups to rapidly transition to becoming members of high-performing teams.

Psychological safety[2]:

  • Encourages speaking up
  • Enables clarity of thought
  • Supports productive conflict
  • Mitigates failure
  • Promotes innovation
  • Removes obstacles to pursuing goals for achieving performance
  • Increases accountability

Your daily stand-up is the perfect place to create a high-performance, psychologically safe environment for the team. As a leader, you can accomplish this by [3]:

  1. Being accessible and approachable. (Yes, managers are encouraged to attend Scrum events)
  2. Acknowledging the limits of current knowledge
  3. Being willing to display fallibility
  4. Inviting participation and valuing input
  5. Highlighting failures as learning opportunities
  6. Using direct language
  7. Setting boundaries

These seven key behaviors and actions will help you establish a psychologically safe environment for your team – no magic wand needed.


Practical Application to Daily Stand-ups (Scrum) and Your Typical Ineffective Meetings

Most Scrum teams blindly follow The Scrum Guide’s approach to stand-ups, where each team member answers the following three questions:

  1. What did I do yesterday to help the team meet its goal?
  2. What am I doing today to help the team meet its goal?
  3. What impediments are in my or the team’s way of meeting the goal?

Yuck!

This three-part daily Scrum Q&A is a recipe for a status update — which is not the intent of the daily Scrum, but is its typical outcome. To avoid this, and to create psychological safety during the daily Scrum, the event instead needs to be viewed as a re-planning session.

Below is an example stand-up and script that follows an effective planning process and provides several opportunities to display the behaviors and actions needed to create psychological safety.

Big Picture

“Good morning, team. It is 9:15. Today is May 6, the third day of Sprint. Our Sprint objective is to deliver the grommet and flipperdoodle functions for our elite users so they can bypass the ninth stage of zoom and provide us with rapid feedback. We have 12 stories with 68 points that support our objective. Our team goals are to use ATDD on 70 percent of our stories, practice closed-loop communication using SBAR, and to have at least four different team members other than the ScrumMaster lead the daily stand-up.”

With the big picture approach, we just created an opportunity for the person leading the stand-up to be viewed as approachable. We also established boundaries by starting on time (ending on time is equally important). Moreover, we repeated shared and common objectives and goals — the Sprint objectives are customer-centric and the goals are focused on teaming.

Failure Check

“Does anyone have a quick, individual failure from yesterday or today that you would like to share with the team?”

This is a great time for a manager, product owner, or functional leader to admit a failure, or show fallibility, in front of the team. Keep it short, 30 seconds or less. For a manager who is attending the stand-up, this is the only opportunity you have to talk until post stand-up.

Impediment Share-out

“What impediments, dependencies, or threats are going to keep us from achieving our Sprint objective and team goals today?”

This step invites participation and allows the team to build off of each other’s impediments. The idea is to share impediments, perceived or actual, and park them until all impediments are heard. There should be no discussion about individual impediments until the impediment popcorn stops popping and the team moves to the next step. The ScrumMaster will act as a scribe. Warning: This approach will uncover more impediments than The Scrum Guide’s stand-up process.

Plan of the Day

“What are you doing today to overcome the impediments and move us closer to achieving the Sprint objective and team goals?”

This question invites additional participation, where team members are free to use the information radiator and talk about what they plan to do today and with whom. They will also use this time to quickly discuss what they can do to overcome or remove team impediments. Each member is invited to talk and may include information from what they did yesterday. This is the re-planning part of the stand-up. Realize that this is just the start to the day’s conversations.

Adaptability Plan (or the What If? Plan)

If there are any leftover impediments that the team or ScrumMaster cannot solve, then the team should develop a “what if” plan. For example, Mike’s spouse is expecting and may deliver their first child during this sprint. By definition, this is an impediment to achieving the Sprint objective. The team should build a “what if” plan around Mike’s potential departure. Make sure to invite participation.

When you view the daily stand-up as a re-planning session, you’ll get more than just a status update — you’ll create a psychologically safe space for your team to reaffirm objectives and goals, identify impediments, and most importantly, create a plan for action.

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

References:

[1] Duhigg, Charles. Smarter Faster Better: The Science of Being Productive in Life and Bussines. Random House. Apple iBooks Edition

[2] Edmondson, Amy C. Teaming: How Organizations Learn, Innovate, and Compete in the Knowledge Economy. Wiley. Apple iBooks Edition.

[3] Ibid

Share This:

OODA: The Mindset of Scrum

Recently, a trusted source reported that the Oracle of Scrum, Jeff Sutherland, has proclaimed that OODA is the Mindset of Scrum.  A few weeks ago I tried my best to explain this “Mindset” when I co-coached with Joe Justice during his Scrum in Hardware – Train the Trainer course. It was a daunting task considering I was surrounded by some of the world’s finest Scrum Trainers and Agile Coaches and was asked to deliver the “Origins of Scrum” using Scrum, Inc.’s slide deck. Not easy.

Knowing that much has been written about the connection between Scrum and OODA including Steve Adolph’s 2006 paper, What Lessons Can the Agile Community Learn from A Maverick Fighter Pilot, I decided to spend my limited presentation time focused on two lesser known features of OODA: empathy and fast transients. Before rolling-in on these two features, here is a quick-and-dirty introduction to OODA and Scrum.

OODA and Scrum

Over the skies of Korea, years before Jeff Sutherland and his RF-4C’s Weapons System Operator’s (WSO) flight plans were constantly disrupted by North Vietnamese gunfire, SAMs, and fighters, John “40-Second” Boyd was trying to understand how a seemingly inferior aircraft, the American built F-86 Sabre, had a kill ratio of 10:1 over the nimbler, more agile MiG-15. As an F-86 pilot who regularly engaged with MiG-15s, Boyd realized that it was the F-86’s bubble canopy that provided American pilots better situational awareness (the ability to better observe and therefore process reality) over MiG-15 pilots. It was from fighter combat, a 1 v 1 dogfight (a socio-technical system vs. a socio-technical system) that the Observe-Orient-Decide-Act (OODA) Loop was born.

According to Jeff Sutherland, Scrum’s origins are in OODA and hardware manufacturing, not software. In fact, for those of you who are Lean Startup practitioners you may want to adopt OODA as your mindset as well considering the Lean Startup is based on OODA. Similarly, Cyber Security borrows from Boyd’s OODA Loop as do several product design approaches.  Back to Scrum.

Scrum is widely practiced by software development teams but is applicable across the routine-complexity-innovation continuum. For example, in the past two weeks, I coached Scrum to a world-class surgical center, an aerospace giant’s flight test team, and a geographical combatant command (GCC). Best place to learn about scrum is the 16-page Scrum Guide. If you happen to fly fighter or commercial jets, then it should not surprise you that CRM is applicable to coaching Scrum…but that’s another story.

OODA: The Mindset…

As I had limited time during my “Origins of Scrum” presentation, I decided to focus on empathy and fast transients, two lessor known characteristics of OODA.

Empathy: Get inside the mind of your customer

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 proposes that “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.” (Page 96) In his 1995 briefing, The Essence of Winning and Losing, John R. Boyd points out that analysis and synthesis are dependent on implicit cross-referencing across different domains including empathy.

Fast Transients: The organization that can handle the quickest rate of change survives

The ability for your organization to transition from one state to another faster than your competition will ensure your organizations survival. Moreover, “Fast Transients” will bring confusion and disorder to your competition as they under or over react to your activities.

Orientation is Schwerpunkt (focal point)

Orientation is the “genetic code” of an organism and cognitive diversity is key to creating innovative solutions to complex problems.

Focus on Feedback Loops

One feature of complex adaptive systems are feedback loops. Learn how to provide feedback. Effective retrospectives are a great start.

Leverage Uncertainty

We live in a Volatile, Uncertain, Complex and Ambiguous (VUCA) world.

Agility is Adaptation with a Time Scale

Adaptability is a cognitive skill found in High-Performance Teaming™ and Crew Resource Management. Agility is adaptability with a time scale and that time scale is rapidly shrinking.

Non-Linear Systems Have Inherently Identical Structures

When looking for solutions to problems, look outside your industry. The future already exists.

I look forward to your feedback and comments.

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.

Share This:

17 Ways to Stop Your Organization’s Agile Transformation

In 1944, the Office of Strategic Services (OSS), now known as the Central Intelligence Agency (CIA), published the Simple Sabotage Field Manual which provides organizational saboteurs—let’s call them managers and employees who are on the wrong bus—a guide on how to interfere with organizational development and transformation.

As an Agile and High-Performance Teaming™ Coach, I have observed the following 17 tactics found in the Simple Sabotage Field Manual skillfully employed by managers and employees who clearly do not want their organizations to survive and thrive in today’s knowledge economy:

  1. When training new workers, give incomplete or misleading instructions.
  2. To lower morale and with it, productivity, be pleasant to inefficient workers; give them undeserved promotions. Discriminate against efficient workers, complain unjustly about their work.
  3. Hold [meetings] when there is more critical work to be done.
  4. Demand [documentation].
  5. “Misunderstand” [documentation]. Ask endless questions or engage in long correspondence about such [documents]. Quibble over them when you can.
  6. Make “Speeches.” Talk as frequently as possible and at great lengths.
  7. Bring up irrelevant issues as frequently as possible.
  8. Insists on doing everything through “channels” [and email].
  9. When possible, refer all matters to committees, for “further study and consideration.” Attempt to make the committees as large as possible–never less than five.
  10. Spread inside rumors that sound like inside dope.
  11. Contrive as many interruptions to your work [and team] as you can.
  12. Do your work poorly and blame it on bad tools, machinery, or equipment.
  13. Never pass on your skills and experience to anyone.
  14. If possible, join or help organize a group for presenting employee problems to the management. See that procedures adopted are as inconvenient as possible for the management, involving the presence of large number of employees at each presentation, entailing more than one meeting for each grievance, bringing up problems which are largely imaginary, and so on.
  15. Give lengthy and incomprehensive explanations when questioned.
  16. Act stupid.
  17. Be as irritable and quarrelsome as possible without getting yourself into trouble.

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.

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:

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:

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:

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:

“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: