Category Archives: Leadership

Organizational and team leadership

How to Develop a Family Hurricane Checklist Using Military-Grade Planning

Concepts Applied in This Post: Red Teaming; complex adaptive systems; Sensemaking; High-Reliability Organizing; Mindful Organizing; Principles of Anticipation; Situational Awareness; Anticipatory Awareness; Mission Analysis; Shared Mental Models; Mission Command; Commander’s Intent; ; Cynefin; vector-based goals; challenge and respond checklists; and establishing a sense of urgency.

This post outlines how families can apply some elements of military-grade planning to develop a hurricane checklist. Moreover, this post also applies to business leaders interested in real agility, innovation, and resiliency.

The Rivera girls reviewing the plan

Background

With last week’s devastation in Houston on our minds and the looming threat of Hurricane Irma in the Atlantic, I thought it would be prudent to take my family through some basic hurricane preparedness planning. To do this, I decided to take my wife, six-year-old and soon-to-be eight-year-old daughters through the same military-grade agility, innovation, and resiliency lessons that I coach to FORTUNE 100 companies and startups. After all, a family is a team and a hurricane is a complex adaptive system, right?

This activity ended up providing valuable lessons for the entire family and as a result, we delivered a challenge and response checklist, reviewed and re-supplied our emergency kits, and more importantly, we became more aware of capabilities and limitations of the socio-technical system we call our home.

Feel free to apply the approach to your household or business.

Focus on Outcomes

To start the activity, begin with a basic statement, a vector-based goal that inspires action. The outcome statement I used:

Survive for five days in our house during and following a major hurricane

Notice that my Commander’s Intent does NOT contain a clear, measureable, achievable objective or SMART goal. Why?  Because we are dealing with complexity; we cannot predict the future in the Complex domain. When dealing with increasing volatility, uncertainty, complexity, and ambiguity (VUCA), emergent goals are fine, as you will see.

Effective Planning

Knowing that plans are nothing and that planning is everything, I used a military-grade planning approach to help the girls understand the system we live in, the wonders and dangers of a hurricane, and their roles in the event of a hurricane. To do this, I asked the girls to write down those things that may happen during a hurricane.

Anticipate Threats

Complex adaptive systems and high-performing teams anticipate the future. One of the common planning problems I see with executive and development teams is they fail to identify threats and assumptions (do not anticipate the future) prior to developing their plan. To help the girls understand this critical step, I asked the them to write down “what” can happen in the event of a hurricane.

Having watched the news on Hurricane Harvey, they were able to identify a few threats associated with hurricanes (e.g.  flooding, no power, damage to windows). However, just as adult team members do when they have meetings, my girls went down many rabbit holes to include discussions about Barbie and Legos. The best approach to overcome this natural phenomenon (cognitive bias) is to use the basic Red Teaming technique of Think-Write-Share.

With some steering help from mommy and daddy, our girls where able to get back on course and capture several more “whats” before moving on to the next step.

Red =Threats; Blue = Countermeasures; Green = Resources Needed.

Identify Countermeasures and Needed resources.

With the threats identified, we began to write down possible countermeasures and needed and available resources that overcome those threats.  As we were doing this, we noticed the emergence of a what appeared to be a checklist (see our blue notes in the above picture). Although not explicitly stated in the Commander’s Intent, we decided that we should add “build a checklist” –an emergent objective– to our product backlog (more on this later).

Apply Lessons Learned

“Learn from the mistakes of others. You can’t live long enough to make them all yourself.” ~ Eleanor Roosevelt

Knowing that there are many lessons learned from people who have lived through hurricanes, I went online to find and apply those lessons learned to our countermeasure and resource backlog. I used the Red Cross as a source and discovered we missed a couple of minor items in our growing backlog.

*I recommend using external sources only after you develop countermeasures to your identified threats. Why? Because planning is about understanding the system; it is how we learn to adapt to change.

After we applied lessons learned, we used a green marker to identify those needed resources (see picture). These resources became part of our product backlog.

Build a Prioritized Product Backlog

A product backlog should be prioritized based on value. Since I was dealing with children who have a low attention span but were highly engaged in the current activity, I decided to prioritized our backlog in this order:

  • Build a Hurricane Checklist
  • Review with the team (family) what is in our current emergency kit
  • Purchase needed resources
  • Show the kids how to use the kit
  • Build a contingency plan –our contingency plan details are not covered in this post.

“Scrum” It

Since I coach Scrum as a team framework, and our family is a team, I showed my children the basics of Scrum. If you are not familiar with Scrum, you can find the 16-page scrum guide here.

We used a simple Scrum board to track our work and executed three short Sprints. As a result, the girls were able to pull their work, we were able to focus on getting things done, and we identified pairing and swarming opportunities. They also learned a little about what I do for a living.

Key Artifact and Deliverable Review: Challenge and Respond Checklists

With a background in fighter aviation, and having coached surgical teams on how to work as high-performing teams, I know from experience that checklists work in ritualized environments where processes are repeatable. To create a ritualized environment, we can do simple things such as starting an event at a specified time with a designated leader. Another option is to change clothes or wear a vest—by the way, kids love dressing up.

One advantage of a challenge and respond checklist is it can be used to create accountability and provide a leadership opportunity for a developing leader–perfect for kids and needed by most adults. For example, the challenge and respond checklist we developed (above) can be initiated by one of my daughters.  If we needed to run the checklist, one of my daughters would simply read the items on the left  and mommy or daddy would respond with the completed items on the right. Giving a young leader an opportunity to lead a simple team event and recognizing their leadership accomplishments energizes their internal locus of control and utimiately builds a bias toward action.

Feel free to use our checklist as a guide but remember, planning is about understanding your system.

The Most Important Step: Debrief

Yes, a debrief with a six and seven-year-old is possible. Remember to create a learning environment for them, ask them about the goal(s) they set out to achieve, and ask them what they learned. Walk them through the planning steps they just went through to reinforce the planning process. Also, ask them what they liked and what they didn’t like about working on the plan with mommy and daddy. Bring snacks.

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 high-performing teams and organizations.

Share This:

High-Performing Teams and Complex Algorithms: Things You Don’t Have to Figure out Alone

