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

Creativity Under Pressure

[In the fall of 2013, I completed a course on Coursera titled “Creativity, Innovation, and Change” presented by Drs. Jack V. Matson, Kathryn W. Jablokow, and Darrell Velegol at Pennsylvania State University. It was an excellent class. At the end, they invited the class (How many tens of thousands of us?) to submit short essays about our experience. The plan was to select the best of these essays and roll them into a free Kindle book. The following spring, they sent out this update:

We are sorry to inform you that we have decided not to proceed with the publication of a CIC eBook. The submissions were read and commented on by four reviewers.  The consensus was that the manuscripts for the most part would take efforts far beyond our capabilities and means to edit and upgrade to meet the standards for publishing.  We are very sorry that the plan did not work out.

What follows is slightly edited version of the essay I submitted for consideration.]

Creativity Under Pressure – When necessity drives innovation.

Background

When you hear someone speak of an individual they know as being creative, what images come to mind? Often, they spring from stereotypes and assumptions about such an individual being an artist of some sort. Someone unconstrained by time or attachment to career, family, or a mortgage. My personal favorite is the image of a haggard individual wearing a beret, a thin cigarette balanced on their lower lip, and busy being inspired by things us mortals cannot see. A foreign accent adds the final touch to firmly set the speaker’s creative individual in the “That’s not me.” category. Our preconceived notions and assumptions assure us we are not creative.

The truth is all of us are creative. The artist’s Muses are not the only source of inspiration. Chance can inspire creative ideas by the convergence of seemingly unrelated circumstances and events. An activity as passive as sleep can lead to creative ideas. Moving away from beauty toward the other end of the inspiration spectrum, the source may not necessarily be pleasant. Frustration and irritation may inspire us to find a creative solution as we spend an inordinate amount of time searching for a way to scratch a just-out-of-reach itch. Crisis, too, can be a source of inspiration, often of the very intense variety. Chance surrounds all of us. We all sleep. And alas, we are all subject to frustrating or crisis situations from time to time in our lives. We are immersed in opportunities for creative inspiration.

Perhaps the least obvious or explored opportunities for applying creativity and experimenting with innovative ideas happen when we are under pressure to perform. At first glance, the tendency is to think that such situations require extensive knowledge, abundant prior practice, and scenario rehearsals in order to navigate them successfully. It’s fair to say that the chances for successfully responding to a crisis situation are greatly enhanced by deep knowledge and experience related to the situation.

The Apollo 13 mission to the Moon is a familiar example of crisis driven creativity by a team of experts. Survival of the astronauts following the explosion of an oxygen canister depended on NASA engineers finding a way to literally fit a square object into a round hole. The toxic build-up of CO2 could only be prevented by finding a way to fit a cube shaped CO2 filter into a cylinder shaped socket using nothing but the materials the astronauts had with them. Of course we know from history the team of engineers succeeded in this exercise of creative improvisation.

Individual experts have also succeeded in devising creative solutions in crisis situations, and in doing so introduced critical changes in protocols and procedures that have saved lives. For example, smokejumber Wagner Dodge’s actions in the Mann Gulch forest fire on August 5, 1949, introduced the practice of setting escape fires as a way to protect firefighters caught in “blow-ups.”

What I’ve always found interesting about these and similar examples is that, although the creative and innovative solutions were found while “on the job” and using established expertise, the solutions were counter to what the individuals and teams were expected to do. The NASA engineers were paid to design and build an extremely high tech solution for sending three men to the moon and bringing them safely back to Earth. Their job descriptions likely didn’t call for the ability to “build a fully functional CO2 scrubber from a pile of junk.” Wagner Dodge was expected put out fires, not start them.

The Course

What else is important in preparing us to respond creatively in high pressure situations? It’s a question that’s dogged me for years. The “Creativity, Innovation, and Change” (CIC) course offered by Pennsylvania State University and taught by Professors Jack Matson, Kathryn Jablokow, and Darrell Velegol offered an opportunity to explore this question.

