Changes and a Grand Experiment

After more than 20 years of blogging across four different domains, I’m changing platforms from self-hosting (WordPress, mostly) to Substack. I hope this pivot will simplify the technical side of my life and allow me to focus more on writing.

Please visit The Stoic Agilist on Substack and support my writing efforts by subscribing. You can also visit (self-hosted on WordPress, of course) to view the same posts that appear on Substack except they will be published approximately four weeks later than they appear on Substack.

The Changeability Decision Matrix

Responding to change over following a planThe Agile Manifesto

That’s one of the four values to the Agile Manifesto. It’s also one of the values that is commonly plucked from the context of three other values and twelve principles. Once isolated, it’s exaggerated and inflated to some form of “We can’t define scope before we start work! There’s too much discovery work to be done first! We don’t know what we don’t know! Scope (and requirements) are emergent!” That bends the intent of the Manifesto and disregards the context from which a single value has been extracted.

I don’t believe Agile practices ever meant for software development to be a free-for-all, a never ending saga of finding and implementing better and better ways to code something before a product can be released. Projects run like this never see the light of day, let alone a shelf to languish on waiting for a long since departed market opportunity.

What isn’t in the Agile Manifesto, but is implicit in the Agile methodologies I’ve worked with is the notion of decision points. These are the points around which change, to a small or large degree, is not allowed. At least not for a while. Decision points bring stability to the development process from which Agile teams can move forward with a stable set of assumptions. If subsequent discoveries inform the team that they need to revisit a decision, than they must do so. The key element is that the work subsequent to the decision is what generates the need to revisit the decision. It isn’t done arbitrary, on a hunch, or with minimal information.

There are numerous decision points that exist within Scrum and SAFe, for example. Stories are decisions. “We need to create this thing.” Acceptance criteria, definitions of ready and done, sprint duration, feature and epic definitions, milestones, minimum viable/valuable products are also examples of decisions. Some of these can be quite changeable. Stories, for example, can be refined many times prior to and during sprint planning. The description, acceptance criteria, definition of done, and effort estimation can change many times before a story is committed to a sprint. And there’s the decision point. When the team agrees that a story can be brought into a sprint and they commit to completing it before the sprint is over, they have made a decision and the story shouldn’t change on its way to being completed by the team. (As noted previously, the work on the story may reveal a need to change something about the story – maybe even indicate that work on the story should stop – but that should be an edge case and not part of common practice.)

To help teams understand these distinctions, I’ve developed a 2X2 matrix called the Changeability Decision Matrix. Its purpose is to help teams evaluate the effects of changing work in the queue. The horizontal axis goes from “Small Impact” to “Big Impact.” The vertical axis goes from “Few Changes” to “Many Changes.”

The two questions the team needs to ask when thinking about changing a decision they’ve made (acceptance criteria, story description, MVP, etc.) are:

  • Will this change have a small or big impact? They may consider any number of variables: cost, time, productivity, effort, etc.
  • Will this change require a few or many changes (lines of code, documentation updates, other components that consume the code, budgets, release dates, etc.)

Where the proposed change resides on the grid may be dependent on where the team is on the project timeline. Consider the Epic, feature, and story hierarchy: Early in the project – during the design phase, for example – there may be little more than features in the backlog. As placeholders for ideas, they may be quite volatile as new marketing information enters the conversation or obvious technical issues become apparent. So changing an epic or a feature may have a relatively small impact on the project and involve few changes. Most probably there won’t be any code involved at this point.

As the project progress and backlog refinement continues, epics and features will be broken up into large stories. More detail is added to the backlog and more time and money has been invested in the design so the epics and features are less changeable. If any changes are needed, it is probably that the impact of those changes and the number of things that need to change will be greater than it would have been during the design phase.

Eventually, as the project moves into high gear, the backlog will become populated with more and more smaller stories that can be easily estimated and planned into sprints and increments.

For the duration of the project, it’s likely most of the stories in the backlog can and should be responsive to multiple changes…right up to the point the decision is made to drop the story into a sprint.

The Changeability Decision Matrix is an easy way to evaluate whether or not an Agile team is pondering undoing a small or large decision by forcing the conversation around the consequences of making the change. If either of these two axis are not a good fit for your organization or what you consider important to consider, then change them to something that makes more sense to your project.

See also:

Update 2020.11.07