Personally, I can’t solve long division. I don’t do algorithms, logarithms, or any other “-ithms.” I strongly dislike even having to do my taxes (and I am married filing jointly with standard deductions, no investments, no special circumstances, and no complications). I’ll be the first to admit, I’m just not that smart.

What I am is self-aware. After years of training, learning about, working in, and teaching high-performing teams, I knew there had to be reasons – very good reasons – that our techniques, tools, and methodologies all worked as well as they did. I knew there had to be something about the way we worked and the way we trained which was grounded in something other than wild guesswork, happenstance, and luck.

Indeed, as anyone who’s operated in a high-reliability organization knows, you do the things you do for very clear, proven reasons. Often, you do them because other people have died to teach you the lessons your organization has learned, helping to increase its resiliency and robustness.

Developing high-performing teams is no different!

I encounter – daily – blogs, LinkedIn posts, articles, podcasts, papers, seminars, conferences, Meetups (you get the idea) about various aspects of developing and enhancing teams and teamwork. Some are interesting and useful, but the overwhelming majority are based on personal beliefs, ideas, conjecture, experimentation, luck, a bad experience, or any of a number of other subjective, introverted, well-meaning but ultimately wrong ideas.

Don’t misunderstand – these ideas come from really smart people who are giving their absolute best, but intentions do not equate to outcomes.

Why aren’t we hiring these same people to handle our home renovation projects, build our national infrastructure, or handle international trade and defense policies? Because putting in a lot of effort and working hard is different from knowing what you’re doing.

You may be a very dedicated, hard worker, but I prefer to have an actual plumber working on my home’s plumbing, thank you.

Unfortunately, for too many organizations around the world, this is exactly what they do in building teams. They have highly intelligent professionals who are skilled in management, process and portfolio stewardship, agile frameworks and methodologies, and any number of additional things. Yet what they are not studied, or skilled at, is team-building.

To make things worse, these well-meaning individuals also believe, wrongly, that just figuring this “team-building thing” out on their own is the best, most effective course of action. To those people I want to reflect back to my earlier admission that I know my limits. You need to realize that unless you’ve been raised in a culture of team performance and team-building or have spent considerable time studying it, you probably don’t actually know as much about it as you think you do.

Rather, there is an entire world of scientific research, based in empirical studies, and grounded in human social, behavioral, and cognitive psychology, industrial – organizational psychology, human cognition, sociology, and human evolution which informs us about the social, human-interactive skills which power team behaviors, performance, and effectiveness.

There are an abundance of knowledgeable professionals who have spent most of their adult lives studying, working with, and developing great teams.

However despite that fact, organizations, leaders, and managers continue to struggle through trying to figure these things out on their own. They read an HBR article, a few blog posts, and walk away thinking “I got it.” In technology we have a huge array of protocols, structures, frameworks, processes, methodologies, tools, etc., which are intended to somehow supplant or circumvent the real and necessary process of teaching teams and individuals the social teaming skills necessary to enable them to team together effectively.

Developing great teams is not a secret, miracle, or act of individual or organizational brilliance. The science and practice of team-building is based in the fundamental makeup that accompanies being human. Ensuring teams can develop, survive, and thrive, requires the following:

  • Right Environment. Teams need to have the support necessary to enable execution, which includes clear vision/direction, prioritization, and goal-setting from leadership, a culture which enables and rewards teaming, and the ability to identify and deal with things which threaten the team’s ability to achieve its mission or purpose. It also requires leadership and concerted inputs from other teams, as well, like Human Resources and Product Management.
  • Right Skills. Teams need to be trained in the skills which enable high-performance teamwork, and that training needs to be experience-based as well as knowledge-based. They need to learn from those who have lived it, and they need to be empowered to continually learn, grow, and improve those skill-sets. Training individuals is a critically important – and oft-overlooked – key to success. Most people are not born great team players, however as with any skill, the skills which enable effective teamwork can be developed and improved over time.
  • Right Process. A team is a group of individuals working together – interdependently – toward a common and shared goal. As such, they need to have a product which unifies the team members in pursuit of that common, shared goal, and toward which they can work interdependently. They need to be able to employ a process capable of supporting their product’s domain (simple/routine – complex – innovative), and they need to be able to realize intrinsic motivators through Autonomy, Mastery, and Purpose (a la Daniel Pink).

Most importantly, you don’t need to figure out how to develop and implement all of these things yourself, and unless you’ve spent your career studying teams, teamwork skills, and team training and development, you probably do not actually possess the knowledge necessary to successfully develop these skills in your teams.

This may seem a stark presentation of reality, and perhaps a bit harsh.

We all want to think we’re great team players and we know everything there is to know about training and developing the skills necessary for teamwork. However, unless you’ve been studying teams, teamwork, and skills, and can name specific social, non-technical, non-process-related skills which enable and enhance interpersonal communication, collaboration, and creativity, you probably aren’t that knowledgeable about what teams and individuals need to develop and enhance their teamwork. As I said in an earlier post – being able to recognize great art when you see it doesn’t make you a great artist!

Instead, you can leverage the knowledge and expertise of others whose professional existence is grounded in building and developing great teams. There are a large number of people across various industries who focus and work in exactly this domain.

Instead of trying to reinvent the wheel yourself, wouldn’t it make more sense to talk to a car manufacturer who can actually help you get where you’re going?

Rather than devising or borrowing lists of protocols and processes to help you get the behaviors you desire out of individual team members, wouldn’t it make far more sense to simply train them in the skills and behaviors they need to team together effectively, provide them feedback, and enable them to execute and succeed together? The knowledge to do so is out there, resident in professionals across various industries and academia. When you find yourself confronted with these sorts of problems, I’d recommend you do what the best leaders always do…

…find and engage the best people to get the job you need done, effectively.

 

Chris Alexander (that’s me) is a former F-14 Tomcat RIO & instructor, and co-founder of AGLX Consulting, where he co-developed High-Performance Teaming™ – a training methodology focused on teaching individuals and teams the social, interactive skills necessary to help them achieve high-performance. He currently works as an agile coach at Qumulo, Inc. in Seattle, Washington.