The first insight from the course was the importance of the “adjacent possible” to creative and innovative problem solving, even in crisis situations. The phrase was originally suggested by the theoretical biologist Stuart Kauffman to describe evolutionary complexity. The idea is that innovative or creative ideas occur incrementally. While they may appear as substantial leaps forward, they are in fact derived from a collection of adjacent ideas that coalesced to make a single idea possible. As an individual explores deeper and farther into an idea space, they extend the boundaries around which adjacent ideas collect, increasing the potential for new idea combinations. In other words, increasing the likelihood of creative or innovative ideas.

In the case of Apollo 13, the deep experience and knowledge of the engineers allowed them to consider a wide spectrum of possibilities for combining an extremely limited number of objects in a way that could remove CO2 from a spacecraft. In the case of Wagner Dodge, his extensive experience with fighting forest fires allowed him to spontaneously combine a variety of “adjacent possibilities” in a way that lead to the idea of lighting an escape fire.

That’s the theory, anyway. There’s a difference, though, between theory and practice. Albert Einstein explains, “In theory they are the same. In practice, they are not.” The CIC course offered an abundance of techniques and methods that facilitated the transfer of learning and strengthened the connection between theory and practice. In particular, there were two important reframes that opened the door to deliberately improving how I approach creativity and innovation in stressful situations:
“Successful” failures are those that are strategic. That is, not random guesses about what will work, but deliberate experiments designed to succeed. Yet if they fail, the design of the experiments also reveal weaknesses that are preventing the eventual success. Unconsciously, I had already become reasonably good a doing this. But there was significant room for improvement. Using many of the methods and techniques offered during the CIC course, I deliberately unpacked my unconscious competence in this area, consciously explored how I could practice becoming even more competent with this skill, and am now exploring ways to integrate the new capabilities back into unconscious competence.

“Failure” is a necessary, even desired process for finding success. This ran counter to my get-it-right perfectionist approach to success. Likely the result of having to work in too many crisis situations where failure was not an option, it was nonetheless a poor strategy for finding success in day-to-day business. In concert with point number one, these failures should be strategic.
Each of these insights are encapsulated in the “Intelligent Fast Failure” (IFF) principle presented in the CIC course and further described in Prof. Matson’s book, “Innovate or Die!”:

The “Intelligent” part refers to gaining as much knowledge as possible from each failure. The “Fast” part means speeding up the trials to quickly map the unknown thereby minimizing frustration and resources spent.

The “fast” part also increases the pool of “adjacent possibilities” and raises the potential for successful innovations to emerge from the process.

The Test

Has all this experimentation and thought practice made a difference in my ability to respond more creatively in stressful situations? A full-on test in crisis mode hasn’t happened as yet. And frankly, I’d count my self fortunate if I never had to face such a test again. But there are indications the changes are having a positive effect.

These days, work typically offers the most abundant opportunities for stressful situations. Most recently, I was tasked with coordinating a significant change in how an organization went about the process of completing projects. The prevailing process had deep roots in the company’s culture and was incapable of scaling to meet growth goals for the organization. With so much personal investment into the old way of doing things, implementing a more agile and scalable process was going to require as much mediation and negotiation as it was process definition and skill development.

Using the techniques and methods that support the IFF principle, I have been successfully implementing a wide range of new ideas and process improvements into the organization in a way that makes them appear less as a threat and more as a value to each of the stakeholders.


Photo by Ameen Fahmy on Unsplash

Accidental Social Capital and Status

 

I was made aware recently that I have accidentally acquired some interesting social status: I’m not on Facebook. Apparently, it isn’t just that I’m not on Facebook, its that I’ve never had a Facebook account. I’ve also never had accounts with:

  •  MySpace
  • Twitter
  • Instagram
  • TikTok
  • Pinterest
  • Snapchat
  • Reddit
  • Parler
  • The list goes on and on.

I am fairly active on LinkedIn and for a brief time had a Gab account after it first launched. The latter looked like another cesspool in the making so I deleted the account and moved on.

Acquiring this status wasn’t entirely accidental, even if it wasn’t by design. It was clear early on that the only way to win the race to the bottom of the social-on-line game was to not play at all. I’d seen this movie before. I had some experience with this environment in the pre-world-wide-web days of USENET newsgroups so it was pretty easy to see where this was heading. Thought I’d seen some epic flame wars on USENET but USENET newsgroups are to 21st century social media as camp fires are to nuclear explosions, as head colds are to social diseases.

