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.

Here is a representation of these phases on a hypothetical project timeline:See also:


Photo by Linus Nylund on Unsplash

Agile and Changing Requirements or Design

I hear this (or some version) more frequently in recent years than in past:

Agile is all about changing requirements at anytime during a project, even at the very end.

I attribute the increased frequency to the increased popularity of Agile methods and practices.

That the “Responding to change over following a plan” Agile Manifesto value is cherry picked so frequently is probably due to a couple of factors:

  • It’s human nature for a person to resist being cornered into doing something they don’t want to do. So this value gets them out of performing a task.
  • The person doesn’t understand the problem or doesn’t have a solution. So this value buys them time to figure out how to solve the problem. Once they do have a solution, well, it’s time to change the design or the requirements to fit the solution. This reason isn’t necessary bad unless it’s the de facto solution strategy.

The intent behind the “Responding to change” value, and the way successful Agile is practiced, does not allow for constant and unending change. If this were otherwise nothing would ever be completed and certainly nothing would ever be released to the market.

I’m not going to rehash the importance of the preposition in the value statement. Any need to explain the relativity implied by it’s use has become a useful signal for me to spend my energies elsewhere. But for those who are not challenged by the grammar, I’d like to say a few thing about how to know when change is appropriate and when it’s important to follow a plan.

The key is recognizing and tracking decision points. With traditional project management, decisions are built-in to the project plan. Every possible bit of work is defined and laid out on a Gantt chart, like the steel rails of a train track. Deviation from this path would be actively discouraged, if it were considered at all.

Using an Agile process, decision points that consider possible changes in direction are built into the process – daily scrums, sprint planning, backlog refinement, reviews and demonstrations at the end of sprints and releases, retrospectives, acceptance criteria, definitions of done, continuous integration – these all reflect deliberate opportunities in the process to evaluate progress and determine whether any changes need to be made. These are all activities that represent decisions or agreements to lock in work definitions for short periods of time.

For example, at sprint planning, a decision is made to complete a block of work in a specified period of time – often two weeks. After that, the work is reviewed and decisions are made as to whether or not that work satisfies the sprint goal and, by extension, the product vision. At this point, the product definition is specifically opened up for feedback from the stakeholders and any proposed changes are discussed. Except under unique circumstances, changes are not introduced mid-sprint and the teams stick to the plan.

Undoing decisions or agreements only happens if there is supporting information, such as technical infeasibility or a significant market shift. Undoing decisions and agreements doesn’t happen just because “Agile is all about changing requirements.” Agile supports changing requirements when there is good reason to do so, irrespective of the original plan. With traditional project management, it’s all about following the plan and change at any point is resisted.

This is the difference. With traditional project management, decisions are built-in to the project plan. With Agile they are adapted in.


Photo by Chris Lawton on Unsplash

Fall Reflections – 2021

Over four years ago, I was in a position to retire early. After some thought, the idea didn’t suit me. I was, in the arc of my life, in an entirely novel position. I could be much more selective about where I chose to exchange my time for money. With nothing to lose and a lot to gain, I sought work with a company that would put Agile principles and my coaching skills to a rigorous test. Did I have what it takes to guide a global legacy corporation into an Agile learning organization? I ran this experiment within the software divisions of two different medical device manufacturers. The first was a 6 month engagement that ended when a better option opened up at a much larger manufacturer with more pay and less commute. I was there for three years until a layoff in the spring.

So it is I’ve come to wrapping up an extremely active spring and summer after having tripped a wire that launched me into a career shift about six months earlier than planned – a span of time I’m affectionately calling an unplanned sabbatical. I’m still not ready to retire, but I’m in an even stronger position then I was four years ago – the silent advantage of a Stoic minimalist lifestyle. Shedding the corporate baggage has opened up a universe of space and time for unfettered thought and exploration. Sabbaticals should be integrated into the work lives of every employee who demonstrates integrity and a strong work ethic.

In the coming months, I’ll be writing more about what this new direction involves. A change in direction doesn’t begin to capture the shift. There’s a multi-leveling up in play, too. This fall and winter – seasons ideally suited for deep reflection and planning – will see a continued pace of activity and preparation. Belying the quite stillness of winter, I will be extremely busy moving fieldstones into position and crafting a renewed foundation for success.

