The Fear and Vulnerability Retrospective

What makes your teammates lose sleep at night?

The best way to find out is simple, but not always easy: ask them!

In this post, I’ll be presenting a technique--suitable for a retrospective or a lift off--that opens up channels of communication about the topics of fear and vulnerability.

Set the Stage 

When I run this exercise, I begin with some conceptual groundwork.

I first draw a diagram of three concentric circles and explain that each one of us steps in and out of those zones as we interact as a team:

The Comfort Zone - Ah, an easy and nice place to be. Nothing here worth losing sleep about, and little to no anxiety. The Stretch Zone - AKA No Pain, No Gain. This is a place of risk, and it can be downright uncomfortable for many. However, this zone is where growth usually happens. The Panic Zone – The land of freeze, flee, or fight. It’s best to not go here, since in this zone we actually tend to get dumber. Studies have shown that when we are in a stressed or threatened state (i.e., when the amygdala is on high alert), there is literally less oxygen and glucose for the neocortex’s cognitive functions.

I then explain that moving outside of one’s comfort zone and into the stretch zone where perceptions expand and transformations take place can be scary. Fear is often about risk; more specifically, the risk of losing something. Maybe we get defensive or aggressive when faced with that risk. Maybe our stomachs get queasy. We all have our own personal early warning systems.

I share a quote from Abraham Maslow: “In any given moment, we have two options: to step forward into growth or to step back into safety.”

Choose a similar mantra or quote that makes sense in your team’s context.

I then explain that in order to continuously improve as a team each and every one of us needs to get out of our comfort zone, and doing so requires at least two things: trust and honesty.

Trust at Multiple Levels Personal: You trust yourself to have the courage and bravery to persevere and recover from any failure Personal + Relational: Trust in yourself to recognize your panic zone and be heard by your teammates if you say, “too far!” Relational: Trust in your teammates, coach and leader that they will pull, push or prod you along and support you when you need it Honesty To admit your fears and your sense of vulnerability To bring your full, authentic self without pretense To shine a light on your flaws (as the great Zen master Shunryu Suzuki once said, “Everything is perfect and there is always room for improvement.”) Four Windows into Fear

Next, I draw a quadrant on the whiteboard and discuss four viewpoints:

Environmental: Everything external to the team systems, including other value streams, handoffs, rules, corporate culture and policies Organizational: Refers to the team structure, methods, metrics, processes, decision making patterns, leadership and team micro-culture Relational: This is about “We” – a shared vision and interpersonal dynamics among peers Personal: This is about "Me" - the psychological, the inner world

I explain that during this exercise the team is going to explore the ideas of trust, honesty, fear, and vulnerability in the each of those four contexts.

The Really Scary Part

As I hand out Post-it notes and pens, I ask, “What are the things you fear? Where is trust at risk? Write them per note.”

I then give the team 7-10 minutes to silently brainstorm. When that timebox has been hit or the energy in the room has diminished, I have the team post their notes on the whiteboard in one of the four quadrants (many fears turn out to overlap quadrants, so they end up on the boundaries).

During the process of posting, I encouraged folks to affinity group their notes.

We quickly review the board. I then hand out self-adhesive dots (5±2 depending on the number of affinity groups) and have individuals indicate their top concerns via dot voting.

What emerges time and time again follows a similar pattern: almost no post it group has a single dot, and all fears fall into one of the following bakers’ dozen:

Fear of being held accountable where I'm not really responsible or in real control Fear of failure Fear of being under appreciated Fear of loss of job Fear of loss of respect Fear of letting others on the team down Fear of stagnation and lack of personal growth Fear of conflict Fear of separation and being an outsider Fear of being wrong Fear of what others think of me Fear of embarrassment, humiliation and ridicule Fear of loss of identity and individualism (i.e., resistance is futile) What Can We Do About Our Fears?

I then facilitate group idea generation while emphasizing that nothing is off the table. What can the team can do about their fears? Example actions that have come up with include:

Take responsibility for yourself. Acknowledging that you are becoming defensive or fearful. Try telling the person you are with that you’re starting to notice your own defensiveness and fear. Slow Down. Take space, stay quiet for at least a 10-count, take two deep breaths and check or change your posture. Confront your negative self-talk. See if you can switch from red-zone to green-zone self-talk. (Read more about attitudes and intentions.) Check your assumptions. Everyone must make many assumptions on a daily basis in order to get by. There is nothing wrong with making assumptions, and it would be impossible to live a normal life without making them. The biggest problem with assumptions is the rigidity with which we hold them. Explore your fear with conscious awareness, trying to understand the root causes, and ask yourself, “What am I trying to override?” Try to look in all directions. Start over. When you realize that you have become defensive or fearful, acknowledge that, take some action to reduce your defensiveness/fear and then start over. (Read more on uncovering your defensive patterns.) Look to the Future

No retrospective is worth its time unless it results in a plan for some things to change. So, I ask each participant to come up with a self-action plan. I provide some thought starters that correspond to the four windows:

Personal What I’m expected to do is… I want to learn more about… I should ask for help when... Relational One thing we can both stop/start doing is…. We are both motivated by…. What we don’t dare to do yet is… Organizational What I expect from my team leadership is…. The reason the team is at risk is…. What the team needs most is…. Environment I’m proud of our team/business unit/company when… What our stakeholders can expect from us is…. The reason our value stream can be blocked is… 

To wrap up, I ask if anyone would like to share their plans with the group. (This is where a facilitator’s ability to withstand awkward silence comes in handy!)

I’ll share with you a facilitator secret. If I suspect a team I’m working with doesn’t yet have a solid foundation of trust, and as a result the majority is hesitant to be vulnerable in front everyone, I will have a “plant” (someone I’ve spoken with beforehand) volunteer to speak up first. Sometimes all it takes to open the gates is for a single individual to step up and do something that feels unsafe and uncomfortable.

Build Upon the Foundation

A few days after the exercise, I will share Brene Brown’s wonderful thoughts on vulnerability as "the birthplace of innovation, creativity and change” via her TED Talks and YouTube videos. Brown’s ideas will reinforce many of the concepts that likely bubbled up during the retrospective.

On any team, vulnerability-based trust is not a given, nor does it magically appear after a single retrospective. It will take time and many instances of individuals admitting their fears, their mistakes and taking risks that move them outside of their comfort zones.

I’ll share with you one more technique that I’ve found helpful in accelerating development of deep levels of trust on a team: Personal Maps – Getting to Know the Whole Human Being.

Take either exercise for a spin with your team, and feel free to share your experiences in the comments. What besides fear could be holding you back?

Leadership & Effective Decision Making on High Performance Teams

Trust, Vision and Ownership

In a previous post, I identified "3 Necessary Conditions for 'Going Agile'": Trust, ownership and vision. There, I used up my quota of blog space by focusing on trust and its impact on a high-performance team.

Here, I will continue that voyage by exploring ownership.

High Performance Defined

To get started, here’s a definition of a high-performance team from Wikipedia:

A high-performance team (HPT) can be defined as a group of people with specific roles and complementary talents and skills, aligned with and committed to a common purpose, who consistently show high levels of collaboration and innovation, that produce superior results. 