I’m not so naive to think just because I don’t participate in the vast majority of social media that others haven’t contributed data about me without my knowledge or consent nor that I’m immune to the effects of social media. It’s that nuclear explosion thing. I can’t help but be aware of the blast and getting caught in the blast zone, even being targeted for the epicenter are known risks. While zillions of people are blithely working to feed The Beast’s insatiable need for data in exchange for nano hits of dopamine, my efforts are focused on how to avoid the growing tar pit that oozes from The Beast. I study how others have inadvertently been lured into the hot mess and, even more valuable, those few who have successfully wrestled themselves free.

Neither do I think social media is devoid of value or purpose. This is where LinkedIn (so far) seems to rise above the base rabble. There is a modicum of professionalism and elevated expectation of how one behaves on LinkedIn. (Although, I see signs of this eroding at an accelerated pace.)

As I see it, there is no way I can reliably cash in on this newly acquired social capital and status. It’s value is dubious. A small-talk starter at parties. A novelty. A non-thing that’s interesting like not having purple hair, tattoos, and a pierced face is interesting. To really leverage it, I’d have to jump into the social media quagmire, thereby emptying the account or, more likely, go into serious debt. In the end, carefully curated piles of garbage are still garbage.

So there it sits. A helluva thing, maybe valuable only as a note on my headstone.

Here rests Gregory Engel.
@nothing, @nowhere
He lived in the real world.

The Practice of Sizing Spikes with Story Points

Every once and a while it’s good to take a tool out of it’s box and find out if it’s still fit for purpose. Maybe even find if it can be used in a new way. I recently did this with the practice of sizing spikes with story points. I’ve experienced a lot of different projects since last revisiting my thinking on this topic. So after doing a little research on current thinking, I updated an old set of slides and presented my position to a group of scrum masters to set the stage for a conversation. My position: Estimating spikes with story points is a vanity metric and teams are better served with spikes that are time-boxed but unsized.

While several colleagues came with an abundance of material to support their particular position, no one addressed the points I raised. So it was a wash. My position hasn’t changed appreciably. But I did gain from hearing several arguments for how spikes could be used more effectively if they were to be sized with story points. And perhaps the feedback from this article will further evolve my thinking on the subject.

To begin, I’ll answer the question of “What is a spike?” by accepting the definition from agiledictionary.com:

Spike

A task aimed at answering a question or gathering information, rather than at producing shippable product. Sometimes a user story is generated that cannot be well estimated until the development team does some actual work to resolve a technical question or a design problem. The solution is to create a “spike,” which is some work whose purpose is to provide the answer or solution.

The phrase “cannot be well estimated” is suggestive. If the work cannot be well estimated than what is the value of estimating it in the first place? Any number placed on the spike is likely to be for the most part arbitrary. Any number greater than zero will therefore arbitrarily inflate the sprint velocity and make it less representative of the business value being delivered. It may make the team feel better about their performance, but it tells the stakeholders less about the work remaining. No where can I find a stated purpose of Agile or scrum to be making the team “feel better.” In practice, by masking the amount of business value being delivered, the opposite is probably true. The scrum framework ruthlessly exposes all the unhelpful and counterproductive practices and behaviors an unproductive team may be unconsciously perpetuating.

Forty points of genuine business value delivered at the end of a sprint is 100% of rubber on the road. Forty points delivered of which 10 are points assigned to one or more spikes is 75% of rubber on the road. The spike points are slippage. If they are left unpointed then it is clear what is happening. A spike here and there isn’t likely to have a significant impact on the velocity trend over 8 or 10 sprints, for example. One or more spikes per sprint is another matter. In this case, numerous spikes in successive sprints will likely cause the velocity to sink. If this happens, a number of corrective actions can be taken – actions that may be missed if the velocity is falsely kept at a certain desired or expected value. In other words, pointing spikes hides important information that could very well impact the success of the project. Bad news can inspire better decisions and corrective action. Falsely positive news most often leads to failures of the epic variety.

Consider the following two scenarios.

Team A has decided to add story points to their spikes. Immediately they run into several significant challenges related to the design and the technology choices made. So they create a number of spikes to find the answers and make some informed decision. The design and technology struggles continue for the next 10 sprints. Even with the challenges they faced, the team appears to have quickly established a stable velocity.