This post originally published on LinkedIn: https://www.linkedin.com/pulse/high-performing-teams-complex-algorithms-things-you-dont-alexander

Share This:

Psychological Safety is Just One Piece of the Larger Puzzle – Where Google’s Project Aristotle Missed the Bigger Picture

Google recently released the results of a five-year study, known as Project Aristotle, through which they determined that the common attribute – or what Google termed “key dynamic” – which successful teams exhibited was something known as psychological safety.

Unfortunately, Google’s expensive, five-year foray into teamwork is a great example of what can happen when technologists undertake studies in team and cognitive psychology, human interaction, sociology, and complex adaptive systems (among other disciplines), and base their findings entirely on self-collected metrics and their own statistical analyses of that data. What Google found was that psychological safety is a statistically significant attribute (key dynamic) associated with high-performing teams, but unfortunately this doesn’t tell the full story or help other teams or organizations to understand what they need to do to create those same conditions in their own environments.

I certainly do not want to impugn or belittle the considerable efforts or discipline of the team conducting Google’s study. However, I might have suggested beginning with a review of existing research in some of those disciplines (teamwork, sociology, human behavior, cognitive psychology, etc.) relating to team performance and teamwork. As it turns out, there is quite a lot.

In fact, so much that today there are meta-studies covering these topics. Among other critical areas not studied by Google, team performance is directly tied to the number and quality of social interactions between team members [1], the existence of Shared Mental Models within the team, shared expectations regarding behavioral norms (what we call Known Stable Social Interfaces), as well as organizational issues such as the leadership and management culture.

Which isn’t to imply that psychological safety isn’t important; indeed it is. Amy Edmondson in her book Teaming points out that psychological safety is of critical importance to effective teams:

“An environment of psychological safety is an essential element of organizations that succeed in today’s complex and uncertain world. The term psychological safety describes a climate in which people feel free to express relevant thoughts and feelings without fear of being penalized…In corporations, hospitals, and government agencies, my research has found that interpersonal fear frequently gives rise to poor decisions and incomplete execution.” [2]

Psychological safety is important. Yet psychological safety is not a team skill. For example, we can teach a team and individual team members to communicate more effectively using certain techniques and behaviors. Similarly, we can train a team to communicate in more assertive ways. However, we cannot train teams to simply “be psychologically safe.”

As Edmondson states in the quote above, “psychological safety is an essential element of organizations…” (emphasis added) – it isn’t a team skill or behavior.

This critical fact is where so much of the literature, and Google’s study in particular, come up short. Knowing that successful teams operate in an environment of psychological safety does not enable leadership, management, or coaches to build psychologically safe environments any more than looking at a painting enables me to paint a replica of it.

The real challenge is determining how one can mindfully, purposefully build a psychologically safe environment within an organization. To answer this question, we need to first understand what, exactly, psychological safety is. I define the term slightly differently than many textbook definitions:

Psychological safety is the existence of an environment in which individuals proactively exercise assertiveness, state opinions, challenge assumptions, provide feedback to teammates and leadership, while openly sharing mistakes and failures.

Many traditional definitions of psychological safety make use of the term “feel,” as does Edmondson: “The term psychological safety describes a climate in which people feel free to express relevant thoughts and feelings. Although it sounds simple, the ability to seek help and tolerate mistakes while colleagues watch can be unexpectedly difficult.” [3] (Emphasis added.)

However, I purposefully make use of the word “exercise.” Although this may seem a semantic difference at first glance, since we’re concerned with factors such as team performance, quality, and effectiveness, the existence of a psychologically safe environment in which no one actually admits mistakes or states opinions (although they feel free to) is undesirable. We need not only the environment, but also the actual actualization of the skills and behaviors necessary to realize the environment’s benefits.

How to build psychological safety in teams and organizations.

Although I’ve only glossed over the considerable amount of theory and research, I also don’t want to try to provide a Reader’s Digest version of decades of knowledge here. I’d rather get right to the point. What do leaders, managers, coaches, and teams need to do to purposefully build psychological safety in their environment, today?

First, significantly reduce the focus on processes and frameworks. The existence of a specific environment or culture is largely independent of the business process employed in an organization’s daily operations. Some frameworks and methodologies are structured to support the types of psychologically safe environments necessary to enhance team performance and effectiveness, but they do not guarantee it.

As Lyssa Adkins, author of Coaching Agile Teams, stated in her Closing Keynote at the 2016 Global Scrum Gathering in Orlando, Florida:

“I thought we would have transformed the world of work by now. People, we’ve been at this for fifteen years…Transforming the world of work is literally a human development challenge. So we are awesome, we are so good in this community at process and business agility. We’ve got that handled people, and we’ve had that handled for a while. What we’re not so good at, what I want to see us become just as great at, is human systems agility. Because that’s the other piece of it…You know, those organizations – they’re all made of humans, aren’t they? So, human systems agility is a piece of business agility. Not the only one, but an important one; and one that we’re not as good at.” [4]

Business processes and frameworks, including Agile systems such as Scrum and Lean, can only help create a structure capable of supporting the ways in which teams and individuals need to work to reach the highest levels of performance, effectiveness, and innovation. What those teams – from executive to functional – need, is a shared mental model, a Known Stable Social Interface for interacting and working collaboratively together, and which enables them to develop and exercise the interpersonal skills and behaviors necessary for psychological safety.

Leadership and management must initiate the formation of a psychologically safe environment by welcoming opinions (including dissent) on goals and strategies from peers and subordinates. People in management or leadership roles who fear questioning or are more focused on their ideas than on the right ideas need to either learn, adapt, and grow, or move on. They are obstacles, roadblocks, and hindrances to organizational effectiveness, performance, and innovation.

Steps leadership and management can take to start to create psychological safety:

  • Establish and clearly communicate expectations
  • Receive training themselves
  • Provide training for their employees
  • Ensure follow-through with dedicated coaching and regular check-ins

Then, learn about and employ the following behaviors and skills:

  • Frame mistakes and errors as learning and opportunities for improvement.
  • Encourage lessons learned to be shared instead of hidden, focused toward helping others to learn, grow, and avoid similar mistakes.
  • Embrace the value of failure for learning by admitting to mistakes they’ve made themselves.
  • Understand the difference between failures and subversion, sabotage, incompetence, and lack of ability.
  • Learn about the interpersonal, social skills which power team effectiveness, including Leadership, Communication, Assertiveness, Situational Awareness, Goal Analysis, and Decision-Making. Those skills include the explicit behaviors necessary to build psychological safety in the organizational environment.