The purpose and mission I declared at the very beginning of 2020 is still in place. When I crafted that mission I was at the very beginning of a grand experiment, full of optimism and yet fully aware of the daunting task ahead. The company I was working for presented me with choice: I could accept a new management role or pursue a stated goal of mine to create an official Agile Coach position within the software group. The organization had just created an official scrum master role in the org chart, but the PMO was strongly resisting the idea of an official product owner role. I was an epic turf battle.

The management path offered greater security but had significant downsides. Not only would I have the decidedly unpleasant task of managing people in a highly regulated and bureaucratic organization, I would also be expected to fill in the scrum master gaps on various teams. This sounded like a good way to end my career as an Agile Coach.

The coach path offered the highly appealing challenge of implementing Agile and SAFe in a 60 year old medical device manufacturer. The known risks included a certain tsunami of resistance. I’d be out on a limb, working to navigate in uncharted and dangerous waters. But I had excellent support. The arrival of a new CEO broke up many of the old ways of organizing software development and opened a window of opportunity. After a rigorous decision process, I chose the Agile Coach path. My 2020 mission reflects the enthusiasm I had for having made this choice.

Then things went sideways. The new CEO brought a much bigger broom than anyone imagined and my key executive support left the organization. Two new senior execs were hired that had a rather stunted understanding of Agile, SAFe, and working with software professionals. Progress stalled as head nods and “Yeah, we’ll get to that.” can-kicking substituted for action. A lot of really good people started to leave the organization, including what was left of my support and allies. A deeply disturbing experience while serving as the Unofficial Official Agile Coach and the effects of the pandemic lock-down sunk the Agile Coach boat. The bubble I placed myself on became more so. I’m surprised I wasn’t laid-off sooner.

The period since separating from my previous employer in early 2021 has been a period of immensely positive growth. The gain in perspective on the prior three years has enlightened me to just how toxic the work environment was. Taking that job was an experiment and in the end the primary failure was not discovering sooner that the experiment was destine to fail. My optimism was misplaced. I trusted untrustworthy people. The greater sadness is that the organization has a wonderful mission and excellent products, each held back from what they could be by a select few and their caustic alliances within the organization. My health and well-being are much the better for having left on their dime.

 I finished my 2020 declaration with “Here’s to moving into 2020 with mind and eyes wide open.” And so I did. Where to next will be on my terms. Free from people who talk inclusion but practice exclusion, talk diversity but practice conformity, talk about change but fight for stagnation, and talk about collaboration while protecting their tiny fiefdoms with vindictive ruthlessness. My tuned purpose and mission for 2022 will reflect this. And a good start will be to conduct business operations in ways that are aligned with the Mission Protocol.


Photo Credit: Original, Copyright © 2021, Gregory Paul Engel

Improving The Odds of Success For Any Goal With A Definition of Done

In 1626 the King of Sweden, Gustavus Adolphus, began work on what he envisioned would be the most powerful battleship ever to set sail – the Vasa. By all accounts, Gustavus was a brilliant military commander. Over the next two years the King repeatedly alter specifications such that massive amounts of rework were required. The mid-project inclusion of non-essential work – such as adding close to 500 elaborately decorated sculptures – added to the delay. The array of canon on the ship grew both in size and number. The result was an untested design that proved unstable when the ship was launched with great fanfare from the shipyard in Stockholm. Before King and country, the Vasa hadn’t made it out of the harbor before a strong breeze tipped the ship so far that water began entering the canon portals and sank the ship.

The lessons from this historical event about meddling managers embedded in a hierarchical system of status and nobility are obvious. This practice is still very much endemic in legacy corporations and MBA programs continue to crank out a plethora of future executives equipped to carry on the tradition. Thousands of executive and Agile coaches make a well deserved living working to remediate the problem.

A lesser but more actionable lesson has to do with Gustavus’ approach to project management. As brilliant as he was on the battlefield, this skill did not translate to the material production field where events move toward completion over months and years rather than hours and days.

There is a reason Agile project management leverages frameworks rather than highly structured protocols for getting work done. It recognizes that the world can be a messy place. Particularly when it requires human beings to complete work. With so many variables in play – emotions, physical health, competing priorities around family, pandemics, etc. – it’s amazing we get as much done as we do. Frameworks give us the flexibility to adjust and adapt to the situation.