The burndown, however, looks like this:

If the scrum master were to use just the velocity numbers it would appear Team A is going to finish their work in about 14 sprints. This might be true if Team A were to have no more spikes in the remaining sprints. The trend, however, strongly suggests that’s not likely to happen. If a team has been struggling with design and technical issues for 10 sprints, it is unlikely those struggles will suddenly stop at sprint 11 or beyond unless there have been deliberate efforts to mitigate that potential. By pointing spikes and generating a nice-looking velocity chart it is more probable that Team A is unaware of the extent to which they may be underestimating the amount of time to complete items in the backlog.

 

 

Team B finds themselves in exactly the same situation as Team A. They immediately run into several significant challenges related to the design and the technology choices made and create a number of spikes to find the answers and make some informed decision. However, they decided not to add story points to their spikes. The design and technology struggles continue for the next 10 sprints. The data show that Team B is clearly struggling to establish a stable velocity.

 

And the burndown looks like this, same as Team A after 10 sprints:

However, it looks like it’s going to take Team B 21 more sprints to complete the work. That they’re struggling isn’t good. That it’s clear they struggling is very good. This isn’t apparent with Team A’s velocity chart. Since it’s clear they are struggling it is much easier to start asking questions, find the source of the agony, and make changes that will have a positive impact. It is also much more probably that the changes will be effective because they will have been based on solid information as to what the issues are. Less guess work involved with Team B than with Team A.

However, any scrum master worth their salt is going to notice that the product backlog burndown doesn’t align with the velocity chart. It isn’t burning down as fast as the velocity chart suggests it should be. So the savvy Team A scrum master starts tracking the burndown of value-add points vs spike points. Doing so might look like the following burndown:

Using the average from the parsed burndown, it is much more likely that Team A will need 21 additional sprints to complete the work. And for Team B?

The picture of the future based on the backlog burndown is a close match to the picture from the velocity data, about 22 sprints to complete the work.

If you were a product owner, responsible for keeping the customer informed of progress, which set of numbers would you want to base your report on? Would you rather surprise the customer with a “sudden” and extended delay or would you rather communicate openly and accurately?

Summary

Leaving spikes unpointed…

  • Increases the probability that performance metrics will reveal problems sooner and thus allow for corrective actions to be taken earlier in a project.
  • The team’s velocity and backlog burndown is a more accurate reflection of value actually being created for the customer and therefore allows for greater confidence of any predictions based on the metrics.

I’m interested in hearing your position on whether or not spikes should be estimated with story points (or some other measure.) I’m particularly interested in hearing where my thinking described in this article is in need of updating.

[An earlier version of this article originally appeared on the Agile Alliance blog.]

The World Needs More Booths

Remember face-to-face conversation? You know, sharing thoughts, talking through concerns, sketching out ideas, and having intelligent discussions without the overblown internet persona outrage? You have instant feedback through facial expressions, tone of voice, and spoken word. You have instant ability to clarify a particular point, on the spot. You get a better “read” of where the other person is coming from. And, you get better engagement in the conversation. – Rick Knowles

Conference rooms, court rooms, hospital rooms, elevators – these are some examples where the space presupposes a particular way of behaving and communicating (or, in the case of elevators, not communicating.) The informal setting of a booth, however, allows for a comfortable space to let some of the usual barriers to conversation fall away.

 

Many of the most memorable conversations and exchanges of ideas in my life happened in restaurant booths. They weren’t all good, but most of them were and all of them were important. Add in a good cup of coffee and they can be incredibly creative spaces. Perhaps it’s just a lucky spacial anchor thing. However it happened, the result is that booths, particularly coffee shop booths, are my go-to spaces for near-instant solace and creativity. So much so that when we kicked off a major home renovation some years ago it included, among many other things, a breakfast booth off the kitchen. The design of the booth was completed by the same designer/builder of the booths at Racine’s Restaurant – perhaps my second all-time favorite Third Place behind The Market. (Sadly, neither Racine’s or The Market survived the government lockdowns of 2020.)


(Image credit: johnny_automatic)

When Collaboration Becomes Clobber-ation