“If I focus on using your mistake as a way to blame and punish you, I’ll never hear about your mistakes until a catastrophe ensues. If I focus on using your mistake as a way for us to learn and improve collectively, then our entire process, system, and business will be better after every mistake.”

Individuals and teams can also help to build and enable psychologically safe environments:

  • Seek training about and learn the interpersonal, social skills which power team effectiveness, including Leadership, Communication, Assertiveness, Goal Analysis, Decision-Making, Situational Awareness, Agility, and Empathy.
  • Advocate for and build a climate in which learning and improvement is possible through open and honest analysis of failures / mistakes.
  • Frame and focus discussions on the plans, strategies, and ideas supporting what is right, not who is right.
  • Assume responsibility for their own psychological safety and proactively help build it as a fundamental attribute of their teams’ work environment.

Psychological safety is a key organizational characteristic which is critical to the growth of high-performing teams. However, it isn’t a holy grail and most organizations, coaches, and consultants do not know how to purposefully create a psychologically safe environment, nor why it makes sense to do so. Yet mindfully organizing to build high-performing teams is not only possible, it is something which many organizations have been doing for decades.

 

Chris Alexander is a former F-14D Flight Officer, the co-founder of AGLX Consulting, High-Performance Teaming™ coach, Agile coach, and Scrum Master, and has a passion for working with high-performing teams. Learn more at https://www.aglx.consulting.

References:

  1. Pentland, Alex (2014­01­30). Social Physics: How Good Ideas Spread – ­The Lessons from a New Science (p. 90). Penguin Publishing Group. Kindle Edition.
  2. Edmondson, Amy C. (2012­03­16). Teaming: How Organizations Learn, Innovate, and Compete in the Knowledge Economy (Kindle Locations 1474­-76, 2139-40). Wiley. Kindle Edition.
  3. Ibid, 2141-2144.
  4. https://www.youtube.com/watch?v=LDKYehwuirw

Share This:

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

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

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

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

So What?

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

Teaming Lessons from Fighter Aviation

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

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

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

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

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

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

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

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

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

Agility. Agility is adaptability with a timescale.

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

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

So, who’s coaching your teams?

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

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

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

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

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

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

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

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

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

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

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

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

Share This:

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:

Risk Management and Error Trapping in Software and Hardware Development, Part 3

This is part 3 of a 3-part piece on risk management and error trapping in software and hardware development. The first post is located here (and should be read first to provide context on the content below), and part 2 is located here.

Root Cause Analysis and Process Improvement

Once a bug has been discovered and risk analysis / decision-making has been completed (see below), a retrospective-style analysis on the circumstances surrounding the engineering practices which failed to effectively trap the bug completes the cycle.

The purpose of the retrospective is not to assign blame or find fault, but rather to understand the cause of the failure to trap the bug, inspect the layers of the system, and determine if any additional layers, procedures, or process changes could effectively improve collective engineering surety and help to prevent future bugs emerging from similar causes.

Methodology

  1. Review sequence of events that led to the anomaly / bug.
  2. Determine root cause.
  3. Map the root cause to our defense-in-depth (Swiss cheese) model.
  4. Decide if there are remediation efforts or improvements which would be effective in supporting or restructuring the system to increase its effectiveness at error trapping.
  5. Implement any changes identified, sharing them publicly to ensure everyone understands the changes and the reasoning behind them.
  6. Monitor the changes, adjusting as necessary.

Review sequence of events

With appropriate representatives from engineering teams, certification, hardware, operations, customer success, etc., review the discovery path which led to finding the bug. The point is to understand the processes used, which ones worked, and which let the bug pass through.

Determine root cause and analyze the optimum layers for improvement

What caused the bug? There are many enablers and contributing factors, but typically only one or two root causes. The root cause is one or a possible combination of Organization, Communication, Knowledge, Experience, Discipline, Teamwork, or Leadership.

  • Organization – typically latent, organizational root causes include things like existing processes, tools, practices, habits, customs, etc., which the company or organization as a whole employs in carrying out its work.
  • Communication – a failure to convey necessary, important, or vital information to or among an individual or team who required it for the successful accomplishment of their work.
  • Knowledge – an individual, team, or organization did not possess the knowledge necessary to succeed. This is the root cause for knowledge-based errors.
  • Experience – an individual, team, or organization did not possess the experience necessary to successfully accomplish a task (as opposed to the knowledge about what to do). Experience is often a root cause in skill-based errors of omission.
  • Discipline – an individual, team, or organization did not possess the discipline necessary to apply their knowledge and experience to solving a problem. Discipline is often a root cause in skill-based errors of commission.
  • Teamwork – individuals, possibly at multiple levels, failed to work together as a team, support one another, and check one another against errors. Additional root causes may be knowledge, experience, communication, or discipline.
  • Leadership – less often seen at smaller organizations, a Leadership failure is typically a root cause when a leader and/or manager has not effectively communicated expectations or empowered execution regarding those expectations.

Map the root cause to the layer(s) which should have trapped the error

Given the root cause analysis, determine where in the system (which layer or layers) the bug should have been trapped. Often there will be multiple locations at which the bug should or could have been trapped, however the best location to identify is the one which most closely corresponds to the root cause of the bug. Consideration should also be given to timeliness. The earlier an error can be caught or prevented (trapped), the less costly it is in terms of both time (to find, fix, and eliminate the bug) and effort (a bug in production requires more effort from more people than a developer discovering a bug while checking their own unit test).

While we should seek to apply fixes at the locations best suited for them, the earliest point at which a bug could have been caught and prevented will often be the optimum place to improve the system.

For example, if a bug was traced back to a team’s discipline in writing and using tests (root cause: discipline and experience), then it would map to layers dealing with testing practices (TDD/ATDD), pair programming, acceptance criteria, definition of “Done,” etc. Those layers to which the team can most readily apply improvements and which will trap the error sooner rather than later should be the focus for improvement efforts.