There is a paradox embedded within Agile frameworks. Flexibility and adaptability are important, but there are also elements of the frameworks that are important to get right. The most important is to have a healthy product backlog that is vigorously maintained and defended by the product owner. If this isn’t in place, everything else become a major battle to implement. Stories bounce across multiple sprints, errors and rework grow exponentially and stakeholders readily jump to uncomfortable conclusions about progress.

Another important element is what’s typically called the “definition of done.” If the product owner or Agile team member can’t clearly and concisely describe what “done” looks like, you end up with some version of this conversation.

Product Owner: “What do you mean you’re still working on that story. I closed it last sprint because you said it was ‘done!'”

Agile Team Member: “Well, uh, yeah. It was done. But it wasn’t done done. There were still a couple of things I wanted to finish.”

If your definition of done is some version of “I’ll know it when I see it,” there is a good chance you’re about to attempt the launch your very own Vasa.

If you’d rather not do that, here are a few things to do instead:

  • If you are involved during the design phase of the project, repeatedly run a thought experiment where you begin with the end in mind. It’s that vision statement thingy.
  • Work to establish a clear understanding of what “good enough for now” means. And when you’ve done that, keep checking in with your team to evaluate if anything has changed to cloud that understanding.
  • Use minimum viable product definitions. Add to this the idea of minimum viable actions. As important as it is to know, as best you can, what done looks like, you need a sequence of actions that will get you there. What are those? In what order can they most effectively be sequenced? How jis what you’re learning along the way changing the path to “done?”
  • Finally, keep your product backlog healthy and strong. Without exception, continuously refine the backlog with stakeholders and the development team so that it is an accurate reflection of progress and future work.

Photo by Jamie Morrison on Unsplash

Responding to change over following a plan

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Agile Manifesto Principle #2

Following from the Agile Manifesto value that is the title of this post, Principle #2 may be the most mis-interpreted and misunderstood principle among the set of twelve. Teams frequently behave as if this principle was prefaced with the word “always.”

Constantly shifting requirements leads to a frustrating and unsatisfying environment in which to work. It feeds burn-out and erodes morale. The satisfaction of a job well done depends on the opportunity to actually finish the job, no matter how small. Consider the effects on a finish carpenter who has just spent several days installing and trimming a full set of kitchen cabinets when the homeowner declares they want to change the kitchen design such that all those new cabinets will need to be ripped out and work begun on a new design. Or a film editor who has just worked 21 days straight to pare down an hour’s worth of video to fit into 7 minutes only to learn the scene has to be re-shot from scratch in order to match a change in the story line.

Of course, the second principle does not state we should “always welcome changing requirements.” Nor does anyone I know claim that it does. But that doesn’t stop people from behaving as if it did. The rationale offered for agreeing to change requests from the stakeholders may be “We’re an agile shop and agile welcomes changing requirements” when, in fact, the change was agreed to because the product owner didn’t challenge the value of the change or make clear the consequences to the stakeholders. Or the original design was, and remains, needlessly ambiguous. Or the stakeholders have changed without renegotiating the contract or working agreements. Or any number of reasons that are conveniently masked with “welcoming changing requirements.” At some point, welcoming changing requirements is about as attractive as welcoming a rabid dog into the house. This won’t end well.

So, what kind of change is the Agile Manifesto referring to? There are several key scenarios that embody the need for flexibility around requirements.

  • The change that results from periods of deliberate design, such as during design sprints.
  • The change that is driven by the lessons learned from exploration and prototyping. If it is understood that the work being “completed” is for the purposes of testing a hypothesis and the expectation is that the work will most likely be thrown away, there can still be a great deal of satisfaction derived from the effort as the actual deliverable wasn’t working software, but the lessons from the experiment (usually in the form of a wireframe or prototype.)

So what is it that locks out the option for additional change? It’s a simple event, really. A decision is made.

Each of these scenarios where adapting to lessons and discovery is essential nonetheless end in a decision, a leverage point from which progress can be made toward a final deliverable. Each of these decisions can themselves form the basis of a series of experiments which, depending on the eventual outcome, may change.  Often, a single decision point may look good but when several decisions are evaluated together they may suggest a new direction and therefore impact the requirements. If the cumulative insight from a series of decisions results in the need to change direction, that shift is usually more substantial and on the scale of a project plan pivot rather than a simple response to a single change in a single requirement. The need to pivot cannot reliably be revealed if the underlying decisions do not coalesce into some sort of stable understanding of the emerging design.

Changing requirements cannot go on indefinitely or a final product will never be delivered. Accepting change for the sake of change is what gets teams into trouble.