Common characteristics of HPTs include:

Participative leadership Open and clear communication Clear goals, values and principles Mutual trust Managed conflict Flexibly defined roles and responsibilities Coordinative relationship Positive atmosphere Continuous improvement

Nice, right? Who wouldn’t want to have more of that in their organization?

Delegation and Decision Making

With the characteristics described above, ownership of and attention to results is distributed as equally as possible. To accomplish this, decision making is taken up by various team members so that “the call” is no longer the domain of any single individual, especially not “the boss,” because command and control is simply too slow.

Distribution of decision making, aka delegation, is a great deal more than “Either you do it or I do it.” To avoid that mindset, I coach my teams to experiment with a matrix that provides four types of delegation:

Type 1: Decisions that only the leader can make/take - Type 1 can be made with or without consultation/discussion/buy-in with/from the team, though consultation is of course preferred. Type 2: Decisions that individuals/the team can and should make/take themselves, but need to first run by a leader - In the event of a “tie” or a disagreement on how to proceed, the individual/team calls it. If the individual/team is not willing to take accountability, then it reverts back to a Type 1; there is no “Type 1.5.” Type 3: Decisions that individuals/the team can make/take themselves, and inform the leader of after the fact – These decisions can be made either “contemporaneously” or “routinely.” Type 4: Decisions that individuals and team can make/take themselves. In other words, the “Just do it” method.

Technically, there’s a fifth type as well:

Type 5: Wait until you are told what to do by the leader.

We don’t want Type 5 to be an option. Why? For a boatload of reasons, including these: No one person can know as much as a talented team, and being told what to do demotivates talented individuals and removes accountability.

Where is the Team Today?

To begin the distribution journey, start by developing a picture of your team’s present conditions. Grab the team and the leader, a pad of post-its and some pens. Crowd source a divergent list of all the decisions that need to be made over the course of the coming month. Have an unfiltered brain dump and fill the white board.

Next, affinity map the individual decisions to converge on topics and themes. Using those groups, build a matrix, placing topics/themes/details in rows and each of the four delegation levels in columns.

Then, like planning poker, have each team member pick a number from 1-4 to indicate what type of decision they think should be applied to the topic at hand today. The range of votes may or may not surprise the participants.

Then, discuss the results and see if both the team and the leader can agree on “where things are.”

Newly formed teams typically start off heavily skewed with lots of Type 1’s, and maybe a few 2, 3, or 4’s, while more experienced teams tend to have a more even distribution of all types.

Envision the Future

Once both the team and leader have a picture of where they are today, rinse and repeat the poker rounds for where folks want to be in the not-too-distant future, like the next sprint or the end of the next quarter.

As a team matures and becomes more gelled and performant (retrospectives help on this path), things should move as far to the right of the matrix as possible. Loads of type 4’s, 3’s, a few 2’s and almost zero 1’s is ideal.

Why? Because moving decision-making deep into the team and away from “the boss” reduces bottlenecks and wait times, reduces waste and multiplies by orders of magnitude the speed at which a team can move, experiment and learn.

Put a date on the calendar to do this exercise again, perhaps in three months. A team and its leaders should be careful not to build the future state matrix once and then never revisit it out of a misplaced need for consistency or a fear of stretching out of their comfort zone. Instead, remember to regularly inspect and adapt. 

Group Decision-Making Models

As decisions move into the realm of the team, a common issue that comes up is how exactly they should go about making them without resorting to asking the leader: “What should we do about this?” (by the way, if you are a team leader and you hear that question too often, try simply answering with: “What would you do if you were me?” More on this approach here.)

There are many models that can help a team choose options when it comes to team decision types 2, 3, and 4 (consult first, inform after or JFDI, respectively). None of these models are perfect, and each has its own strengths and weaknesses:

Consensus – A collaborative approach. Typically requires that the majority approves, but also that the minority agrees to go along. In other words, if the minority opposes the idea, consensus requires that it be modified to remove objectionable features (see: Fist to Five). Since everyone gets a voice, consensus is both useful and appealing, although it is also potentially dangerous. It can quickly devolve into a battle for who is willing to argue their point the longest, or a watered-down compromise. Advice – A simple form of decision making where any individual can make the call. But, before doing so, they must seek advice from all affected parties as well as those with expertise on the matter. The individual, however, is under no obligation to integrate every piece of advice they receive. Random – The group leaves the choice to chance. Put the options in a hat and pull out the winner, roll the dice or flip a coin. Unanimity (or “12 angry peers”) – The group discusses the issue until an agreement is reached by all those involved in the situation. I Can Live with It – Anyone might have well-reasoned objections to a given decision. However, they agree to work toward the goals of the decision anyway. Solidarity – Unwavering commitment wherein individual will is suppressed for “the good of the group.” Rock Paper Scissors – See “Random.” :) Experiment

Different decisions call for different decision making models and types of delegation. Some teams may not be ready for all of the types covered above, and not all types are the best fit for any given team.

For best results, try to come to an agreement on the following:

(Type 1, 2, 3 or 4, or any other nomenclature that fits your culture) Which one will be used for the decision at hand today Which one the team wants to use tomorrow

See what works, see what doesn’t and continuously improve. Not only will the team experience a significant increase in productivity, but there will be a greater degree of trust and innovation as well. Once again, that is the promise of truly embracing agile.

3 Necessary Conditions for “Going Agile”

In the terrain of agile software development, there are three rivers - Trust, Ownership and Vision - which flow and converge into a confluence that helps to create the necessary conditions for a high performing, self-managing team. A team that adapts quickly to what its customers want, delivers great business value at a sustainable pace and is filled with happy people. In short, the ideal agile team.

This is true regardless of the industry, the geographic location and the organizational size. And, if you’re in the software development field like me, it makes no difference whether you’re using  SAFe, LeSS, DaD, XP, Scrum, Kanban, Scrumban or some new framework of your own.

Sure, at times the waters can be choppy and the currents unpredictable. But one thing is certain: a disruption of any of the three rivers will result in a true storm. Either the crew will start thinking about mutiny, or the boat will run aground on one of two shallows: command_control or anarchy_chaos

Beware the Twin Sirens:  Command and Control

The biggest challenge for leaders in a transformation is often that of leaving command and control behind. While they can easily articulate a clear vision of where to go, leaders  tend to have a hard time refraining from telling people how to get there.

In my experience, many of the difficulties these leaders face result from the fact that the leader can no longer play the old role of the hero with all the answers.

In his great book "Humble Inquiry", Edgar Schein says:

“Our culture emphasizes that leaders must be wiser, set direction and articulate values, all of which predisposes them to tell rather than ask.” (emphasis is mine)

The simple task of coaching and encouraging leaders to ask the right questions instead of providing the answers begins to catalyze them at every level. This reaction will in turn multiply the speed at which decisions can be made and new learning can take place. (For more on change, see my previous blog post: Personal Change: Unlock Successful Organizational Transformation)

Trust Above All Other Things