I was new on site and agreed to co-create a working session with the company Agile coach for developing the skills needed to split large stories into smaller stories. The plan was to develop the skills of the company’s scrum master pool so that they could then deliver this presentation to their teams. Given the diversity of the team projects involved, I proposed that it might be helpful to open the session with a short segment on how to size stories, just to be sure everyone had a baseline understanding. To this end and in the interests of time I offered to leverage a 10 minute presentation that I’d used successfully for several years.

“Great,” she said. “Let’s see it.”

Thirty minutes and an uncounted number of interruptions later to interject what I should do different here and where I was wrong there, I stopped trying to get through my short deck of slides. The interaction had all the feel of turf posturing and a clear need for the company coach to be the sage in the mix. I don’t mind getting thrashed by sharp or well placed feedback from a curious novice or a proven master. These insights are often the most valuable and important to learning and growth as an Agile coach. But if anyone deploys a tear-you-down-to-build-me-up strategy in the name of collaboration I’ve learned it’s best to cut my losses and walk away.

And that’s what happened here. The co-creation dissolved and the working session never occurred. Weeks later, the company coach emailed the approved deck of slides to the scrum masters with instructions to present the deck to their teams. How to do that was “in the notes.”

There were a lot of things wrong with this interaction and, indeed, with the company’s Agile implementation. But the lack of co-creation and collaboration was a core issue. Healthy and productive collaboration includes all of the following:

  • Asking many questions
  • Careful attention and listening to answers
  • Making few statements
  • Setting aside the limitations of “or” and embracing the power of “and”
  • Understanding the goals of the collaboration
  • Understanding the purpose of the collaboration
  • Respect for everyone as professionals
  • Communication that is open and uncontaminated by back channeling and triangulation
  • Patience

Photo by Ashley Jurius on Unsplash

Teams, Tribes, and Community – 0.1.0

Several months ago, I made bold decision: Take command of the helm for a brilliant tribe of diverse creative thinkers dedicated to helping each other succeed. This is the first of an on-going series of posts – maybe once or twice a month – describing this evolving effort.

For an extrovert, this might not have been a bold decision. But in my case, you should know I designed the card that card-carrying introverts carry. So this decision involved a more thorough application of my already robust decision-making process. On a professional level, this may be the most significant challenge I’ve taken on to date. Will my years of experience with forming and guiding teams help this tribe further their success? Will I be able to find the gravitational force that holds us together and the spark that keeps us inspired? These are open questions. They are also questions that occupy much of my thinking.

We are not dedicated to achieving a single goal or moving in a unified direction. We each have our areas of expertise and independent business goals. We are much more a tribe than a team. As such, I believe we will be guided more by tribal dynamics and models than team rules and policies. The path is not clear, but this much I know…

  • There is no leader of this tribe. Not in the sense of a single person who’s responsible for setting the direction and making all the decisions that impact the organization. There is no “Chief” or “Czar” of anything. I’ll fill the role of Launch Commander and Flight Commander in order to get us organized and moving forward. However, I have been clear from the start about my intention to structure our tribe on principles of self-organization.
  • The emphasis is on simple and accessible technology and easy ways to organize meetings based on Agile principles and practices – lean coffee, for example, has served us well for our initial meetings. What has emerged since then are more involved and interactive meeting formats, such as client role-plays and accountability exercises. Keeping things simple and remaining mindful of barriers to participation is vital. Too many tools with too many logins risks the creation of a Tower of Babel. For now, the weekly video call is the center-point around which we all meet. This in itself is enough of a challenge given the global participation. Other than this, email is the acknowledged primary channel for asynchronous communication.
  • We are not accepting new members. Whether or for how long this remains the case is undecided. We have discussed various ways of introducing new members, but have decided to decide on this issue later. The circumstances that brought each of us together created a unique bond of trust and familiarity with each other’s business interests that makes the introduction of new members a risk to maintaining these relationships. At the moment, we are tipped slightly toward being on the large size and everyone acknowledges if we grow much bigger the meetings may become unmanageable and the interactions less valuable. Since trust is foundational, none of the details related to who we are and what we discuss will be revealed in this space. My writing will be limited to the general case of what I discover from having participated in and helped guide our tribe. It is my hope this may help others with forming and guiding their own teams and tribes.

Whatever the outcome, it’s been more fun thus far than I’ve had in a loooooong time.


Image by Youssef Jheir from Pixabay

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