Much like the forces on evolution, there will always be some external force that seeks to change the project requirements so that the delivered product can be stronger, faster, better, taller, smarter, etc.  This must be countered by clear definitions of “minimum viable” and “good enough for now” relative to what the customer is expecting.

In addition, product owners would serve their teams well by vigorously challenging any proposed changes to the requirements.

  • What is the source of the change?
  • Is it random change or triggered by some agent that does not announce its arrival ahead of time?
  • Was the change in requirements a surprise? If so, why was it a surprise?
  • Will this (or something like it) happen again? With what frequency? At what probability?

Photo by juan pablo rodriguez on Unsplash

The Novice and the Master

When coaching people in a new skill, there are several things I watch for in their development from novice to master. Insuring they have the requisite foundational knowledge can be considered a given. Tightly coupled with this is a demonstration of working from first principles. If neither of these are in place than it can be said the learner has yet to begin their journey toward mastery.

Beyond the basics, I look for signs of what’s happening behind the curtain. I watch for how they respond to challenges and conflict. And how they work through difficult decisions.

How a difficult decision is handled is an important indicator for whether an individual is a novice, a master, or somewhere in between. Where novices struggle trying to figure out what to do, masters resolve quickly. Certainly a common issue in play would be doubts about the outcome of any particular action and the probability of recovering from any associated consequences. It is also possible that the issue – either instead of or in addition to – is that the novice has become stuck at a decision node that has an uncomfortable degree of uncertainty associated with it on the front end and they are unskilled at thinking through the “disjunction,” as Eldar Shafir1 calls situations like this.

With the former issue, the tack taken by the novice is to plan out as many details as possible so as to account for every contingency and squeeze out as much doubt as possible regarding the outcome. In the later, the novice simply doesn’t have the information needed to make the decision and lacks the skill to play out n number of scenarios leading up to the decision node such that they can then evaluate subsequent paths.

An example given by Shafir has to do with a student that has just taken a rather important exam (say, for graduate school) but doesn’t yet know the results. If they’ve passed, they move forward. If they’ve failed, they have to retake the exam in a couple of months after the end-of-year holidays. On the same day, they are presented with a incredibly sweet deal for a 5-day Hawaiian vacation over the end-of-year holidays. The vacation deal is good for today and grades won’t be released until tomorrow. What does the student do?

Notice that the outcome of the exam will be known long before the vacation begins. Thus, the uncertainty characterizes the present, disjunctive situation, not the eventual vacation. Additional, related versions were presented in which subjects were to assume that they had passed the exam, or that they had failed, before they had to decide about the vacation. We discovered that many subjects who would have bought the vacation to Hawaii if they were to pass the exam and if they were to fail, chose not to buy the vacation when the exam’s outcome was not known. The data show that more than half of the students chose the vacation package when they knew that they passed the exam and an even larger percentage chose the vacation when they knew they they failed. However, when they did not know whether they had passed or failed, less than one-third of the students chose the vacation and the majority (61%) were willing to pay $5 to postpone the decision until the following day, when the results of the exam would be known.

A solution to this simple example of disjunction (Shafir provides many other examples) is for the student to ask themselves two questions:

  1. “Would I take this vacation deal if I passed?”
  2. “Would I take this vacation deal if I failed?”

If the answer is “Yes” to both or “No” to both, then the decision about the vacation deal is easy. If the answer is still mixed, then I suppose the student will have to dig a bit deeper to get at a level of leading criteria that will shake out the decision. (When I was a student, I would have had to consult my financial adviser – a.k.a. my wallet – first. The answer to everything beyond beer was “NO!”) In the experiment described above where students remained uninformed as to the outcome of the exam, they didn’t have a skill or strategy for resolving the uncertainty and were even willing to pay to make it go away!

Shafir’s work was instrumental in helping me tap into new skills for developing mastery in several areas of interest (specifically, martial arts and woodworking). Disjunction has a distinct visceral sensation for me. It gives me pause to ask questions not about potential future events, but about past events leading up to the present. I find I’m usually missing something about the history of events that either help sort out the indecision once known or cause me to think through better scenarios on emerging events that will influence the decision I’m trying to make.

References

1 Eldar Shafir’s chapter in “Cognition on Cognition” titled “Uncertainty and the difficulty of thinking through disjunctions”

Photo by Motoki Tonn on Unsplash