Decide on improvements to increase system effectiveness

Based on the knowledge gained through analyzing and mapping the root cause, decisions are made on how to improve the effectiveness of the system at the layers identified. Using the testing example above, a team could decide that they need to adjust their definition of Done to include listing which tests a story has been tested against and their pass/fail conditions.

Implement the changes identified, and monitor them for effectiveness.

Risk Analysis

Should our preventative measures fail to stop a bug from escaping into a production environment, an analysis of the level of risk needs to be explicitly completed. (This is often done, but in an implicit way.) The analysis of the level of risk derives from two areas.

Risk Severity – the degree of impact the bug can be expected to have to the data, operations, or functionality of affected parties (the company, vendors, customers, etc.).

Blocking A bug that is so bad, or a feature that is so important, that we would not ship the next release until it is fixed/completed. Could also signify a bug that is currently impacting a customer’s operations, or one that is blocking development.
Critical A bug that needs to be resolved ASAP, but for which we wouldn’t stop everything. Bugs in this category are not impacting operations (a customer’s, or ours), but they are significantly challenging to warrant attention.
Major Best judgement should be used to determine how this stacks against other work. The bug is serious enough that it needs to be resolved, but the value of other work and timing should be considered. If a bug sits in major for too long, its categorization should be reviewed and either upgraded or downgraded.
Minor A bug that is known, but which we have explicitly de-prioritized. Such a bug will be fixed as time allows.
Trivial Should really consider closing this level of bug. At best these should be put into the “Long Tail” for tracking.

Risk Probability – the likelihood, expressed against a percentage, that those potentially affected by the bug will actually experience it (ie., always, only if they have a power outage, or only if the sun aligns with Jupiter during the slackwater phase of a diurnal tide in the northeastern hemisphere between 44 and 45 degrees Latitude).

Definite 100% – issue will occur in every case
Probable 60-99% – issue will occur in most cases
Possible 30-60% – coin-flip; issue may or may not occur
Unlikely 2-30% – issue will occur in less than 50% of cases
Won’t 1% – occurrence of the issue will be exceptionally rare

Given Risk Severity and Probability, the risk can be assessed according to the following matrix and assigned a Risk Assessment Code (RAC).

Risk Assessment Matrix Probability
Definite Probable Possible Unlikely Won’t
Severity Blocker 1 1 1 2 3
Critical 1 1 2 2 3
Major 2 2 2 3 4
Minor 3 3 3 4 5
Trivial 3 4 4 5 5

Risk Assessment Codes
1 – Strategic     2 – Significant     3 – Moderate     4 – Low     5 – Negligible

The Risk Assessment Codes are a significant factor in Risk decision-making.

  1. Strategic – the risk to the business or customers is significant enough that its realization could threaten operations, basic functioning, and/or professional reputation to the point that the basic survival of the business could be in jeopardy. As Arnold said in Predator: “We make a stand now, or there will be nobody left to go to the chopper!”
  2. Significant – the risk poses considerable, but not life-threatening, challenges for the business or its customers. If left unchecked, these risks may elevate to strategic levels.
  3. Moderate – the risk to business operations, continuity, and/or reputation is significant enough to warrant consideration against other business priorities and issues, but not significant enough to trigger higher responses.
  4. Low – the risk to the business is not significant enough to warrant special consideration of the risk against other priorities. Issues should be dealt with in routine, predictable, and business-as-usual ways.
  5. Negligible – the risk to the business is not significant enough to warrant further consideration except in exceptional circumstances (ie., we literally have nothing better to do).

Risk Decision

The risk decision is the point at which a decision is made about the risk. Typically, risk decisions take the form of:

  • Accept – accept the risk as it is and do not mitigate or take additional steps.
  • Delay – for less critical issues or dependencies, a decision about whether to accept or mitigate a risk may be delayed until additional information, research, or steps are completed.
  • Mitigate – establish a mitigation strategy and deal with the risk.

For risk mitigation, feasible Courses of Action (CoAs) should be developed to assist in making the mitigation plan. These potential actions comprise the mitigation and or reaction plan. Specifically, given a specific bug’s risk severity, probability, and resulting RAC, the courses of action are the possible mitigate solutions for the risk. Examples include:

— Pre-release —

  • Apply software fix / patch
  • Code refactor
  • Code rewrite
  • Release without the code integrated (re-build)
  • Hold the release and await code fix
  • Cancel the release

— In production —

  • Add to normal backlog and prioritize with normal workflow
  • Pull / create a team to triage and fix
  • Swarm / mob multiple teams on fix
  • Pull back / recall release
  • Release an additional fix as a micro-upgrade

For all risk decisions, those decisions should be recorded and those which remain active need to be tracked. There are many methods available for logging and tracking risk decisions, from spreadsheets to documentation to support tickets. There are entire software platforms expressly designed to track and monitor risk status and record decisions taken (or not) about risks.

Decisions to delay risk mitigations are the most important to track, as they require action and at the speed most business move today, a real risk exists of losing track of risk delay decisions. Therefore a Risk Log or Review should be used to routinely review the status of pending risk decisions and reevaluate them. Risk changes constantly, and risks may significantly change in severity and probability overnight. In reviewing risk decisions regularly, leadership is able to simultaneously ensure both that emerging risks are mitigated and that effort is not wasted unnecessarily (as when effort is put against a risk which has significantly declined in impact due to changes external to the business).

Conclusion

I hope you’ve enjoyed this 3-part series. Risk management and error trapping is a complicated and – at times – complex topic. There are many ways to approach these types of systems and many variations on the defense-in-depth model.

The specific implementation your business or organization chooses to adopt should reflect the reality and environment in which you operate, but the basic framework has proven useful across many domains, industries, and is directly adapted from Operational Risk Management as I used to practice and teach it in the military.

Understanding the root cause of your errors, where they slipped through your system, and how to improve your system’s resiliency and robustness are critical skills which you need to develop if they are not already functional. A mindful, purposeful approach to risk decision-making throughout your organization is also critical to your business operations.

Good luck!

 