Here is a representation of these phases on a hypothetical project timeline.

The Emotional Bumblebee

I finished Lisa Feldman Barrett’s book, “How Emotions Are Made: The Secret Life of the Brain,” this past week. It’s the latest exploration in my decades-long journey to better understand myself and others. There’s a lot in this book and it’s been a paradigm shift for me personally. I expect the effects from the insights gained from Dr. Barrett’s work in my professional life will be equally seismic.

As part of this exploration and effort to understand what Dr. Barrett and others are discovering, I’ve been experimenting with different ways to organize and assimilate information. For years I’ve used mind mapping and its served me well. I continue to use this approach almost daily. Ah, but the relentless advancement of technology has resulted in new tools. My current favorite (meaning the one that so far matches how my brain seems to work) is a tool called Obsidian. It’s new and is evolving quickly. I’ve been using Obsidian to organize and study cognitive biases in a way similar to Buster Benson’s work. This past weekend I began a similar process with emotions based on Dr. Barrett’s work.

It’s early but it has already yielded many important insights and benefits. I began by collecting as many words I could find (currently, 514) that are used to describe emotional states or patterns. I then entered them into Obsidian, each connected to a single node, “Words that express emotion.” Here’s a partial screen capture of the Obsidian graph:

The graph is too big to fit on a single screen and have the words show. And Obsidian does not yet have an export feature for graphs into a standard image file. So I’m limited by screen real estate. Where I take this next…I’m not sure, actually. Probably a cycle of refinement and deep dive into definitions and descriptions. I can foresee the creation of a real-time tool for assessing emotional states using a circumplex. Lots of experimentation ahead.

There is a dynamic quality to the graphs in Obsidian that is part of the fun and path-to-insights with the information. I’ve created a video to show the effect and set it to Nikolai Riminsky-Korsakov’s orchestral interlude “Flight of Bumblebee.” If/when you read Dr. Barrett’s book, you will understand why I selected the bee theme. It’s a virtual emotional bee hive inside our heads and bodies. Be sure to expand the video to full screen for maximum effect. Enjoy!

Baseballs and Hockey Pucks

“Keep your eye on the ball!” I was always coached when learning how to play baseball. Seemed like reasonable advice while standing at the plate, facing down the pitcher for the opposing team. Certainly wouldn’t want to be daydreaming or casting my gaze to the horizon. It didn’t seem to help, though. I excelled at striking out.

Later…much later…I came across Wayne Gretzky’s quote: “Skate to where the puck is going, not where it has been.” I wonder if I had learned to figure out where the baseball was going to be and made sure my bat was there to meet it if I might have spent more time on bases. Keeping my eye on the ball didn’t tell me much about when to start my swing.

No regrets. I still love the game (as it was, not as it currently is.)

I think of this Gretzky quote when I watch product owners struggle with organizing their backlog. (I also think how tragic it is that the business world has beat this quote into an intolerable pulpy platitude.)

Ask a product owner what their team is working on today, they should be able to give a succinct answer. Ask them what their team is going to be working on in three months and watch the clock. The longer they can go on about what their team is going to be working on, the healthier their backlog is likely to be. Struggling product owners scramble to keep their teams busy sprint-to-sprint. Good product owners can see where their teams are going to be in several months. Great product owners see to the end of the game.

Teaching Product Owners How To Fish

Product owners are responsible for defining WHAT the Agile team needs to create. The team is responsible for deciding HOW to build WHAT the product owner needs.

I don’t think any Agilist would fundamentally disagree with that statement. Where there is inevitably a great deal of discussion and disagreement is describing the boundary between “WHAT” and “HOW.” Is it thin or thick? How much overlap is there? Does this depend on the nature of the work or is there a fixed standard? Does it have to be determined for every story? These are often not easy questions to answer.

While reading some neuroscience material yesterday regarding how our brains construct “concepts,” the topic lead into the notion of “goal-based concepts.” Since I’m not a neuroscientist but an Agilist looking for ways neuroscientific discoveries can be applied to the implementation of Agile principles and practices, the material had me thinking about how product owners might learn from the idea of “goal-based concepts.” How can I teach them about the “WHAT” such that they better understand the type and amount of detail the team needs in order to figure out the “HOW?”

I came up with a series of short dialogs:

Product Owner (to team): I need a fish.

Team: OK.

(Team goes off to work on “fish” and returns the next day with a catfish.)