The transfer of power, which allows for rapid inspect and adapt cycles, requires great trust in individuals as well as in teams. Trust can be the difference between success and failure, especially as the boat heads into the rapids. In those inevitable whitewater situations, the importance of trust should not be underestimated. As Stephen M.R. Covey says in his book "The Speed of Trust":

“It [trust] is the one thing that changes everything. If you promote a high-trust environment where you have capable people who do what they say they are going to do, in my experience, anything is possible. If there is not a high-trust environment in place, virtually everything, including the most mundane activities, can feel like an ordeal for the group and impede progress. Over time, I have found that trust, based on competence and character, trumps all other attributes.”

Is Your Organization a High-Trust Environment?

A lack of trust in an organization can manifest itself in a multitude of artifacts and patterns:

Deadlines and forced commitments (instead of targets and goals) Roadmaps are created but hardly ever updated (instead of product visions that are combined with inspect and adapt) Waterfall over the wall / it’s not my job / us and them / barriers / silos (instead of collaboration / cross functionality / build / measure / learn) Individual KPI’s imposed from above (instead of team-selected accountability systems) Manager / subordinate performance reviews and stacked ranking (instead of 360º feedback and team / peer reviews) Small “Inner Circle” of communication / information / lack of transparency in “leadership" (instead of transparency and a circle of safety which extends to the “outer edges” of the organization) Focus on performance by numbers, burndowns and velocity (instead of a people-first approach which focuses on inner work life, team happiness/morale, OKR's, delivery of value and outcomes instead of outputs) Lack of mutual respect & transparency / leadership relying on “authority” / back channel communications / disengaged workforce / fear (instead of individuals and teams giving it their all with no holds barred)

Observations on the presence of the above artifacts and patterns are generally qualitative. If you’re more of a quant, take a look at the following two-part assessment that any organization or team can conduct. It comes from Pollyanna Pixton’s book "Agile Culture".

Assessment Part 1: Leadership

The first part of the survey measures leadership’s trust in their team.

Prompt: As a leader, indicate a score between 1 and 10 which response best reflects where you are for each row in the table:

Low (1-3)

Medium (4-7)

High (8-10)


I trust no one on my team.

I trust some of my team.

I trust my entire team.


I require that everything must be defined before the team can do anything.

The big things, such as cost, schedule, and scope, must be defined before the team can do anything.

I honestly accept and allow genuine ambiguity and uncertainty from my team.


My team cannot take risks without my approval.

I let my team take risks – but only when the risks are low.

I encourage my team to take risks in order to deliver value more effectively.




Average (total / 3)


Results: Average individual scores, and then average those across the organization. This will tell where leadership believes it is on the Scale of Trust (max = 10)

Assessment Part 2: Team Members

The second assessment gets to the roots of how team members feel about the level of trust coming from leadership.

Prompt: As a team member, indicate a score between 1 and 10 that best reflects how you feel about each row in the table:

Low (1-3)

Medium (4-7)

High (8-10)


I have to get permission to do anything.

Managers and processes sometimes get in my way.

I am trusted to do my work.


I am told what to do and how to do it.

I can sometimes find my own solution.

I am trusted to always be able to find my own solution.


If I don't do things the approved way, I am at risk.

There are certain low-risk things I can do.

I can take chances without feeling at risk.


I always must give the organization exact numbers.

I sometime can tell the organization when I am uncertain.

I can honestly tell the organization when I am uncertain without risk.




Average (total / 4)


Results: Average individual scores, and then the scores across all team members. This will reveal the team’s position on the Scale of Trust. (Max = 10)

What is Revealed? Compare both the leadership and the team member overall averages. Is there a gap? (If leadership and team scores are identical, then congratulations, everyone shares the same view!) How close to “10" are the final scores? Is there anything the organization can do to raise the score?? (If your scores are all at 10, share the secret sauce, please!)

If there is a gap between the averages of Part 1 and Part 2, this indicates a cultural disconnect honesty and openness.

On the other hand, low scores on both Part 1 and 2 indicate a different kind of problem: a known lack of trust on an organizational level.  As Ricardo Semler asks in his book "The Seven-Day Weekend" 

“If you don’t trust the people on your team, why are they on your team? For that matter, why are they in your organization?”

Running Pixton’s assessment will require a leap of faith. After all, agile doesn’t promise to fix anything, it just promises to bring the organization’s issues to light.

Point the Boat in the Right Direction

If there is a significant gap between the team and leadership assessments, or if the overall level of trust is low, ask yourself the following questions:

Can folks have an open discussion about causes for conflict that center around trust? Can leaders and team members develop a shared understanding of their expectations around trust? Can anyone generate new practices and agreements regarding trust? Understand What Trust Looks Like

Here’s the good news: there are various tools and exercises that can help guide the way by showing teams and leadership how to paint a picture of what “trust” means to them. 

Alexey Pikulev has run numerous divergent exercises over the years with agile teams to explore elements that influence trust. He has identified the following most frequently occurring themes:

Clarity Connection Compassion Value Competency Commitment Contribution Consistency Paint a Picture

Pikulev has put the above themes together in the form of a “canvas” that teams can use to paint a portrait of what trust means to them:

To get started, participants can begin adding items to each theme. They can fill out of the canvas in a couple of different ways:

Silent brainstorming on all the themes Rotating flip charts with one group per theme

I’d like to add two of my own suggestions to Pikulev’s approach. The first comes by way of Jurgen Appelo and his ideas from Management 3.0: as the participants are filling out the canvas with specific items in each theme, they should consider four discrete aspects for each theme:

Trust from leader(s) to the team (Part 1 assessment) Trust from the team to leader(s) (Part 2 assessment ) Trust among team members Trust in oneself

The second suggestion I’d like to add is that participants label each item with either a “+” or “-,“ thus creating a force field analysis where “+" indicates driving factors (catalysts/nourishers) and “-" indicates restraining factors (toxins/detractors) with regard to trust.

Once the canvas or flip charts have been populated with ideas, the participants can group and converge the items. They then run a voting/ranking exercise based on two characteristics:

Importance: Rank the relative importance of each converged item via dot voting Influence: Rank the team’s ability to impact a change in each converged item

At this point, participants will have constructed a pretty clear image of what “trust” means to them. They should have a firm grasp on the following:

Things that add to trust and things that take it away What factors are collectively important for creating trust What the team feels is within their current sphere of influence to change, and what they feel is outside their control Avoid Scylla and Charybdis via Ownership

In light of the results of both the trust assessment (which shows where things currently are) and the trust canvas (which shows where things could be), what kind of picture emerges? Have areas of current or future conflict reared their heads?

Often, the important issues need to be resolved through a change in delegation and a realignment of ownership. However, big gaps in ownership and trust are likely to change only with intervention from powerful allies within the organization. Instead, explore things through the lenses of “start, stop and continue” or “keep, add, less and more” (or any other retrospective technique). Collectively come up with safe-to-fail experiments,  gradually nudge the delegation levels deeper and deeper into the team, ensure continuous feedback, honor the prime directive and always inspect and adapt.

In short, don’t be afraid to set sail the agile way -- you're sure to make it past the treacheries of a transformation without losing any crew.

Enjoy the Journey