Chris Alexander is a former U.S. Naval Officer who was an F-14 Tomcat flight officer and instructor. He is Co-Founder and Executive Team Member of AGLX Consulting, creators of the High-Performance Teaming™ model, a Scrum Trainer, Scrum Master, and Agile Coach.

Share This:

Risk Management and Error Trapping in Software and Hardware Development, Part 2

This is part 2 of a 3-part piece on risk management and error trapping in software and hardware development. The first post is located here (and should be read first to provide context on the content below).

Error Causality, Detection & Prevention

Errors occurring during software and hardware development (resulting in bugs) can be classified into two broad categories: (1) skill-based errors, and (2) knowledge-based errors.

Skill-based errors

Skill-based errors are those errors which emerge through the application of knowledge and experience. They are differentiated from knowledge-based errors in that they arise not from a lack of knowing what to do, but instead from either misapplication or failure to apply what is known. The two types of skill-based errors are errors of commission, and errors of omission.

Errors of commission are the mis-application of a previously learned behavior or  knowledge. To use a rock-climbing metaphor, if I tied my climbing rope to my harness with the wrong type of knot, I would be committing an error of commission. I know I need a knot and I know which knot to use and I know how to tie the correct knot – I simply did not do it correctly. In software development, one example of an error of commission might be an engineer providing the wrong variable to a function call, as in:

var x = 1;        // variable to call
var y = false;    // variable not to call
public function callVariable(x) {
return x;
}
callVariable(y); // should have provided “x” but gave “y” instead

Errors of omission, by contrast, are the failure to apply knowledge or experience (previously learned behaviors) to the given problem. In my climbing example, not tying the climbing rope to my harness (at all) before beginning to climb is an error of omission. (Don’t laugh – this actually happens.) In software development, an example of an error of omission would be an engineer forgetting to provide a variable to a function call (or forgetting to add the function call at all), as in:

var x = 1;              // variable to call
var y = false;          // variable not to call
public function callVariable(x) {
return x;
}
callVariable();   // should have provided “x” but left empty

Knowledge-based errors

Knowledge-based errors, in contrast to skill-based errors, arise from the failure to know the correct behavior to apply (if any). An example of a knowledge-based error would be a developer checking in code without any unit, integration, or system tests. If the developer is new and has never been indoctrinated to the requirements for code check-in as including having written and run a suite of automated unit, integration, and system tests, this is an error caused by a lack of knowledge (as opposed to omission, where the developer had been informed of the need to write and run the tests but failed to do so).

Defense-in-depth, the Swiss cheese model, bug prevention and detection

Prevention comprises the systems and processes employed to trap bugs and stop them from getting through development environments and into certification and/or production environments (depending on your software / hardware release process). In envisioning our Swiss cheese model, we need to understand that the layers include both latent and active types of error traps, and are designed to mitigate against certain types of errors.

The following are intended to aid in preventing bugs.

Tools & methods to mitigate against Skill-based errors in bug prevention:

  • Code base and architecture [latent]
  • Automated test coverage [active]
  • Manual test coverage [active]
  • Unit, feature, integration, system, and story tests [active]
  • TDD / ATDD / BDD / FDD practices [active]
  • Code reviews [active]
  • Pair Programming [active]
  • Performance testing [active]
  • Software development framework / methodology (ie, Scrum, Kanban, DevOps, etc.) [latent]

Tools & methods to mitigate against Knowledge-based errors in bug prevention:

  • Education & background [latent]
  • Recruiting and hiring practices [active]
  • New-hire Onboarding [active]
  • Performance feedback & professional development [active]
  • Design documents [active]
  • Definition of Done [active]
  • User Story Acceptance Criteria [active]
  • Code reviews [active]
  • Pair Programming [active]
  • Information Radiators [latent]

Detection is the term for the ways in which we find bugs, hopefully in the development environment but this phase would also include certification if your organization has a certification / QA phase. The primary focus of detection methods is to ensure no bugs escape into production. As such, the entire software certification system itself may be considered one, large, active layer of error trapping. In fact, in many enterprise companies, the certification or QA team (if you have one) is actually the last line of defense.

The following are intended to aid in detecting bugs:

Tools & methods to mitigate against Skill-based errors in detecting bugs:

  • Automated test coverage [active]
  • Manual test coverage [active]
  • Unit, feature, integration, system, and story tests [active]
  • TDD / ATDD / BDD / FDD practices [active]
  • Release certification testing [active]
  • Performance testing [active]
  • User Story Acceptance Criteria [active]
  • User Story “Done” Criteria [active]
  • Bug tracking software [active]
  • Triage reports [active]

Tools & methods to mitigate against Knowledge-based errors in detecting bugs:

  • Education & background [latent]
  • Professional development (individual / organizational) [latent / active]
  • Code reviews [active]
  • Automated & manual test coverage [active]
  • Unit, feature, integration, system, story tests [active]

When bugs “escape” the preventative measures of your Defense-in-depth system and are discovered in either the development or production environment, a root cause analysis should be conducted on your system based on the nature of the bug and how it could have been prevented and / or detected earlier. Based upon the findings of your root cause analysis, your system can be improved in specific, meaningful ways to increase both its robustness and resilience.

How an organization should, specifically, conduct root cause analysis, analyze risk and make purposeful decisions about risk, and how they should improve their system is the subject of part 3 in this series, available here.

 

Chris Alexander is a former U.S. Naval Officer who was an F-14 Tomcat flight officer and instructor. He is Co-Founder and Executive Team Member of AGLX Consulting, creators of the High-Performance Teaming™ model, a Scrum Trainer, Scrum Master, and Agile Coach.

Share This:

Risk Management and Error Trapping in Software and Hardware Development, Part 1

The way in which we conceptualize and analyze risk and error management in technology projects has never received quite the same degree of scrutiny which business process frameworks and methodologies such as Scrum, Lean, or Traditional Project Management have. Yet risk is inherent in everything we do, every day, regardless of our industry, sector, work domain, or process.

We actually practice risk management in our everyday lives, often without consciously realizing that what we are doing is designed to manage levels of risk against degrees of potential reward, and either prevent errors from occurring or minimizing their impact when they do.

