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


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:

Psychological Safety ≠ “Be Vulnerable”

Psychological Safety has (finally) entered the mainstream discourse in business communities. Particularly in the world of #agile and #agile_coaching, it is a topic I hear referenced with increasing frequency and conviction. There’s just one problem.

Most people have no idea what it actually means.

Through various discussions, online and in person, in sessions at Agile meetups, and at numerous conventions, I’ve listened to agilists and consultants preaching the importance of Psychological Safety whilst touting the research which was surfaced by Google through Project Aristotle (though pioneered by researchers like Amy Edmundson).

Yet most managers, consultants, and agilists have embraced the concept of Psychological Safety without understanding the context of the term. Instead, the term Psychological Safety is often equated with the idea of “being vulnerable with your team.” Agile Coaches and Scrum Masters, focused on achieving that Holy Grail of coaching – building a high-performing team – are in the process of co-opting the term “Psychological Safety” to mean “intra-team-member trust.

Please. Stop.

Trust within a team is certainly a fundamental and vital characteristic to develop; absolutely no question there. Team members working together need to understand one another, trust in each other, communicate, collaborate, innovate, problem-solve, make decisions, implement, improve, learn, and produce together effectively. Trust is fundamental, and team trust is an important component of Psychological Safety.

Part of building that trust means, yes, taking some (perceived) interpersonal risk. Examples of perceived “risky behavior” in this area of interpersonal trust-building within a team might include:

  • Asking questions, which risks evidencing a perceived lack of knowledge, awareness, or understanding;
  • Questioning assumptions and/or voicing opinions, which risks challenging social and sometimes formal hierarchies and upsetting power relationships;
  • Admitting mistakes, which risks appearing like an under-performer at best, or incapable and incompetent at worst;

The point is, these sorts of things are clearly trust issues, but we have a word for these issues: trust.

What, then, is the difference between Trust and Psychological Safety?

Trust in this story is inter-personal and intra-team, which means it has to do with the degree to which individuals within the same team believe in the reliability, credibility, ability, and intentions of their teammates. We certainly cannot build an environment of Psychological Safety without Trust.

Psychological Safety, on the other hand, refers not only to the degree to which team members trust one another, but also to the environment (external) in which the team operates. In fostering intra-team trust, the team is neither attempting nor able to affect the external environment in which the team operates (the business or organization, its culture, explicit and implicit rules and processes, explicit and implicit structures and hierarchies, norms, values, etc.).

The environment in which the team functions will ultimately have the greatest effect on Psychological Safety. Regardless of how much team members trust one another, if the team operates in an environment which is hostile to open and honest communication, punishes individuals and teams for mistakes, or engages in or encourages retribution for perceived protocol infractions, slights, or failure to follow dogmatic processes, all the trust in the world isn’t going to develop Psychological Safety.

Psychological Safety

What does build Psychological Safety?

First and foremost, lead by example. The truth is, and there is ample social and cognitive psychological research to prove it, that people follow – and imitate – those they identify as leaders. The basic fact of our humanity is that when we perceive someone as “doing well,” we emulate those aspects of their personality and habit which we interpret as contributing to their success. We follow them (social media, online, print, at conferences and expos, etc.) and watch what they’re doing, and what they’re saying.

How this plays into Psychological Safety is simple. If you’re in charge of a team, department, or organization, and you want people to admit to (and learn from) mistakes along the way, start by exemplifying that behavior. Walk into meetings and start admitting the last big mistake you made, what it meant, and what you learned from it and plan to adjust in order to do better, next time.

Yes, it sounds crazy, but the first step is admitting your own fallibility and creating a culture in which it is okay to do that very thing. Re-framing failure as a learning opportunity, which is the central theme of The Lean Startup (by Eric Ries), you’re showing everyone around you that failure – and owning up to it – is perfectly fine when it is followed through with thoughtful analysis, learning, and meaningful change or improvement.