The right kind of organizational environment – one that is filled with mutual and ever-growing trust, ownership and vision – creates a palpable flow of energy and innovation. It fosters teams that can respond quickly to changing currents and obstacles, and enables a voyage where everyone knows and owns the results of their efforts.

It results in a productive and joyful journey that delivers delight not only to an organization’s customers but to all members of its crew as well.

And that is the promise of truly embracing agile.


Personal Change: Unlock Successful Organizational Transformation

Here we are, about month and a half into the new year. According to Gold’s Gym, it’s also the “fitness cliff” - the week most of us will stop going to the gym.

Why is it so hard to keep those resolutions, to make changes stick? After all, there are only three things one needs to know to embark on change:

Where we are (me: a bit over 14 stones) Where we want to be (a stone less) The means we should try to maneuver the territory between #1 and #2 (eat less, exercise more) Old Habits Die Hard

One reason individual change can be so difficult is the power of habits. All of us have created many routines over the years. These behaviors have not only been responsible for our success, but have also helped shape our inner identity. We have been rewarded for certain behaviors, which we then strove to maximize. And we have likely been disincentivized (punished) for our non-compliant behaviors.

Meet Your Inner Reptile

One of the biggest obstacles to modifying our habits is our amygdala. That element of our brain structure gets direct inputs from our senses. It is highly pattern-focused, and processes many of our memories and past experiences.

The amygdala has a direct line to the neural networks that activate both our reward (approach) and threat (avoid) circuitry. It is very, very sensitive to danger and does its computations rapidly, well before we have had a chance to think things through with our much newer (and much slower) brain structures.

That ancient part of our brains helped our ancestors stay alive long enough for us to emerge from the evolutionary tree.

Thank Goodness for a Neocortex

Fortunately, we can work with the adaptive nature of our newer gray matter - our neocortex - to help us make change happen and stick.

Social neuroscientist David Rock has done extensive study into how the neural networks of both our older and newer brain structures impact our behavior in groups. I believe his model offers a key to unlocking successful change at an individual level - which then can cascade to the organization.

Rock’s SCARF model looks at the following five areas of social interaction:

Status – Relative importance Certainty – Ability to predict the future Autonomy – Sense of control over events Relatedness – Sense of safety with others (Are you my friend or my foe?) Fairness – Perception of fair exchanges (Are the rules of the game are clear?)

Being aware of these five domains and their influence on our behavior during periods of change will help each of us to get in touch with what might otherwise remain buried deep in the older recesses of our brains.

This understanding will help us when it comes time to making new kinds of decisions and taking new actions. It will help us manage our emotions and our stress levels when dealing with the uncertainty that accompanies change, when the path forward is unclear.

Gaining control over our emotional reactions to the stress of change and being able to train our neocortex to inhibit our amygdalas will have an added benefit of making us smarter. I’m not kidding here. Studies have shown that when we are in a stressed or threatened state (i.e., amygdala on high alert), there is literally less oxygen and glucose for the neocortex’s cognitive functions.

Unwrapping the SCARF

Let’s explore a couple of elements of this model in the context of a middle manager making individual changes to move from a command and control attitude to an agile mindset.

Our manager has likely attached much internal meaning to the importance of her status as a boss. She may have even responded in the past with aggression should her power be challenged (“We can’t possibly deliver X scope by Y date, boss”): “It’s my way or the highway!”

This is because a threat (perceived or real) to her status activates exactly the same primal neural networks as a threat to her life. And cortisol, the stress hormone, flows fast. That vigilant amygdala processes stimuli well before things reach her conscious awareness.

Well, that now presents a problem, eh? To be successful on the journey of embracing agility, our middle manager has to look at things in a very new way … decisions will need to be distributed to the wisdom of her teams, not addressed by hierarchy. And if using a Scrum framework, the team will not be dictated scope and delivery dates, but will themselves decide how much of a workload to accept in a given iteration.

Fortunately for our manager, there are tools that will help build a bridge to a new way of interacting:

Team Agreements Delegation Matrices Definition of Ready (DoR) Definition of Done (DoD) Enabling Self Learning Teams

Created in a spirit of collaboration with the manager’s teams, these tools can develop an environment of greater certainty, autonomy, and fairness, paving the way for good change - and not just for the manager.

The Power of Iterative Change

But as mentioned above, it will take time for our manager to change her ways, to move out of her habit-realm (See above: Old Habits Die Hard). Her evolution will likely be bumpy as she trains her neocortex to inhibit her amygdala.

In the beginning she will start to catch herself after the fact of an amygdala hijack. (“Damn, I just [gave out an order, provided the ‘right answer’, yelled at the team]…”) During her next stage, she will catch herself in the act (“WTF is wrong with them! typing… getting ready to hit reply all… oh wait…. save draft instead of send.”) Emerging to neocortex domination, she will think about things before she acts. (“Feeling the need to say something that really what’s best? Let me count to five first…”) Arrival: She says and acts in a new way (or in some cases does not act) without forcing herself to think about it.

All along this path, people will value our middle manager differently. Not because of the implied power of her position but because she is changing in a way that brings out the best in others. Voilà: Status reward.

And here’s a really cool thing: People think about themselves using the same neural networks they use for thinking about others. As our ex-command and control manager begins to make breakthroughs in her own growth, doing better than last time, her own internal reward circuitry will be activated!

Unlocking Organizational Transformation

Sure, it can be hard to keep those New Year’s resolutions. However, the good news is that with conscious effort (and the support of a good coach), we can make changes that stick.

Along the journey, we will need to pace ourselves, taking time and making space to:

Pause and reflect Accept and learn from failures (don’t sweat ‘em, just don’t stop trying) Celebrate accomplishments, big and small Expect the unexpected

And since all organizations are composed of individuals, this collective pursuit of individual change will lead to greater things.  

As we make breakthroughs in our own growth, we will likely become more aware of potential changes to organizational systems – compensation, flexible work arrangements, extrinsic motivations, information flow, training, on boarding and a vast range of other structures – that can have a huge impact the SCARF domains of our environment.

All of this is the master key to unlocking successful transformation at the scale of our organizations.

Navigating Complexity aka Cynefin for Dummies

For some time now, I’ve been working on getting a better grasp of the Cynefin framework and the related topic of Complexity Theory. This is mostly because I kept hearing something to the effect of: “We’re working in a complex adaptive/emergent system …” as well as, “Complexity: it’s the science of the 21st Century!” So I am trying my best to figure out what the heck folks are talking about.

In this post, I share what I’ve discovered so far.

Meaning of “Cynefin” (and How to Pronounce It :P)

The word “Cynefin” is Welsh, it is pronounced kin-ev-in and it has no direct translation into English. Some of the best explanations I’ve found are: “a place to stand,” “usual abode” and “habitat.”

Dave Snowden, a Welshman and scholar, came up with the Cynefin framework circa 1999 as a way of providing a typology for exploration and decision-making. In the simplest sense, the framework is a tool to help you know where you are (the “habitat”), so you know what you might do or how you might behave (no sense trying to swim if you’re on top of a tree …).

Five Places to Stand

Snowden’s Cynefin framework has five habitats or domains:

Obvious Complicated Complex Chaotic Disordered