For example, I recently took a trip to the San Juan islands with my wife and parents. I woke up early, made coffee, roused the troops, and checked the weather. I’d filled up the gas thank the day before, and booked our ferry tickets online. I checked the weather and recommended we each take an extra layer. We departed the house a bit earlier than really necessary, but ended up encountering a detour along the way due to a traffic accident on the Interstate. Nevertheless, we made it to the ferry terminal with about 10 minutes to spare, and just in time to drive onto the ferry and depart for Friday Harbor.

My personal example is relatively simple but, with a little analysis, demonstrates how intuitively we assess and manage risk:

  • Wake up early: mitigates risk of oversleeping and departing late (which could result further in forgetting important things, leaving coffee pot/equipment on, etc.), waiting on others in the bathroom, and not being able to prepare and enjoy some morning coffee (serious risk).
  • Check the weather: understanding the environment we are entering into is critical to mitigating environment-related risks, in this case real environmental concerns such as temperature, weather, wind, and precipitation, enabling us to mitigate potentially negative effects and capitalize on positives. Bad weather may even result in our changing our travel plans entirely – a clear form of risk mitigation in which we determine that our chance for a successful journey is low compared against the value we would derive from undertaking the journey in the first place, and decide the goal is not sufficient to accept present risk levels.
  • Book ferry tickets online: a mitigation against the risk of arriving late and having to wait in line to purchase tickets, which could result in us missing the ferry due to either running out of time or the ferry already being completely booked.
  • Departing earlier than necessary: a mitigation against unforeseen and unknowable specific risk, in this case the generic risk of en route delays, which we did encounter on this occasion.

As you can see, as a story my preparations for our trip seem rather routine and unremarkable, but when viewed through the lens of risk mitigation and error management, each action and decision can be seen as specifically targeted to mitigate one or more specific risks or minimize the potential effects of an error. Unfortunately, our everyday intuitive actions and mental processes seldom translate into our work environments in such direct and meaningful ways.

Risk and Error Management in Software and Hardware Development – Defense-in-Depth and the Swiss Cheese Model

Any risk management system can be seen as a series of layers designed to employ a variety of means to mitigate risk and prevent errors from progressing further through the system. We call this “trapping errors.” Additionally, each of these layers is often just one part of a larger system. A system constructed with these layers  is referred to as having “defense-in-depth.”

Defense-in-depth reflects the simple idea that instead of employing one single, catch-all solution for eliminating risk and trapping errors, a layered approach which employs both latent and active controls in different areas throughout the system will be far more effective in both detecting and preventing errors from escaping.

These layers are often envisioned as slices of Swiss cheese, with each slice representing a different part of the larger system. As a potential risk or error progresses through holes in the system’s layers, it should eventually be trapped in one of the layers.

Risk and errors are then only able to impact the system when all the holes in the system’s Swiss cheese layers “line up.”

Latent and Active Layers

There are two basic types of layers (or traps) in any system: latent and active. In your day to day life, latent traps are things such as the tires on your car or the surface of the road. Active traps are things such as checking the weather, putting on safety gear, wearing a helmet, or deciding not to go out into the weather.

Latent layers in software or hardware development may be things such as the original (legacy) code base, development language(s) used, system architecture & design, hardware (types of disk drives, manufacturer), and so forth. It may even include educational requirements for hiring, hiring practices, and company values.

Active layers in software and hardware development may include release processes, User Story writing and acceptance criteria, and development practices like TDD/ATDD, test automation, code reviews, and pair programming.

Separation of Risk and Error Management Concerns

To better focus on dealing with the most appropriate work at the appropriate time in responding to error detection, triage, and risk mitigation, we can separate our risk and error analysis into the following areas:

During development: focus on trapping errors

  • Prevention – the practices, procedures, and techniques we undertake in engineering disciplines to help ensure we do not release bugs or errors into our code base or hardware products.
  • Detection – the methods available to us as individual engineers, teams, and the organization as a whole to find and respond to errors in our code base or hardware products (which includes reporting and tracking).

Risk mitigation: steps for errors that have escaped into certification or production environments

  • Risk Analysis – the steps required to analyze the severity and impact of an error.
  • Risk Decision-making – the process of ensuring decisions about risk avoidance, acceptance, or mitigation are made at appropriate levels with full transparency.

Continuous Improvement in every case

Improvement – the process of improving workflows and practices through shared knowledge and experience in order to improve engineering practices and further harden our release cycles. This step uses root cause analysis to help close the holes we find in the layers of our Swiss cheese model.

Here is one conceptualization of what a Defense-in-depth Risk Management model might look like. Bear in mind that this is simply one way to conceive of layers at a more macro level, and each layer could easily itself be broken down into a set of layers, or you could conceive of it as one very large model.

swiss_cheese

Given our model and our new ability to conceive of Risk and Error Management in this more meaningful and purposeful way, our next step is to understand error causality and what we can do to apply our causal analysis to strengthening our software and hardware risk management and error trapping system.

Continue reading in part 2 of this 3-part series.

 

Chris Alexander is a former U.S. Naval Officer who was an F-14 Tomcat flight officer and instructor. He is Co-Founder and Executive Team Member of AGLX Consulting, creators of the High-Performance Teaming™ model, a Scrum Trainer, Scrum Master, and Agile Coach.

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:

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

As reported by GeekWire, over the weekend two Seattle sisters, Kimberly (8) and Rebecca (10) Yeung, launched a small weather balloon to the edge of space (roughly 78,000 feet). They have the GoPro video from two cameras to prove it.

While this is certainly an impressive, if not amazing, feat for two young girls to have accomplished (despite some parental assistance), what is perhaps most impressive (at least to me) is the debrief (or retrospective) they held after the mission. While I’m not fortunate enough to have been there to witness it personally, I can see from the photo of their debrief sheet (as posted in the GeekWire article) that it was amazingly productive and far surpasses most of the agile retrospectives (debriefs) I’ve witnessed.

14416510384450*Photo copied from the article on GeekWire.

Apart from the lesson about their Project Plan (“We were successful because we followed a Project Plan & Project Binder”), this sheet is astonishingly solid. Even given the fact that I think it is a misconception to attribute success to having had a project plan, for an 8 and 10-year-old, this is awesome work!