Many people in leadership positions (note that I do not refer to them as leaders) are far, far too preoccupied with proving that they know what they’re doing and “getting it right,” to actually recognize whether they’re “getting it right.” This is what many refer to as a Performance Mindset.

Performance Mindset: I’m here because I’m the expert, I know what I’m doing, I’m not wrong, I don’t make mistakes, and my job (and self-image) depends on my ability to perform!

Those in leadership positions who possess a Performance Mindset are typically unable to admit mistakes or fallibility, and tend to directly or indirectly punish others for making mistakes and can be prone to rebuking those who challenge their positions or opinions. It’s tough to be challenged when your perception of self – personal and professional – is grounded in an image of expertise and infallibility.

Developing Psychological Safety in teams and organizations which are led by individuals (execs, directors, or managers) who are firmly fixed in the Performance Mindset is exceptionally challenging. I wouldn’t say impossible – I’d just say I have yet to see it done.

To be certain, there are environments in which a Performance Mindset is exceptionally useful, if not vital to success. One of the underlying principles behind Traditional (Waterfall) Project Management is in fact the manager or leader who has a Performance Mindset. For companies and organizations who operate in simple-to-complicated domains, the presence of experts who have developed vast amounts of experience and knowledge over the course of many years of work is invaluable.

Simple or complicated work streams lend themselves perfectly to the application of best practices or known-good practices. We just need experts who can apply their knowledge and experience to help us achieve predictable, known outcomes.

Now, let’s step into Complexity. Complexity is a domain in which causal connections are unclear or hidden. We can make observations and discern clear correlations emerging between events, but it is impossible to definitively prove a causal relationship between events.

Enter the Complexity Mindset.

Complexity Mindset: I’m here because I know how to enable teams and individuals to make observations, analyze goals, make decisions, execute, reflect and learn, take improvements, adjust, and iterate!

The opposite of the Performance Mindset is the Complexity Mindset. Leaders with this mindset (regardless of their designated position within a hierarchy) focus on clearly articulating a vision and intent while empowering their teams to execute with as much autonomy as possible. The ultimate expression of this mindset is a company or organization in which teams understand at deep levels what their objectives and constraints are, and guide their own execution according to those objectives and constraints.

A Complexity Minded leader not only empowers teams to execute according to principles of self-organization, but also encourages and rewards learning through both success and failure. When you don’t know how to get from A to B, mistakes will occur.

The Lean Startup is, at its essence, a prolonged essay on the execution of a Complexity Mindset. When developing a new product which we don’t know anyone will like or use, as we learn about aspects of the product people like or dislike, we’ll adjust to build more of what they like, and less of what they don’t like. If people don’t like the product at all, we’ll look for positive, leading indicators which may point us to new products which then will have a better chance of success.

We are learning, despite failures. Iterating on a product, observing its adoption, deciding what to change, changing it, and returning to observe (ODAO variant of the OODA loop), we have a much greater chance of succeeding.

Software companies like Google, Amazon, Facebook, Microsoft, and Apple do this often. Facebook’s Dislike button, Tay (the offensive AI chatbot from Microsoft), Windows Vista… you get the idea. Heck, with a roughly 90% failure rate, the entire startup scene in Silicon Valley is a fantastic example of attempting to navigate social, financial, and consumer complexity through experimentation.

The point is, companies never start out with an intent to fail or make mistakes and neither do your teams. Yet the simple fact of reality is that mistakes and failures do happen. Especially when trying to do something that’s never been done before, build something that’s never been built before, etc. A mature, resilient, learning organization knows that challenges and setbacks are inevitable, and is able to overcome and succeed.

What about responsibility and accountability?

I quite often hear this refrain. “If we don’t hold people accountable,” (a code phrase for punishing people for mistakes), “people will think they can get away with anything!” False. First, if you hear this come from a leader, beware. They have just given you an insight into how they think and how they would likely behave, if given the chance.

The truth is, the 99% majority of people, especially in knowledge industry work, are there specifically because they want to do a good job. Furthermore, yes, there are clear red lines in terms of performance and accountability. This is the difference between honest mistakes and negligence.

When Amazon Web Services went down recently, taking a considerably large portion of the internet with it, Amazon was incredibly forthcoming in sharing their root cause diagnosis and the fact of the matter was that someone incorrectly entered a piece of text specifying the amount of infrastructure to take offline. It was an honest mistake.

I once watched as a friend attempted to enter TTYL (talk to you later) into an SMS to his wife, which quickly auto-corrected the phrase to Tina. As we were on a business trip, it could have raised some pretty legitimate concerns from his wife’s perspective. Instead, he replied “sorry, stupid auto-correct – meant TTYL” and sent that, instead.

Honest mistake.

Now, let’s imagine a scenario in which a government worker with a security clearance decides to take some classified work home with him on a USB drive to continue reviewing at home. At home, he plugs in the USB drive and the malware on his computer instantly dumps that classified information out to Wikileaks.

This is not an honest mistake. There are federal regulations (laws) which guide the handling of classified information. Those laws (in our example) have just been broken.

This is not an honest mistake. This is negligence (or worse).

Negligent (or worse, outright illegal) behavior needs to be corrected, yes, and those engaging in it need to be held to account, perhaps outright fired. But the guy who incorrectly typed a command wasn’t being negligent – he made an honest mistake.

Honest mistakes we want to know about because they offer us great opportunities for improving our systems. For example in the AWS case – why was an individual able to take down such a large system without having to confirm their typed command entry? Why were they able to incorrectly type the command (don’t they have copy/paste, or a UI)? How could we have enabled the system to prevent this sort of outage, itself?


Can you tell I’m passionate about this stuff???

By now I hope you’re developing the sense that Psychological Safety in teams is not fully within the team’s ability to control. Management and leadership have a significant ability to control whether teams feel empowered to admit mistakes, learn from them, and make improvements, or hide mistakes, silo important knowledge and information, and leave systems (and the organization) to succeed or fail on their own.

To develop and enhance Psychological Safety in your complex workplace, leaders need to adopt a Complexity Mindset and focus on the following:

  • Own your mistakes. That manager at AWS who refused to take on the work to improve the automation around service outages because it seemed not worth the return on investment? They’d better be standing up right now and admitting that they made that call, it was a bad call, and that Amazon indeed needs to invest in improving their outage automation. The quote sounds like this: “It wasn’t the engineer’s fault for causing the outage, it was my fault for not allowing the engineering team to prevent an outage before it occurred. My bad. Can someone help me fix it?”
  • Support your people and your teams, especially when they make honest mistakes. Help them re-frame those mistakes as opportunities to improve systems, processes, practices, and skillsets, and then empower them to make those improvements.
  • Reward individuals and teams for sharing mistakes, challenging assumptions, questioning decisions and policies, and striving to find “better ways.” Public support and thanks are powerful signals that those are desired behaviors, and will get you more of the same.
  • Encourage open environments in which people can freely share issues, concerns, and admit when they aren’t sure about how to solve a problem. Ensure that people asking for help get help, not ridicule. A culture in which individuals pride themselves on showing everyone how smart they are is a culture in which no one admits when they don’t know something, leaving you blind to risks and pitfalls. A culture in which people feel empowered to ask for help – and then get it – in order to solve challenging issues and mitigate potential risks, is a culture which will build resilient, adaptable systems and organizations.

Agree? Questions or comments? Do you entirely disagree and feel that Psychological Safety is actually all about admitting vulnerability? Let me hear about it. If you don’t want to respond here in the comments, send me an email! I’m more than happy to hear from you, engage in constructive debate, and learn about where I have it wrong. Because I make mistakes, too.

By the way – thank you for reading!


This post originally appeared March 9th, 2017 on LinkedIn here:



Share This:

Planning is Everything… If You Know How To Plan (Part 1)

In the next two minutes, you will learn what planning is and why it is a critical enabler in today’s VUCA world.

The above General Eisenhower quote and similar ones by Perter Drucker, Helmuth Karl Bernhard Graf von Moltke, and Mike Tyson, are peppered in leadership and team-building presentations at conferences, company off-sites, and in blog posts. Although powerful—just as strategically hanging posters of your company values above water coolers does nothing to change your organizational values—sharing a planning quote at the beginning of your planning sessions does nothing to improve your organization’s planning capability.

Background. As an Agile Coach with a military strategic and operational planning background, I’ve noticed that very few organizations and coaches know how to plan. A common planning mistake organizations make is throwing a group of people into a room for one, two, or three days to “plan” without showing them how to plan. As a trained and experienced military planner, I know that the science and art of planning (knowing how to plan) must be learned, practiced, and reinforced at every level of an organization.

Knowing how to plan is a human interaction skill and when combined with other cognitive and social skills such as closed-loop communication, the emergence of a collaborative and innovative organization becomes possible. 

What is planning? 

  • The primary goal of planning is not the development of detailed plans that inevitably must be changed; a more enduring goal is the development of teams and organizations who can cope with VUCA
  • Planning provides an awareness and opportunity to study potential future events amongst multiple alternatives in a controlled environment. Through planning, we begin to understand the complex systems we are trying to modulate.
  • Planning is an anticipatory decision making process that helps teams and organizations cope with complexities
  • Planning is continuous.
  • Planning is Fractal. A stand-up is a fractal of a sprint planning session. A meeting should be a fractal of a strategic planning session.
  • Planning is part of problem solving.

Why Plan? 

  • Builds individual and team situational awareness and the organization’s sensemaking capability
  • Helps build leadership skills
  • Planning helps individuals, teams, and leaders anticipate the future
  • Planning helps organizations navigate complexity
  • Planning helps individuals, teams, and organizations understand the system (operational environment) 

How to Plan?

For how to plan, I will save that for another day. There are great planning processes out there that an organization can start practicing today. In Part 2, I will provide a Rubric that will inform your planning how.

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.


Norman M. Wade. The Battle Staff Smartbook: Doctrinal Guide to Military Decision Making & Tactical Operations. Lightning Press, 2005

JP 5-0, Joint Operation Planning, 11 August 2011

Military Decision Making Process (MDMP), March 2015.

Photo: Library of Congress Prints and Photographs Division Washington, D.C. 20540 USA

Share This:

Planning is Everything… If You Know How to Plan (Part 2)

In Part 1, I provided the “What” and “Why” of planning. The intent of Part 2 is to provide organizational leaders a planning Rubric, one that organizations can use to evaluate the adoption of a third-party’s planning process or to help leaders in the development of their organization’s planning “How.”

Based on my experience, training, and education in iterate planning, here are 10 criteria I find essential for any planning process:

  1. Context
  2. Goals | Objectives | Commander’s Intent
  3. Anticipate the Future
  4. Mitigate Cognitive Biases | Challenge Assumptions | Reduce Risk
  5. Low-Tech, High-Touch
  6. Contingency Plan
  7. Retrospective… Part of the Plan
  8. Simple
  9. Iterative
  10. Designate/Rotate the Facilitator

1. Context

You must understand your operating environment (system). Is your operating environment ordered, complex, or chaotic? Not sure? Use the Cynefin framework to help make sense of your context before developing your mission goals, objectives, or Commander’s Intent.

2. Goals | Objectives | Commander’s Intent

If you are operating in an ordered system, then you should be able to establish clear, measureable, and achievable objectives (SMART goals/objectives are okay if you like redundancy). However, this is an unlikely scenario given the amount of VUCA in most operational environments.

For organizations and teams that operate in a complex system—which should be most organizations and teams—using a defined outcome such as SMART goals is not so smart. Why? You cannot predict the future in complex environments. Since complex environments are dispositional, we need to start journeys over stating goals. Vector-based goals are fine—wanting more of X and less of Y is a good example of a vector-based goal and also serves as a decent Commander’s Intent.

3. Anticipate the Future

Complex adaptive systems anticipate the future. Your planning process should include a step that allows team members to identify potential threats to the goals, objectives, or Commander’s Intent. Threats include things such as holidays, days off, system availability, weather systems, outbreak of the flu, multiple futures, etc.

Anticipatory planning also includes identifying resources and people—both available and needed.

4. Mitigate Cognitive Biases | Challenge Assumptions | Reduce Risk

Use Red Teaming, liberating structures, or complex facilitation techniques to mitigate cognitive biases, challenge assumptions, and reduce risk. These tools also help identify weak signals—where innovation comes from—and serve as a check against complacency.

5. Low-Tech, High-Touch

Use a large canvas or board to plan. Sending PowerPoint decks back and forth is a horrible way to plan (Conway’s Law). PowerPoint is a presentation tool, not a planning tool. A high-touch, low-tech approach to planning requires people to be present, both physically and mentally, in a room or rooms.

6. Build a Back-Up or Contingency Plan

You cannot plan against every contingency—those items that you identified as threats or impediments—but your planning process should include a step where the team looks and plans against some of the known unknowns from the complicated domain. Do not spend too much time on unknown unknowns—an organizational adaptive mindset, partially developed from learning how to plan, is a great tactic for protecting against risks in the complex domain.

7. A Retrospective… Part of the Plan

Planning is part of problem solving and building situational understanding; however, a retrospective is far more important than planning and must be included in your plan. Daily re-planning sessions (stand-ups) should also be included in your plan.

8. Simplicity

You should be able to use your planning process as a way to lead a meeting or a stand-up (a re-planning session).

9. Iterative

Planning is not sequential, it is iterative. It is okay to go back and revisit a previous idea, assumption, objective, etc.

10. Designate a Facilitator

If your team and organization knows how to plan, you can eliminate the need to follow a coach who is an expert at putting planning quotes on the board. Leading a planning session builds leadership capability. It also creates team and organizational accountability.

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.


Norman M. Wade. The Battle Staff Smartbook: Doctrinal Guide to Military Decision Making & Tactical Operations. Lightning Press, 2005

JP 5-0, Joint Operation Planning, 11 August 2011

Military Decision Making Process (MDMP), March 2015.

Photo: Library of Congress Prints and Photographs Division Washington, D.C. 20540 USA

Share This:

Cynefin & OODA: Sense- & Decision-Making for Today’s VUCA World (Part 1)

Explicitly connected to Scrum and the Lean Startup, the OODA loop is becoming part of today’s business vernacular. If you attend a Big Data, DevOps, Agile, or Cyber conference, there is a good chance that you will hear a speaker talk about “getting inside your competition’s OODA loop” or “flying the OODA loop.” OODA has even made its way into politics as a way for pundits to describe Donald Trump’s ability, purposeful or careless, to create mismatches or ambiguity for his less agile opponents—a key feature of Boyd’s OODA loop.

A decision-making process for dynamic situations, the OODA loop represents forty years of John Boyd’s research captured in several briefings and papers. His OODA loop sketch—and that’s what it is, a sketch—did not appear until 1996 even though many conference goers often hear that the loop was created in the 1950s. John Boyd has clear guidelines about the use of his sketch: (1) it can be drawn any way you want; (2) do not simplify it; and (3) do not make it more complicated than it is.

A few weeks ago, I had the pleasure of video-conferencing with Chet Richards, author of Certain to Win: The Strategy of John Boyd, Applied to Business, and long-time friend of the late John Boyd. The purpose of our conversation was to take a look at where Boyd’s OODA loop fits in Dave Snowden’s Naturalizing Sense-Making matrix (below) and to see how we can map OODA to Cynefin, a sense-making framework. This post will look at the former and save the latter following conversations with Dave Snowden, Chet Richards and others.

Naturalizing Sense-Making Matrix: How Do We Avoid The Hype and False Promises (Dave Snowden)

On the left side of Dave Snowden’s 2×2 matrix is the scientific method. And on the right, is Observation + Hypotheses = Method. The items on the left scale at low risk and those on the right scale with high risk. Ideally, we want our management approaches that help us navigate VUCA to be in the bottom left; however, classic science is not applicable to human systems.

Methods that are supported by sound theory–those that can be replicated in different contexts—fall in the top left. The top left is good. Valuable methods derived from observations and hypotheses that have explanatory power fall in the top right. The top right is okay. Context specific methods that claim predictive power fall in the bottom right—most management approaches and Agile methodologies fall here—these are considered inappropriate. The bottom right heeds caution. To learn more about what methods may fall in each quadrant, watch this video or any of Dave Snowden’s recent talks.

Where Does the OODA Loop Fit in This Matrix?

The question Chet and I tried to answer during our call was, Where does the OODA loop fit in this matrix? Chet and I believe OODA falls in the top left. However, overcoming Popper’s falsification test is a current hurdle. And, I am sure Dave Snowden will have something to say about our justification.

Formative Factors Behind the OODA Loop: Air-to-Air Combat, Strategy and Science

Chet and I spent most of our 75-minute conversation examining the science that influenced Boyd and how he captured that in his OODA loop. Chet reminded me that Boyd defined science as “a self-correcting process of observations, synthesis/analysis, hypothesis, and test.” According to Chet, Boyd was deeply interested in how scientist learn and how knowledge grows; the work of Polanyi, Kuhn, and Popper influenced Boyd the most.

Natural sciences influenced Boyd’s thinking and are evident in several of his briefings prior to the 1996 unveiling of his OODA loop. In fact, science played a bigger role in the development of the OODA loop, more so than Boyd’s experience as a fighter pilot. However, most people associate the OODA loop with combat aviation, not the scientific method.

The sciences that provided John Boyd constraints and guidance on the development of his simple and elegant OODA loop sketch and his supporting briefings include Complex Adaptive Systems, Cognitive Science, Epistemology, Evolutionary Theory, Thermodynamics, Chaos Theory, Cybernetics, and Systems Thinking.

OODA Loop: How We Test Hypotheses

The OODA loop is how we test hypotheses. According to Chet, organizations that are trying to learn something new must use multiple safe-to-fail experiments, and through repeated OODA looping (observation, analyses & synthesis, hypothesis, and test), they see how their experiments work, and then add the results to their repertoire. To put it simply, OODA is the decision-making process that compliments the sense-making framework known as Cynefin. We will examine what this may look like in a later post.

Additional Notes

  • Chet wanted me to make it clear that Boyd took over 40 years to develop the OODA loop and one cannot learn the OODA loop in a two-hour seminar.
  • Many people use the OODA loop to sell their management and Agile methods—some of those methods fall in the bottom right quadrant of Dave Snowden’s Naturalizing Sense-Making Matrix.
  • John Boyd’s cross-disciplinary approach in building his OODA loop is similar to Dave Snowden’s approach to Cynefin.
  • Boyd claims that agility is an outcome of OODA. And that agility is an external, relative measure. Not an internal one.

I look forward to your comments and help!

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.


OODA Loop Sketch by HurricaneAllie Design

Special thanks to Chet Richards for taking time to discuss his passion. AGLX received prior permission from Chet Richards to use notes from our 12/21/2016 conversation.

Naturalizing Sense-Making Matrix image created by AGLX Consulting and is used with permission under a Creative Commons Attribution-Noncommercial-Noderivs license. The Cognitive Edge method is ©2017 Cognitive Edge (USA) Inc., used with permission under a Creative Commons Attribution-Noncommercial-Noderivs license