PO: That’s not what I wanted! I need a fish!

(Team goes off to work on “fish” and returns the next day with a nurse shark.)

PO: That’s not what I wanted either!

What if the PO had been more clear about not just WHAT she wanted, but the goal for that WHAT. That is, a description of the problem that the WHAT was intended to solve.

PO: I’m opening a fish store. I need a fish.

(Team goes off to work on “fish for fish store” and returns the next day with a goldfish.)

PO: That’s good. But it’s not enough. I need more fish. Different kinds of fish.

(The team goes off to work on “variety of fish for fish store” and returns the next day with guppies, mollies, swordtails, and angelfish.)

PO: Cool!

Or version two:

PO: I’m opening a restaurant. I need a fish.

(Team goes off to work on “fish for restaurant” and returns the next day with Poached Salmon in Dill Sauce.)

PO: That’s good. But it’s not enough. I need more fish. Different kinds of fish.

(The team goes off to work on “variety of fish for restaurant” and returns the next day with Miso-Glazed Chilean Sea Bass, Mediterranean Stuffed Swordfish, and Pan Seared Lemon Tilapia.)

PO: Yum!

Hopefully, you can see that by providing a little of the “WHY” for the “WHAT” has helped the team do a better job of delivering WHAT the product owner wanted.

Of course, these are simplified examples. There are many additional details the product owner could have supplied that would have helped the team dial in on exactly WHAT she needed. In the first dialog, the team had to make guesses about what the product owner meant by the rather broad concept of “fish.” In the subsequent dialogs, the team at least had the benefit of the context that was of interest to the product owner. In these cases, the team had a better understanding of the goal the product owner had in mind.

In Agile-speak, this context or goal information would be provided in the “As a…” and “…so that…” part of the story. “As a restaurant owner I want fish so that patrons can enjoy a variety of menu options.”

The less clear the product owner is on these elements, the longer it’s going to take for the team to guess what she really wants.

Concave, Convex, and Nonlinear Fragility

Nassim Nicholas Taleb’s book, “Antifragile,” is a wealth of information. I’ve returned to it often since first reading it several years ago. My latest revisit has been to better understand his ideas about representing the nonlinear and asymmetric aspects of fragile/antifragile in terms of “concave” and “convex.” My first read of this left me a bit confused, but I got the gist of it and moved on. Taleb is a very smart guy so I need to understand this.

The first thing I needed to sort out on this revisit was Taleb’s use of language. The fragile/antifragile comparison is variously described in his book as:

  • Concave/Convex
  • Slumped solicitor/Humped solicitor
  • Curves inward/Curves outward
  • Frown/Smile
  • Negative convexity effects/Positive convexity effects
  • Pain more than gain/Gain more than pain
  • Doesn’t “like” volatility (presumable)/”Likes” volatility

Tracking his descriptions is made a little more challenging by reversals in reference when writing of both together (concave and convex then convex and concave) and mis-matches between the text and illustrations. For example:

Nonlinearity comes in two kinds: concave (curves inward), as in the case of the king and the stone, or its opposite, convex (curves outward). And of course, mixed, with concave and convex sections. (note the order: concave / convex) Figures 10 and 11 show the following simplifications of nonlinearity: the convex and the concave resemble a smile and a frown, respectively. (note the order: convex / concave)

Figure 10 shows:

So, “convex, curves outward” is illustrated as an upward curve and “concave, curves inward” is illustrated as a downward curve. Outward is upward and inward is downward. It reads like a yoga pose instruction or a play-by-play call for a game of a Twister.

After this presentation, Taleb simplifies the ideas:

I use the term “convexity effect” for both, in order to simplify the vocabulary, saying “positive convexity effects” and “negative convexity effects.”

This was helpful. The big gain is when Taleb gets to the math and graphs what he’s talking about. Maybe the presentation to this point is helpful to non-math thinkers, but for me it was more obfuscating than illuminating. My adaptation of the graphs presented by Taleb:

With this picture, it’s easier for me to understand the non-linear relationship between a variable’s volatility and fragility vs antifragility. The rest of the chapter is easier to understand with this picture of the relationships in mind.

Team Composition