In common usage, the words “complicated” and “complex” are often used synonymously, and that can create a bit of confusion. Take a trip with me through all of the domains and let’s see if I can tease the differences apart.

1. Obvious = Easily Knowable

In this abode, the relationships between cause and effect are, well, obvious. This domain is sometimes referred to as simple. Think of a table lamp. If you turn the switch and it doesn’t work, I’m pretty sure you know all the things you need to know to troubleshoot. Check if the lamp is plugged in. Check if there’s power at the plug. Change the light bulb, etc.

In Snowden’s framework, the best approach when you know you are in an obvious place is: sense, categorize, respond.

Sense the light doesn’t work Categorize the problem (power supply or bulb?) Respond appropriately (plug lamp in, turn on breaker, change the bulb.)  

In this domain, you can observe directly (look at the plug, the circuit breaker, and then apply best practices (plug something else that you know works into the socket, swap bulbs). Your results will be quite predictable.

2. Complicated = Not Simple, But Still Knowable

In the complicated domain, the relationship between cause and effect requires analysis and investigation combined with the application of expert knowledge. And the results, while possibly incomprehensible for the novice, will be predictable for the expert.

For example, take my computer (please do, it’s really old …). There’s quite a bit that I know I don’t know about its inner workings and why it might not perform the way it should. But there are fortunately plenty of experts who do know.

In fact, they could take my aging Mac apart into its many constituent pieces, figure out what’s wrong and put it back together (adding whatever new gizmo it needs) and it will work as it should.

And these experts could do this an endless number of times (provided, of course, I have the budget for their services). Rocket surgery lives in this domain, too. The approach will be: sense, analyze, respond. Good practices (the right people, the right process and sufficient time) will work every time.

3. Complex = Not Fully Knowable, Not Fully Predictable

When the relationship between cause and effect can only be perceived in retrospect, but not in advance, we are in the complex domain. This is the haunt of unknown unknowns--a  phrase that became popular for a few minutes during the George W. presidency.

Expertise in a particular subject matter may be helpful, but unlike in the complicated domain, it is not necessary or sufficient to control the outcomes.

I came across what I think is a great illustration of the complex domain when I watched a 4-minute video describing the reintroduction of wolves into Yellowstone National Park.

The presence of a small number of wolf packs, absent from the park for over 70 years, literally changed the course of rivers in less than a handful of years. Did anyone expect that? Unlikely. Sure, humans influenced it, but we could determine only in hindsight what would happen and why.

When traveling in complexity, the approach is probe, sense, respond.

Using the wolf example, you’d introduce an apex predator and measure things like wolf population, deer/elk/moose population, small rodent population, stream clarity, raptor count, tree density.

And then respond based on the what you’ve learned from the feedback loops. For example, add more wolves or reduce them. It is a safe-to-fail experiment. (Thanks to Ralph van Roosmalen for the metrics ideas!)

4. Chaotic = Neither Knowable Nor Predictable

In the domain of chaos, there is no relationship between cause and effect at a systematic level. Any moment is one that can have both unforeseen as well as incredible consequences. Decisive steps are called for all the time, yet what will happen is unknowable.

The approach in the habitat of unknowable unknowns is: act, sense, respond. Smash the glass, grab the fire extinguisher, aim at the base of the flame and pull the release. And then maybe run …

When in the domain of chaos, our behaviors tend to be reflexive and rightfully so. We don’t have the time to experiment. While we may learn something, it is often through serendipity.

5. Disordered

The fifth domain is disorder, which is the state of not knowing what type of causality exists. I don’t like to travel there. And when I’m there, I try to get the hell out as quickly as possible.

Cynefin and and Software Development

You might be wondering, “So what does this have to do with software development?” Me, too!

Circling back to my introduction: it’s important to know where you are operating, so you know how you should prepare, how you should behave and what approach you should take regarding measurement and feedback loops. Otherwise you may end up making decisions based on biased or simply inaccurate information.

The Ordered Realms

Back to the Cynefin domains themselves and the context of agile development. The obvious and complicated domains both lie within the boundaries of “ordered” systems. With ordered systems, we can relate cause and effect with confidence. If we take a certain action, we know what the effect will be; given an effect, we can determine what caused it.

A linear notion of decision-making works well. Got a display bug in a browser? Fix the underlying CSS. Lots of error messages in your RAID logs? Find the bad drive and swap it out.

In ordered domains, building new software tends to be pretty straightforward. Fixed processes generally work fine: Identify what you believe are the most valuable things. Do them first. Take measurements (which will be pretty straightforward) and then build more valuable things.

If you find yourself in one of the two ordered habitats, obvious or complicated, on a regular basis, you are safe following recipes and protocols. Also, please send me a postcard. Remind me how the weather is there.

The Unordered Realms

On the other hand, if you’re like me, much of your time will be spent in one or two of the three domains that are unordered: complex, chaotic or disorder.


If you don’t know where you are, you’re in “Disorder.” Your first priority will be gather enough information to know what you know or what you don’t know so you can move out. Are you under a DDOS attack or is a router down? Anywhere will be better than disorder.


In chaos, like complex, no amount of analysis will allow us to predict the full behavior of things. We can not determine in advance what will cause a particular outcome. While planning might be useful, the plan itself will not be.

If you find yourself in the realm of chaos, speed of response is vital. Triage. Stanch the bleeding. Stabilize the network. Get the servers back up and running. Figure out the root causes later. The only advance planning that makes sense is to have a known crisis management crew. If stuck on what to do, perhaps explore an oblique strategy to break the creative block. Novel solutions will likely be sufficient to help you stabilitze and move to another domain.


Last, and not least, we come to complexity, which got me started on this adventure. In complex systems, even though the relationship between cause and effect is often fuzzy, things tend toward being somewhat stable. So we can run experiments and see what happens.

In fact, we ought to run a series of experiments or a number in parallel to maximize our potential for learning. More planning won’t help. The best thing to do is just get started, launch many probes, measure many things, and set up lots of feedback loops. Then we can get a holistic perspective of what is happening. We can begin to see patterns and respond with amplification or dampening.

Our solutions and processes will continually adapt. This is the playground of complex emergence.

The Terrain of Complexity

The domain of complexity covers a varied and expansive terrain. The Stacey Matrix has helped me navigate by using the lenses of agreement and certainty. (Shout out to @scrummando for pointing me to Ralph Stacey’s work.)

In its simplest form, we can draw the matrix in two dimensions as below and overlay four of the five Cynefin domains. I acknowledge this is not a perfect representation of the world around us, as the borders and transition from one domain to another are not so neat and tidy, and with any particular situation, there may be islands of one domain floating in another.

(And maybe we could use a third dimension like entropy, or algorithmic information content ...)

Nevertheless, the 2-D view provides a useful perspective, a way towards greater awareness:

As we get further along the x-axis, the linkages between cause and effect become less clear, and we have less certainty. The y-axis indicates the level of disagreement about what we should (or should not) do about an issue or a decision.

If we pause to find out our general X-Y coordinates, we can design experiments to probe, poke and prod appropriately.

For example, would more or less certainty be helpful (maybe a shared mission/vision) or is it perhaps agreement we should be exploring through coalition building, negotiation, or compromise? How close to chaos are we? Is that an area to be avoided, lest like Wile E. Coyote we end up at the bottom of a canyon, or is it a place where some great innovation may be found? How safe would it be to fail?

Wrapping Up

I want to circle back to the complicated and complex domains, which as I mentioned earlier are easily conflated. I found two things that help grok the differences. First a recent article by Will Allen that explored the art of leadership and management within complicated and complex systems. Notice the contrasting brushes, palettes and approaches that Allen highlighted for each domain:

Roles, Tools and Approaches for Complicated Role defining – setting job and task descriptions Decision-making – find the “best” choice Tight structuring – use chain of command and prioritize or limit simple actions Knowing – decide and tell others what to do Staying the course – align and maintain focus Roles, Tools and Approaches for Complex Relationship building – working with patterns of interaction Sense making – collective interpretation Loose coupling – support communities of practice and add more degrees of freedom Learning – act/learn/plan at the same time Notice emergent directions – building on what works Game Play

The second thing I found that helped me tease apart complicated from complex was a LEGO Serious Play exercise posted by Andrea Tomasini. I’m a big fan of play time, so I was very excited when I came across Tomasini’s game.

In under an hour, it provides an introduction to four of the five Cynefin domains and helps participants explore the effectiveness of different communication and leadership styles along with the impact of planning in each domain. Check out the Cynefin Lego Game on

Happy travels!


Is ‘Meeting’ Really a Dirty Word?

Just the other day at stand-up, I heard a dev team member say: “Yesterday I didn’t get anything done. I had a day of meetings.” As the team’s coach, I said nothing at the scrum, but took the opportunity afterwards to ask a question of the team: “Have you heard of ‘The Law of Two Feet’?”

I received many questioning glances. So I elaborated:

If you see a meeting as an opportunity to connect, learn, educate, share, collaborate and/or inspire, then by all means, use your two feet to join it. On the other hand, if you find no value in a meeting (proposed or in progress), be polite and see if you can get things on a better track. If not, use your two feet and walk away. (Feel free to steal a line my friend Jay Hrcsko uses: “Excuse me. I have to return some videotapes.”)

I don’t read the minds of my teammates, but I’m pretty sure at least a few folks thought that I had finally gone off the deep end. “Don’t show up or (gasp) walk out of a meeting that an SVP called?!”

They’d rather sit there, multitasking, pretending to be engaged? Maybe I need to print up some get-out-of-jail-meeting-free cards.

Only Two Kinds of Meetings

Let’s cut to the chase: there are only two kinds of meetings: good meetings and bad meetings. That’s it. Nothing really in between. Sure, we could start to subdivide the good meetings into types: alignment, creation, one-on-ones, etc. But let’s stick with big buckets.

Good Meetings

There’s a simple formula to evaluate if what you’ve been invited to / are attending is a good meeting. It’s a formula that I learned from Lyssa Adkins: Good Meetings = P+O+W+E+R

Purpose: Is there a clear, anticipated purpose to this meeting? For example, make decisions, solve problems, exchange ideas and information. Do we plan to discuss the “right stuff”? Is there a selective agenda? (An upfront purpose doesn’t rule out the possibility of some good improv….) Outcome: Are we all clear on what we expect to gain, produce, decide, solve or get as a result of this meeting? WIIFM: Do I know what’s in it for me? Will I gain value? Will I provide value? Am I interested in the items on the agenda? Will this empower me and / or my team? In his book, “The Agile Team Facilitator,” Martin Alaimo breaks the WIIFM variable of the formula into two parts: recognition and attraction. These tell each invitee why their participation is important, and explains the benefits they can obtain by showing up. Expectations: Are things like start time and end time clearly communicated? What kind of preparation is needed? Is there sufficient time to prepare? Is everyone clear on the decision-making process (e.g., majority vote, full consensus, consensus minus one, unanimity, etc. See Decision Making Patterns for Teams)? Are there clearly communicated expectations about listening? How about actually showing up? If you aren’t in a culture where all meetings are optional, clarify things. Roles: Will everyone who needs to be there actually be there? Who’s facilitating the meeting (some folks call this role the referee)? Who’s leading which topic on the agenda? Who’s taking notes? Who’s the timekeeper? Who owns each action item produced? (Another sign of a good meeting is that we don’t have to have it a second time.) Bad Meetings

There’s an even simpler formula to tell if you’ve got a bad meeting arising: 

Ask, “Can what this meeting is attempting to accomplish be done any other way?”

If the answer is “yes” – you’ve got a bad meeting. Or as VM Brassuer defined it many years ago: Selfish, Haphazard, Informational and Tardy. Which has a nice acronym to it. Those are the meetings you don’t want to step into.

First: Consider Asynchronous Communication

Before you go ahead and schedule that next meeting simply out of habit, pause and figure out its purpose. You might start by roughing out an agenda. When you have that, ask yourself: Is there another way we can address these items beside having a meeting? For example, would some other communication method like chat, email, wiki, etc. work just as well, if not better?

The advantage of async communication methods over a scheduled interruption – whoops, a meeting – is that the “conversation” can easily be quarantined. Someone who doesn’t mind being interrupted can monitor these channels and respond – if they choose – in near real time.

Someone who is in the zone can minimize their Slack/HipChat/email window, turn on DND and respond at their leisure. (See Disturb / Do Not Disturb.) 

A word of advice: when you go async, make sure your communication style is actionable. Don’t rush things. After all, you’ve got extra time now that you don’t have to go to a meeting. Use it well. (See Slowing Down to Speed Up – Effective Asynchronous Communication.) 

When You’ve Ruled out the Impossible... Have a Meeting

It seems to me that Sutherland and Schwaber must have had an aversion to meetings. They avoided the word completely back in 1995 when they codified Scrum. The framework has a number of prescribed events that to the uneducated observer look a lot like dreaded “meetings.”

These events or ceremonies really are accomplished best via synchronous communication and discussion: retrospectives / post-mortems, 1-1 reviews, sprint planning, kick-offs, backlog estimating, demos. Add in monthly and quarterly strategic planning sessions and yep, we’ve got ourselves some meeting time.

So why don’t we make the best of use of that time and, like any good agilist, inspect and adapt how we are using it?

Feedback Loops

Find out how your meeting went by using a retro technique from Growing Agile. Reserve the last two to five minutes and ask the participants:

Was this meeting valuable? Why or why not? Did you pay attention all the time? Why or why not? Did everyone else pay attention all the time? Why or why not? Which parts felt great? Why? Which parts felt awkward or odd? Why?

 If you don’t yet have sufficient psychological safety so that people will vocalize their thoughts, hand out sticky notes instead. Ask people to populate a feedback wall, right next to the exit door.

The Value of Synchronous Communication

I don’t know about you, but I haven’t yet found a way to get rid of meetings completely. And I’m not sure that should be the goal, although I heard someone say that was their definition of a successful agile transformation: No meetings!

Cut meeting time in half, and then half again? Yeah, I can do that. I’ve made it a point to schedule short meetings. If I think we need 30 minutes, I’ll schedule 20. An hour? I’ll book 50 minutes. But get total meeting time to zero? Unlikely.

Planned, as well as ad-hoc synchronous, communication, aka meetings, reduce the potential for misunderstanding (provided folks say what they mean and mean what they say). Good meetings provide the opportunity to come up with meaningful solutions to difficult problems, to collaborate, to get to a point of common understanding efficiently – more so than 20 back and forth Slack, JIRA or GitHub comments.

Good meetings help make sure teams don’t just “get stuff done” but that they get the right stuff done at the right time. Your time is a limited resource, use it, along with your two feet, wisely.

30+ Metrics for Agile Software Development Teams

At the end of a Scrum team’s iteration aka “sprint,” the team has a velocity. In some cases, it is based on the number of story points they have completed within the sprint’s duration; other teams simply count the number of user stories done. [1]

Velocity (story points or user stories completed in a fixed time period) is one of the most commonly used metrics in agile software development. It is also one of the most abused. Teams and stakeholders fall into the trap of believing “increasing velocity” is a noble goal. It is not.

Why not? Because instead of focusing on delivering working software that has business value for stakeholders, the team will be concerned with simply delivering more story points (e.g., to meet a target velocity).  

While team velocity might (arguably) be a good long-term predictor, if it becomes the team’s focus in the short term, it can become a negative influence. An increasing velocity doesn’t necessarily mean things are getting better.

For example, a team could achieve a higher sprint velocity by skipping tests or sacrificing quality with the side effects of brittle code, technical debt and escaped defect fix cycles. This will result in a lower velocity in the long term. (See the Hawthorn Effect: that which is measured will improve, at a cost, as well as Goodhart’s Law: when a measure becomes a target, it ceases to be a good measure.)

Also, a Scrum team’s velocity is a lagging indicator – like unemployment. You don’t fix unemployment by focusing on the rate of employment. You fix unemployment by fixing the economy. In both cases, you are working in a complex emergent system, and the causes for increases or decreases in any metric are not immediately obvious nor predictable.

Measure Many Things

I’m not suggesting that an agile development team should never look at its velocity chart. But to help monitor experiments aimed at continual improvement, a team needs to measure more than just one thing.

Only when trends in multiple metrics are overlaid (technical as well as human) can a team begin to get a holistic perspective. And those multiple viewpoints, along with their variations, stability and trends can only serve to raise a flag that says “Look deeper here … what is going on?”

30+ Metrics for Agile Software Development Teams

To help jumpstart a “measure many things approach,” I have assembled below a listing of metrics for software development teams. (Shout out to Jason Tice @theagilefactor for the main buckets.)

The list is intended as a starting point, not an exhaustive inventory. Use the ideas as conversation openers for coming up with things that make sense for your development team. If you’re working outside of IT, perhaps on a sales team or a customer support team, you can use these buckets to stimulate your brainstorming.

Process Health Metrics

This category assess day-to-day delivery team activities and evaluates process changes.

Cumulative Flow Diagrams Control Charts Percent Complete and Accurate Flow Efficiency Time Blocked per Work Item Blocker Clustering Release Metrics

This group directs focus on identifying impediments to continuous delivery. 

Escaped Defects Escaped Defect Resolution Time Release Success Rate Release Time Time Since Last Release Cost Per Release Release Net Promoter Score Release Adoption / Install Rate Product Development Metrics

These help measure alignment of product features to user needs. 

Customer / Business Value Delivered Risk Burndown Push / Pull Product Forecast Product Net Promoter Score User Analytics Technical / Code Metrics

The following help determine quality of implementation and architecture. 

Test Coverage Build Time Defect Density Code Churn Code Ownership Code Complexity Coding Standards Adherence Crash Rate People/Team: The Human Elements

This group of metrics reveals issues that impact a team’s sustainable place and level of engagement. 

Team Happiness / Morale Learning Log Team Tenure Phone-a-Friend Stats Whole Team Contribution Transparency (access to data, access to customers, sharing of learning, successes and failures via sprint reviews) One of my favorites from Geoff Watt’s "Scrum Mastery:" Imagine a team mapping themselves against the 12 agile principles over time 

For more “human” options, see Team Health Checks as well as The Progress Principle. 

Important Considerations

With so many great metrics to choose from, a few obvious questions arise: How many should a team use? For how long should they use the ones selected? And who gets choose? My thoughts: 

Teams might decide on one or two important metrics to add to their current dashboard. They can then add one or two more over time. On a well established team, three, five or perhaps up to seven maximum might be in use at any given time. Any more, and they’ll likely get into analysis paralysis. The useful lifespan of a single metric could range from a couple of months to a couple of quarters. Probably never shorter than three iterations. Coaches or managers should not mandate any specific metric, nor a minimum number of metrics. Metrics are for teams to learn and explore how they can improve themselves through inspect-and-adapt cycles. Teams should choose those metrics they think will be useful in that regard. While some metrics can scale to teams of teams, i.e., the larger organization where all teams “own the metrics” for their parts of the company pie, neither teams nor managers should compare metrics across teams. Sure, use metric comparisons to start conversations, to share knowledge and insights gained across teams. But never: “My X-metric is better than yours …” -- never!

When selecting metrics, a team should be able to answer: 

Why “this metric?” – why does it matter? What insights might we gain from it? What is expected to change? How might it be gamed or misused? (Remember when Wells Fargo offered big bonuses to employees that cross-sold financial products to customers?) Is the metric measuring the team, and not individuals? What are some for trade-offs / costs of improvement? Working to improve one thing may temporarily reduce another (e.g., predictability may increase at the expense of throughput). How often would we like to “take a data point?” How long will we run an experiment related to this metric? (What is the half-life?) How will we know when we’re “done” with this metric (it has served its purpose, and it’s time to retire it and consider another)? Is this metric a leading or lagging indicator? How will we make our measurements visible – to promote knowledge sharing, collaboration with other teams and trust with our sponsors? Remember: 

As Doc Norton pointed out in his "Velocity is NOT The Goal" talk (ScrumGathering 2013):

That which is measured will improve, at a cost. Which metrics are used should be arrived at by team consensus – not mandated by management. When a measure becomes a target, it ceases to be a good measure. Look for and understand trends, not hitting magic numbers. Correlation may not mean causation, but it sure is a hint. (See Friedman’s Thermostat) Make your metrics visible.   Expose how the team feels in near real time. Team happiness is a leading indicator of performance. Identify what’s going on now and they’ll likely know what is going to happen soon.

(For more from Doc, see his recent book Escape Velocity -

Radiate the Information

Did you catch that I snuck visibility in there twice? Sharing your metrics with stakeholders can be a bit scary, especially if you’ve ever been in a place where metrics have been used as a weapon, but take a leap. Be brave. Show them to others.

As Jos de Blök, director of Buurtzorg Foundation says in the forward of Geoff Watts’ “Scrum Mastery” book, “[Breed a culture of] trust and responsibility instead of control and suspicion.”

Only with transparency can we collectively look through enough lenses to build an integrated and holistic view. And then we can collaborate on improving “all the things.”

A team should not be simply striving for ever increasing values, as sometimes slowing down might be called for. Instead, teams should look at variations in their metrics, and then dig to get to the root causes of that variability (or at least develop a few good hypotheses). By striving for consistency and stability (i.e., predictability) teams will find that increased performance - delivery of value - will come as a natural side effect.

What are your thoughts? Please let me know in the comments below.


1. While diving into #estimates vs #noestimates is way beyond the scope of this article, I am defining story points as a unitless, relative measure of complexity + risk + effort involved to complete some user-facing value. I want to rename them “story pints” so they can be redeemed after the sprint review at the local pub. But that, too, is outside of my current scope.

The Power of a Good Story

"Storytelling is the oldest way of passing along information, in which facts can be relayed as powerful statements and where new ideas can blossom.”

-Jurgen Appelo 

Ever since the dawn of our species, we’ve told stories.

We’ve sung them, told them around campfires, painted them on cave walls, drew them on clay pots and canvases, woven them in tapestries and carved them into stone. Eventually we wrote them down.

Today, we share stories via sticky notes, podcasts, town halls, planning meetings and daily scrums.

Science indicates that our brains become more active, more engaged when we hear or tell a narrative. Could it be that as a species we are hardwired for a good yarn?

So let’s explore stories in agile software development, and how they impact continuous improvement and organizational change.

User Stories

One of the first kinds of stories we encounter in agile development is the “user story.”

The simplicity of the composition "As a <type of user, “Actor” or “Persona”>, I want <some action> so that <some goal/achievement>” belies its power.”

A well-told user story starts a conversation. And that discussion eventually leads to a dev team masterfully crafting ones and zeros into an increment of customer value.

I believe a big part of this “magic” happens because the team is able to develop empathy with the persona through the open nature of a user story. That understanding then helps drive decisions and solutions that will satisfy the end user--one of the main characters in the play.

User Story Mapping

Jeff Patton provided a way for agile development teams to tie user stories together in the form of a visual illustration: the user story map. This view of the customers’ journey through a product helps the team see the full narrative as well as to stay in tune with their end users.

As on any jaunt, a well-crafted map will help ensure a pleasant trip for all, perhaps with a little bit of adventure, a lot of reward, but definitely without any ordeal or descent into the underworld (unless of course your dev team is working on the re-release of Tomb Raider).

Building Competencies through Storytelling

The last, and certainly not least, principle behind the Manifesto for Agile Software Development is: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."


At the end of an iteration an agile development team will find its way to a retrospective. There is no shortage of retro techniques for a team to dive into.

One of the classics is “Start, Stop, Continue." Continue and stop tell a story about the past, while the start looks into the future, exploring what might be. And that future is where the team gets to make “more effective” fact, not fiction.

Another well-loved and used retro technique is “Sailboat/Motorboat,” which brings in the wonderful use of a metaphorical journey to help a team visualize and improve their working system.

Then there’s the team journey map technique. The retro journey map exercise reminds me of the Aboriginal Australians’ method of songlines.

Songlines enabled people to navigate by repeating the words of the song and were perhaps the original “journey map.” Alas, I have yet to find a place in agile software development where we utilize the art of telling a story through song in order to turn data into meaning (aside from karaoke on team night …).

Perhaps there’s a retrospective exercise tucked away in there somewhere …

Continuous Improvement

Many models that involve story telling have emerged to help agile teams continuously improve towards ever-increasing levels of brilliance. A few examples are:

Serious Play

Using things like Lego® or spaghetti and marshmallows, teams use metaphors to explore complex emergent systems. While it’s marketed by the folks at Lego as a "radical, innovative” process, I question whether that’s really the case. Like a good epic tale, serious play allows us to use imagination to form images that make a situation come alive before it occurs in real life.

Play allows us to describe something, to create something, to challenge and test our assumptions and to explore possibilities; and we’re able to do it all without running the risk of those real-life consequences of failure and escaped defects.


Improv is a story with no script, but a story nonetheless. Folks like Robie Wood at are training teams to resolve the ambiguity and the paradox that are inherent in the complex emergent domain of software development by using improv techniques to explore the stories as they unfold. He’s helping people develop plot lines they otherwise wouldn’t have seen.

And in Paul Goddard’s wonderful book “Improv(ing) Agile Teams,” the author devotes an entire chapter to storytelling. Goddard writes, “I believe that agile teams become more engaged when they harness the enjoyment and escapism that storytelling provides—when they re-imagine their projects as stories in their own right.”

Team Cohesion through Stories

The Agile Manifesto values "individuals and interactions over processes and tools.” If you’ve had the pleasure of working on a high-performing team, you’ll know the power of the emotional ties, the social bonds and the reciprocal trust that exists there. 

And I bet you those connections developed from storytelling - around the watercooler, late nights over beers or in the #random channel on slack. Chatting not so much about code, but about all the other things we humans bring with us. Our personal histories, our values, our motivations. The things that make you you, and me me.

Using a storytelling exercise like personal maps allows newly formed teams to share quickly those backstories, those key plots that have made each of us who we are today. And with that understanding we can get to a place of greater collaboration, and more effective interaction.

The Hero’s Journey and Organizational Transformation

The "hero’s journey" identified by Joseph Campbell, identifies the many patterns that appear across a broad spectrum of tales:

"A hero ventures forth from the world of common day into a region of supernatural wonder: fabulous forces are there encountered and a decisive victory is won: the hero comes back from this mysterious adventure with the power to bestow boons on his fellow man.” 

(Dang, if that doesn’t sound like many a software development project I’ve been on!)

Perhaps the ultimate hero's journey might be that of the organizational transformation. One that wants to transform from “here” to “there”—where there’s quite a distance to cover.

Harrison Owen reminds us of the power of the origin story in transformation via his seminal work “Spirit”:

“Stories are rather like maps; not much in themselves, but very helpful when crossing strange territories. Of course, we must always remember that the map is not the territory and when the map and the territory fail to agree, we probably need a new map. But even an old map can be useful for it brings to mind the differences between what we once saw and the way things are now. [Creating the] vision must be big, attractive and do-able - all three and all at once. Creating the vision is the first tangible step to be taken by leadership."

And the best way to communicate that vision is through storytelling--a way for strategy to be shared across every level of an organization.

In an organizational transformation, leadership needs to outline the plot: keeping it simple, empowering the characters, and then leaving plenty of open space that invites participation, nay, demands it of the participants.

The stage should be set as it would be in improv, with just enough information to get the story started, but not a stitch more. Then everyone can “yes, and …” to keep things moving.

And it’s that big, attractive, doable story that helps organizations transform from where they started, reincorporating the past, their “origin,” and continuing on the path towards a future vision, just like a good hero’s journey.

The Happy Ending … Or Another Beginning?

Stories of all kinds give us the power to move, to inspire, to guide individuals, teams and organizations 

Stories lay out the infinite possibilities of the future while keeping a connection to the past.

Stories give us the ability to comprehend the meaning behind those ochre marks on cave walls from 40,000 years ago, as well as those ones and zeros that we wrote just yesterday.

What stories will you tell tomorrow?

What do you think? Let me know in the comments below.