Richards, Chet (2004-06-24). Certain to Win: The Strategy of John Boyd, Applied to Business. Kindle Edition.

Share This:

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.


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

[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.

[4] Ibid

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:

Share This:

To Build Great Teams You Need a Plan, Not a Picture

Take a look at the painting below…

Vincent Van Gogh - Cafe Terrace at Night

Notice the way the painter (van Gogh, of course) uses color to create light and shadow, which helps add contour. He draws with perspective, which creates depth. Brush strokes create the illusion of texture, such as cobblestones on the street, or wood on the frame of the doorway. Figures and shapes create the impression of movement, action, and build a scene which our minds can easily interpret.  Now you understand some of the most critical elements in painting, right? So… now you should be able to paint a replica of this masterpiece, or at least be able to create something similar which is just as impressive and iconic.

Can’t do it? Neither can I. We can probably almost universally agree that one cannot simply be shown a great painting, told what techniques, brushes, paints, and colors the artist used in painting it, and then be expected to reproduce it.

There is a fundamental difference between knowing what one needs to do, and actually developing the skills and ability to do it.

Yet we are currently living through exactly this sort of coaching fallacy every day. All around us, thought-leaders, authors, managers, coaches, just about everyone – are deluging the internet with just about everything they can image about the characteristics and behaviors of great teams. For example:

High-performing teams deliver amazing results with high quality.

High-performing teams collaborate together to solve the most difficult problems with ease.

High-performing teams have a common purpose. They work toward shared goals.

High-performing teams manage inter-team conflict and are balanced.

High-performing teams celebrate diversity.

In fact, let me share a little collection of just some of the various attributes, characteristics, and skills found in various articles and publications about “how to build high-performing teams.” Spoiler alert! Like looking at a piece of art, this information doesn’t tell you anything about the things you need to do to start developing your teams toward high-performance. It just shows you a pretty picture of what awesomeness looks like.


So what? We, as individuals, managers, leaders – as a culture – are often far too focused on what things look like – great teams, great cultures, great companies, great innovation – and in trying to explain how incredible, amazing, wonderful, efficient, or effective that greatness is, we fail to consider or share with people the more important knowledge about how they can actually start to improve, themselves.

It’s the difference between showing someone a great painting, instead of helping them develop into a better painter. Or to use a sports metaphor, watching Messi and Ronaldo score goals doesn’t help me to become a better soccer player. To improve, I have to develop my own skills.

I suspect the harsh truth is that most of the enthusiastic authors who blog about and are so excited about high-performing teams have never worked in one, never led one, and never built one. Maybe they’ve seen one or two up close? I don’t want to detract from their exuberance, and I applaud the enthusiasm. Yet I also acknowledge the fact that people need more than pretty pictures to help them improve their own situations.

Fortunately, the skills that high-performing teams and organizations use to normalize greatness are skills that every individual, every team, and every organization can develop, too. Communication, collaboration, situational awareness, problem-solving, agility, leadership – even and especially empathy – are all highly trainable skills which empower the dynamic, human interactions and cooperation upon which great teams are built.

The knowledge and information needed to build effective, powerful teams is out there. It is grounded in decades of experience and scientific research in a multitude of fields across a diverse array of work domains spanning every industry. The teams which employ those skills work in the most demanding environments on (or off) our planet, solve the toughest problems, innovate, collaborate, and perform at incomprehensible levels.

To build great teams you need more than pictures and descriptions. You need a plan to train your teams and based on knowledge, research, and experience. That plan starts with the skills which fuel every kind of team, everywhere. Skills which are transcendent and universal because they leverage one powerful fact:

we are all human.


Chris Alexander is a former F-14 Tomcat RIO & instructor, co-founder of AGLX Consulting, High-Performance Teaming™ coach, Agile coach, Scrum Master, and is passionate about high-performing teams, teamwork, and enabling people to achieve great things.

This post originally published on LinkedIn:

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.


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


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


[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 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?


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.


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