When a potter begins to throw a pot, she picks up a lump of clay, shapes it into a rough sphere, and throws it onto the spinning potter’s wheel. It may land off-center, and she must carefully begin to shape it until, it is a smooth cylinder. Then she works the clay, stretching and compressing it as it turns. First it is a tower, then it is like a squat mushroom. Only after bringing it up and down several times does she slowly squeeze the revolving clay until its walls rise from the wheel. She cannot go on too long, for the clay will begin to “tire” and then sag. She gives it the form she imagines, then sets it aside. The next day, the clay will be leather hard, and she can turn it over to shape the foot. Some decoration may be scratched into the surface. Eventually, the bowl will be fired, and then the only options are the colors applied to it; its shape cannot be changed.

This is how we shape all the situations in our lives. We must give them rough shape and then throw them down into the center of our lives. We must stretch and compress, testing the nature of things. As we shape the situation, we must be aware of what form we want things to take. The closer something comes to completion, the harder and more definite it becomes. Our options become fewer, until the full impact of our creation is all that there is. Beauty or ugliness, utility or failure, comes from the process of shaping.Deng Ming-Dao, '365 Tao - Daily Meditations'

Building a high-performance team from scratch is just as difficult as turning a low-performing team into a high-performing team. However, there are very different reasons why each of these scenarios are difficult.

Like the potter beginning with a lump of clay, when forming a new team we must understand what we have to work with and have a clear idea of the outcomes we want. As we shape the team, we have to be mindful of how the individuals on the team are changing – or not – and whether those changes are moving toward the outcome. If not, we either need to change the desired outcome or alter the material we have to work with, that is, change out one or more people so that the shape of the team is better suited to reaching the desired outcome. It is also important to monitor the speed at which the team is formed or shaped. Too fast, and the team may not coalesce in a way that is healthy or productive. Too slow and they may not coalesce at all, they may “tire” of the slow pace and disengage.

With existing teams, we may have a limited range of options to change the roster. This is more like the an existing piece of pottery that has been fully set.

Estimating Effort – Adaptation

I’ve been running the informed intuition (or if you prefer, “disciplined intuition”)  approach to estimating effort for close to nine months now. For the most part, it has gone very well. The primary objective – inspire and support a conversation around the effort needed to complete a story – has most definitely been realized. Along the way the process has shifted to better support both the conversation and the team’s ability to internalize the process.

Originally, it was proposed that teams rate each of the effort characteristics on a sliding scale – 1 to 10 or 1 to 15, or whatever the team decided was most useful. Feedback from the teams lead to the discovery that it is easier to evaluate each effort characteristic using the modified Fibonacci scale rather than a sliding scale. This provides continuity across the method in that everything about a story’s effort value is considered using the same scale. It also reinforces the rationale behind the use of the Fibonacci scale and seems to facilitating the team’s ability to internalize the method. They are moving more quickly when deriving effort values.

A second adaptation is the use of several sets of characteristics, depending on the type of story, the predominant functional area represented by the team, and the nature of the work. For example, a story that involves the development of a computer board has a different set of criteria from stories that involve the creation of firmware for the board or the UI/UX features of the hardware product. The sets usually contain 3 or 4 common characteristics, such as “complexity” or “dependencies.” However, the hardware board may include something like “part sourcing” or “compliance testing.” This illustrates the importance of having the team deconstruct what “effort” means in the context of their world. When they determine the characteristics, the follow-on conversations about the effort are much more robust and meaningful.

In essence, this method is a reflection of the product owner’s responsibility for the “what” of the story and the team’s responsibility for figuring out the “how” of the story. “What I want,” says the product owner, “is an estimate of the effort involved to complete this story.” The teams effort criteria demonstrate to the product owner how they arrive at any particular value.

Intuition and Effort Estimates

In his book, “Blink,” Malcom Gladwell describes an interview between Gary Klein and a fire department commander. A lieutenant at the time, the firemen were attempting to put out a kitchen fire that didn’t “behave” like a kitchen fire should. The lieutenant ordered his men out of the house moments before the floor collapsed due to the fire being in the basement, not the kitchen. Klein later deconstructed the event with the commander and revealed a surprisingly rich set of experienced-based characteristics about that event the commander used to quickly evaluate the situation and respond. The lieutenant’s quick and well-calibrated-to-the-situation intuition undoubtedly saved them from serious injury or worse.

Intuition, however, is domain-specific. This same experienced-based intuition most probably wouldn’t have served the commander well if he suddenly found himself in a different situation – at the helm of a sailboat in rough water, for example, assuming the commander had never been on a sailboat before.

In the context of a software development environment, a highly experienced individual may have very good intuition on the amount of work needed to complete a specific piece of work assigned to them. But that intuition breaks down when the work effort necessarily includes several people or an entire team. So while intuition can serve a useful role in estimating work effort, that value is generally over-estimated, particularly when it needs to be a team estimate.

Consider work effort estimates when framed by Danial Kahneman’s work with System One and System Two thinking. System One is fast, based on experiences, and automatic. However, it isn’t very flexible and it’s difficult to train. This is the source of intuition. System Two, however, is analytical, methodical, intentional, deliberate, and slower. Also, it’s more trainable. It’s when the things that are trained in System Two sink into System One that new behaviors become automatic. With work effort estimates, we must first deliberately train our System Two using a method that is more deliberate about estimating before we can comfortably rely on our System One abilities.

Once calibrated, any number of changes could signal the need to re-calibrate by employing the deliberate process. Change the team composition and the team will need some measure of re-training of System One via System Two. Change a team’s project and the same re-training will need to occur.

The trained intuition approach to estimating effort develops what Kahneman called “disciplined intuition.” Begin with a deliberate, statistical approach to thinking about work effort. Establish a base rate using the value ranges for the effort characteristics. With experience, the team can begin to integrate their intuition later in the project process. If teams lead with their intuition (as is the case with planning poker and t-shirt sizes), they will filter for things that confirm their System One evaluation. With experience and a track record of success from training their intuition, teams can eventually lead with an intuitive approach. But it isn’t a very effective way to begin.

This method also leverages the work of Anders Ericsson and deliberate practice. The key here is the notion of increasing feedback into the process of estimating work effort. The deliberate action of working through a conversation that evaluates each of the work effort characteristics introduces more and better feedback loops that help the team evaluate the quality of their decision. Over time, they get better and better at correcting course and internalizing the lessons.

It’s like learning to drive a car. A new driver will leverage System Two heavily before they can comfortably rely on System One while driving. This is good enough for most driving situations. However, it wouldn’t be good enough if that same driver who is competent at driving in city traffic was suddenly placed on a NASCAR track in a powerful machine going 200 miles per hour.

A NASCAR track might be where we would go look for expert drivers but not where we would look for competent delivery truck drivers. For work estimates on software projects, we’re looking for a level of good enough that’s a reasonable match for the project work at hand. And we’re looking for better than untrained intuitive guesses.

We’re Good, Yes?


No, we’re not.

I’m adding this phrase to my list of markers that indicate things in a relationship are still not settled. It’s another form of the “seeking forgiveness instead of asking permission” bromide. A self-printed get-out-of-jail-free card. If not that, it’s a dodge to get out from under the burden of an uncomfortable situation at the expense of leaving things tangled and for the most part unresolved.

Here’s a typical scenario.

A product owner or executive faces a decision that affects the workload on a team. Rather than work with marketing, for example, to defer their request for new features to a future release or shift the delivery date to accommodate the request, the decision maker takes the easy path, agrees to the change without adjusting anything else in the system, and drops the extra work on the team.

To make matters worse, the team is informed by email. The team is understandably upset and more than a little confused about the immediate change in course. It’s left to the scrum master to make sense of the e-grenade and deal with the shrapnel. The expected back-channeling and grousing quickly attracts the attention of a wider audience and a full-on electrical storm ensues.

After way too many expensive people are involved and someone with some skill and authority gets control of the situation, work gets renegotiated, timelines are shifted, and work that could and should have been done by the original decision maker gets done by a cadre of ancillary and executive staff.

The original decision maker circles back around to the scrum master, apologies for the “misunderstanding,” and dashes off with a wave and a “We’re good, yes?”

In all likelihood, you’re not. In fact, the difficult conversation that needs to happen is just beginning. What lead up to this explosion? How could the decision maker handled the situation better? What do they need to succeed at navigating future occurrences like this with marketing? What’s different such that the team has confidence this won’t happen again? Does the decision maker understand the consequences to taking the easy way? The hits to time, money (in terms of salaries), and morale can be significant, particularly if  scenarios like this are a frequent occurrence.

Whether you find yourself about to utter this phrase or you’re on the receiving end, know that the work to resolve the issue and move forward has only just begun. Pick up the pieces, learn from the experience, and build something better.