My friend and fellow coach Brian Rivera and I have often discussed the dire lack of quality, understanding, and usefulness of most agile retrospectives. I might even go so far as to call the current state of agile retrospectives in general “abhorrid” or “pathetic,” even “disgraceful.” Yes, I might just use one of those adjectives.

For teams using agile methodologies and frameworks focused on continuous improvement (hint: everything in agile is about enabling continuous improvement), the retrospective is the “how” which underlies the “what” of continuous improvement.

Supporting the concrete actions of how to improve within the retrospective are the lessons learned. Drawing out lessons learned during an iteration isn’t magic and it isn’t  circumstantial happenstance – it requires focused thought, discussion, and analysis. Perhaps for high-performing teams who have become expert at this through positive practice, distilling lessons learned and improving their work may occur at an almost unconscious level of understanding, but that’s maybe 1% (5% if I’m optimistic) of all agile teams.

So what does a team need to understand to actually conduct a thorough and detailed analysis during their retrospective? Actually only a few things:

  1. What were they trying to do? (Goals)
  2. How did they plan to do it? (Planning / strategy)
  3. What did they actually do? (Execution – what actually occurred)
  4. What were their outcomes? (Results of their work)
  5. What did they learn, derived from analyzing the results of their efforts measured against the plan they had to achieve their goals? (Lessons learned)

A simple example:

  1. I want to bake peach scones which are light, fluffy, and taste good. (Goal + acceptance criteria)
  2. I plan to wake up early Saturday morning and follow a recipe for peach scones which I’ve found online, is highly rated, and comes from a source I trust. It should take 30 minutes. (Planning – who / what / when / where / how)
  3. I wake up early Saturday morning and follow the recipe, except for the Baking Powder. It can leave a metallic taste behind, so I leave it out. (Execution)
  4. It took almost an hour to make the scones, and they did not rise. They tasted alright, but were far, far too dense and under-cooked internally, partially due to being flat. (Outcomes)
  5. I didn’t allocate enough time based on the fact that it was my first attempt at baking scones and I was trying to modify a known good recipe (reinventing the wheel, root causes: experience). Although I wanted light, fluffy scones, I didn’t get them because I deliberately left out a key ingredient necessary to help the dough rise (good intention – bad judgment, root causes: knowledge / discipline). (Lessons learned)

Perhaps a bit overly simplistic but this is exactly the type of concrete, detailed analysis into which most teams simply never delve. Instead, retrospectives for most agile teams have devolved into a tragic litany of games, complaining sessions, and “I liked this / I didn’t like that” reviews with no real outcomes, takeaways, or practical concepts for how to actually improve anything. Their coaches leave them with simple statements such as “we need to improve.” Great. Thanks.

Taking what we know from Kimberly and Rebecca’s plan to send a weather balloon into outer space, let’s do a little analysis on their retrospective. I can tell you already it is not only solid, but will ensure they’re able to improve not only on the technical design itself, but also improve their team’s “meta” – the ways they work, their collaboration, their teamwork, their research – everything which enables them to actually continually improve and produce powerful results.

  • Bigger balloon – create more lift – ensure faster rate of ascent (Technical / work – related but important. They have learned through iterating.)
  • Remember to weigh payload with extra – more accurate calculations – correct amount of helium (Technical but also process-related, this draws root causes arising from both knowledge and experience, enabling them to adapt both their work itself and their meta – how they work.)
  • Don’t stop trying – you will never know if you don’t ask. Eg GoPro (Almost purely meta, reflecting a great lesson which builds not only a team mindset but also reflects a core value, perseverance!)
  • Washington Geography – Map research on launch locations taught us a lot of geography (This is both technical and meta, addressing their research data and inputs/outputs but also learning about how to learn and the value of research itself!)
  • Always be optimistic – We thought everything went wrong but every thing went right. Eg. SPOT Trace max altitude mislead [sic] our expectations. Eg. We thought weather cloudy but it was sun after launch. Eg. Weight. Thought payload too heavy for high altitude. (Are you kidding me?! Awesome! Lessons about situational awareness and current operational picture, data inconsistencies, planned versus actual events, planning data and metrics, and the importance of outlook/attitude! #goldmine!)
  • Be willing to reconstruct – If you find out there is a problem, do not be afraid to take it apart and start all over again. (Invaluable lesson – learning to embrace failure when it occurs and recover from it, realizing that the most important thing is not to build the product right, but to build the right product!)
  • Have a redundant system – Worry less. (Needs no explanation.)
  • SPOT Trace technology awesome – Very precise (This is a fantastic example of a positive lesson learned – something that is equally important to acknowledge and capture to ensure it gets carried forward and turned into a standard practice / use.)
  • Live FB updates – add to fun + excitement (Yes yes yes!! To quote an old motto, “If you’re not having fun, you’re not doing it right!” This stuff should be fun!!)
  • Speculation – Don’t guess. Rely on data. (Fantastic emphasis on the importance of data-oriented decisions and reflects another potential team core value!)
  • Project Plan – We were sucessful [sic] because we followed a Project Plan + Project Binder. (The only lesson I disagree with. I would advocate a good 5 Whys session on this one. My suspicion is that the project was successful because they as a team worked both hard and well together [high-performing], had fun, and iterated well [based on the lesson about not being afraid to reconstruct / start over]. I have serious doubts that their mission was a success because they had and followed a project plan. Regardless, this is far too small a point to detract from the overall impressiveness of their work!)

Take a few lessons from two girls who have demonstrated concrete learning in ways most adults fail miserably to even conceptually grasp. If you are on a team struggling to get productive results from your retrospectives, stop accepting less than solid, meaningful analysis coupled with clear, actionable results. The power is in your hands (and head).

If you are one of those agile coaches who thinks retrospectives are just for fun and celebration, who plays games instead of enables concrete analysis, and who wonders why their teams just cannot seem to make any marked improvements, get some education and coaching yourself and stop being a part of the problem!

(Written with the sincerest of thanks to Kimberly and Rebecca Yeung, and the Yeung family for their outstanding work, and to GeekWire for publishing it!)

* Chris Alexander is an agile coach, thinker, ScrumMaster, recovering developer, and co-founder of AGLX Consulting, who spends too little time rock climbing.

Share This: