Drive for Teams

I recently re-read Daniel Pink’s book, “Drive: The Surprising Truth About What Motivates Us.” I read it when it was first published and I was still managing technical teams. Super brief summary: The central idea of the book is that people are mostly driven by intrinsic motivation based on three aspects:

  • Autonomy — The desire to be self directed.
  • Mastery — The urge to improve skills.
  • Purpose — The desire to engage with work that has meaning and purpose.

I find this holds true for individuals. However, when applied to teams optimizing for these three aspects can be problematic. If an individual on a team seeks to maximize autonomy, they are likely to come into conflict with the objectives of the team. For example, a software team that is tasked with developing a component that is expected to interact with several other components developed by other teams. If a single developer, in the interests of maximizing their individual autonomy, has decided to develop the component according to standards, design principles, and tools that are different from those of teammates and other teams (essentially, a local optimization,) then the result is likely to be sub-optimal overall.

Some individual autonomy must necessarily be sacrificed in the interests of effective collaboration. It’s possible, even desirable, that individual pursuits of mastery and purpose can be maintained. However, it may be necessary for an individual to focus on mundane tasks and the objectives of the team for periods of time. Finding ways to maintain a healthy balance between the intrinsic motivators and the purpose of the team is no small task and, when found, requires constant attention to maintain.

Perhaps it is possible to attach the team’s or organization’s purpose to the interests of the individual. Or sort for hiring people who have a personal purpose that is in-line with the organization’s purpose.

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.

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.

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.

Determining Effort Value – Tactics

While the concept and practice is straightforward, shifting a team from intuitive guesses about story points to a more deliberate approach for determining effort value (a.k.a. story points) can be a challenge at first. The following approach may help start the process.

  1. Begin by focusing on product backlog items (PBIs) that the team has estimated using their previous approach that are at a 5 or greater. There isn’t much to be gained by applying this approach to PBIs estimated at 1 or 2. PBIs that the team knows are a bigger effort but may not be able to articulate why that is the case are good candidates for learning how to apply this technique.
  2. Ask the team how much time it may take to complete a PBI. While I have written before about the importance of excluding time criteria when determining effort values, this can be a good place to start. It is what teams are most familiar with – for better or worse. Teams usually have not problem throwing out a time: 8 hours, 16 hours, etc.
  3. With the time estimate in hand ask the team:

“If you sit in front of your computer and start the clock, will the PBI be done if you do nothing and the estimated time elapses?”

I would hope the team would answer “No.”

  1. With the answer to the first question in hand, ask the following question:

If the passage of time alone won’t get the PBI work completed, what will you be doing (actions and behaviors) to complete the work?

The conversation that follows from this questions is the basis for determining the effort criteria the team needs to better describe what they will be doing on their way to completing the PBI. The techniques around establishing effort criteria are described in an earlier post.

Working with Distributed Teams

I’ve coached and served as scrum master for dozens of remote teams over the years. In light of current events, I’ve posted a collation of the notes I have for helping distributed teams working effectively.

The rule is, if one person on a team is participating from a remote location, the team is a distributed team. Making distinctions such as “distributed team” vs. “fully distributed team” when some or all members of the team are working from remote locations risks marginalizing team members who are working at locations away from the home or central office. 

To help ensure that the concept of “team” remains intact during distributed team conditions, this post is intended to serve as a guide for scrum masters for how best to facilitate and monitor team interactions and performance with distributed teams. 

Scrum masters have the added burden of developing the skills within their teams for effective distributed team collaboration and communication. Distributed teams can function better than collocated teams when the team’s skills for organization and communication have been improved by necessity such that they are better positioned to function effectively as a team. 

Etiquette 

 Even with ideal conditions (i.e. plenty of bandwidth for audio and video, intra-team familiarity, clear agenda, etc.) working with distributed teams will always have a degree of asynchronous communication. Fields of vision are limited to what’s in frame for the video camera, network latency issues, and a general lack of access to in-person non-verbal cues will cause people to speak over and interrupt each other and miss-read intent more than they would during in-person meetings. To mitigate these constraints, it is important to have a well understood and practiced set of etiquette rules for distributed team meetings. 

Pre-meeting Tasks 

  • The principle challenge is to keep everyone on the team focused. Shorter, more frequent meetings are better than long meetings that invite participants to “multi-task” out of boredom. Invite essential people to the meeting. Use of a responsibility assignment matrix is a very useful tool for determining who to invite. People associated with the consulted” or “informed” roles generally don’t need to be invited to formal Scrum meetings. 
  • Communicate an agenda – however sparse – prior to the meeting. Let the team know what the purpose and objectives of the meeting are so everyone knows when they are done. Agendas are scope management tools and help keep the meeting focused. Set the expectation the everyone on the team will be aware of the agenda prior to the start of the meeting. 
  • Ensure that all the necessary equipment is in working order and that all team members have verified connectivity. Test screen sharing capabilities and application accessibility prior to the meeting. 
  • It is preferred that the scrum master host the on-line meeting so that on the rare occasion they may need to take control of the meeting by muting or bumping someone from the meeting they may do so. 
  • Set the expectation that team members will participate from a location that is free from background noise and other distractions. Joining from coffee shops or while driving is to be discouraged as they end up being distractions for the entire team. 
  • Coach the team for how to take turns in a conversation. 
  • Coach the team on how to use any mute features. 
  • The rules of common courtesy apply to on-line meetings. If we wouldn’t accept a behavior in a face-to-face meeting, it shouldn’t be accepted in an on-line meeting either. 
  • Turn off notifications from applications such as email and instant messaging. 
  • Meeting participants need to be aware of what’s in the visual and auditory background and work to anticipate and mitigate potential interruptions.

In-Progress Meeting Activities 

  • Continue to stress that team members be on time for the meeting. Set the expectation that they will join on-line several minutes early to accommodate any last-minute technical issues. 
  • Meetings serve both a practical and social purpose for distributed teams. Allow time for casual conversation (and still expect everyone to be one time) as it is critical to building and maintaining rapport among distributed team members. Small talk, catching up, sharing interesting news bits, interesting (short) stories – any of these helps make the on-line meeting a more enjoyable experience and help set a positive tone for the duration. 
  • If a team member joins a meeting late, they should not announce to the team they have arrived. Doing will potentially disrupt a conversation already in progress.  
  • When a team member needs to contribute to a conversation while others are talking, the best approach is to state, “I have a comment.” or “I have a question.” and then pause. This serves as a signal to the team that you wish to speak. Either the conversation will naturally break, or the scrum master can listen for a break and offer the team member the opportunity to speak. The natural in-person behavior is to simply start talking. With distributed teams this frequently leads to several people talking at once and a degradation in communication.  
  • Ask for the opinion of someone on the team who has not yet participated in the meeting or has been silent for a period of time. This will help keep them focused on the meeting if they know they may be asked a question. 
  • Team members should leave a comment in the meeting chat window if they need to step away from the meeting for a short time or leave the meeting. Announcing such departures tend to be disruptive, but the team will likely need to know if any team members are not absent from the meeting.
  • Remain attentive to anyone who is dominating the conversation or otherwise preventing others from contributing. 
  • For stand-ups, call out the person who is going to start the conversation. Assign that person the task of choosing the next person to speak and so on until everyone has had their turn at contributing. This will help keep each team member’s attention as they will not sure when they will be called on. Similarly (but less desirable) randomly call on team members and vary the pattern day-to-day. 
  • When conducting a meeting where only one or two people are attending remotely, ensure that both the conference room and the remote individuals are using video. This will allow for additional non-verbal cues to be included in the communication and help keep the conference room aware that one or more of their team members is attending remotely. 
  • Leverage chat for one-off conversations or bringing non-priority items to the host’s attention 
  • If video is in use, be aware of the need for patience when waiting for network latency to catch up with any shared screens. 
  • Start the meeting with everyone on video. After a few minutes for casual conversation and catching up, allow team members to switch off video to reduce bandwidth issues. 

End-of-Meeting Activities 

  • Provide a recap of what was accomplished and identify any of the goal or agenda items were not addressed. 
  • State any next steps. 
  • State any action items and the names of people responsible for completing them. Action items without assigned names are in-action items. 

Troubleshooting 

  • If a member of the team has a pattern of responding to questions with some version of “I didn’t understand the question. Can you restate it?” or they have to be prompted with “Are you there?” due to a non-response, there is a likelihood that they are not focused on the meeting and busy with something else. If the pattern is persistent, the scrum master will need to discuss this with the team member off-line. 
  • Be attentive to the introverts on the team and work to have them contribute to each meeting. Ask them for their opinion or any open-ended question that has more than a yes-no answer. 
  • The metrics a scrum master may use to assess team participation and performance will need to be more robust than the usual data-based and subjective measures. Assessing morale or the presence of intra-team conflict may not be as apparent with distributed teams. Scrum masters may need to meet virtually one-to-one with each of the team members more frequently and asses any time management or morale issues.

References

Additional Articles

How to Collaborate Effectively If Your Team Is Remote by Erica Dhawan and Tomas Chamorro-Premuzic 

SwiftFest Boston ’19: Remote Connections: Fostering Relationships in Distributed Teams

Photo by Tanya Nevidoma on Unsplash (Edited)

The Perfect System in an Imperfect World

With apologies to Winston Churchill,

Many forms of project management have been tried, and will be tried in this world of sin and woe. No one pretends that Scrum is perfect or all-wise. Indeed, it has been said that Scrum is the worst form of project management except all those other forms that have been tried from time to time.

Agile in general, and scrum in particular, has suffered their share of hard yet deserved knocks. But many of these complaints come from people who are expecting perfection, some panacea or magic remedy to what ails their project management world. Often they want this perfection out of the box and miss the hard work needed to implement a relatively simple set of rules and guidelines while shifting from the “old ways” of getting work done.

Consider a flock of geese.

Over the course of hundreds of thousands of years they have worked out an efficient way to migrate. Not perfect, but well adapted to the world in which they live. At the heart of this behavior are several important principles: Shared responsibility, clear communication, and coordinated effort.

Consider Agile similarly. It is a perfect system for an imperfect world. The principles found in the formation of a flock of geese can be found within the Agile Manifesto. Its foundation of assuming the need for experimentation, learning, and adaptation is central to it’s enduring success. If these values are absent from or poorly represented in an organization’s culture, the chances for sustainable success using any methodology are diminished.

Photo by Josh Massey on Unsplash

Book Review: Tribes – We Need You to Lead Us

Tribes: We Need You to Lead Us by Seth Godin

Reading Godin is a lot like going for an enjoyable mountain hike and finding a handful of small gold nuggets along the way. No heavy effort to dig for miles in order to find the deeper, richer vein of wealth. Just enough interesting shiny bits of useful wisdom scattered along the trail to invite the reader to explore further.

“Tribes” isn’t so much about the composition and character of tribes, per se, but more a call to serve as a leader for tribes yet to be formed. “Human beings can’t help it,” he writes. “[W]e need to belong. One of the most powerful of our survival mechanisms is to be part of a tribe, to contribute to (and take from) a group of like-minded people.” But left to their own devices, tribes dissolve or evolve into something directionless, perhaps unruly. What they need to persist is some form of leadership to set the rules and customs.

Speaking to aspiring or future leaders, Godin presents what he views as the biggest blocker to people stepping up and fulfilling leadership roles.

The only shortcut in this book, the only technique or how-to or inside info is this: the levers are here. The proof is here. The power is here. The only thing holding you back is your own fear….Dr. Laurence Peter is famous for proposing that “in a hierarchy every employee tends to rise to his level of incompetence.” In other words, when you do a great job, you get promoted. And that process repeats itself until finally you end up in a job you can’t handle….I’d like to paraphrase the Peter Principle. I think what actually happens is that “in every organization everyone rises to the level at which they become paralyzed with fear.”

And the source of that fear is rooted in misaligned beliefs about criticism and failure.

As with almost everything I read, my eye is searching for ways the information I’m acquiring can be applied to improving team performance. The notion of tribes appeals to me from a social community perspective. I firmly believe there are deep psychological patterns in the human mind that unconsciously gravitate toward the idea of belonging to a tribal structure. And yet, there are limitations to that structure in the 21st Century business world. As Godin notes, “[I]n addition to the messages that go from the marketer or the leader to the tribe, there are the messages that go sideways, from member to member, and back to the leader as well.” What about communication between tribes? How might we avoid the formation of silos and corporate turf battles? These are questions for which I’ll need to continue searching as they are not addressed in “Tribes.”

Written more than ten years ago, there are elements of the book that have not aged well. For example, writing at a time which many today are considering the Golden Age of the Internet, Godin observes “In the nonsquishy tribal world of this decade, Twitter and blogs and online videos and countless other techniques contribute to an entirely new dimension of what it means to be part of a tribe.” And later, while writing about how easy it is for tribes to connect, communicate, and spread messages: “The tribe thrives; it delivers value and it spreads. Internet folks call this viral activity, or a virtuous cycle.” More commonly today the technology noted by Godin – particularly Facebook and Twitter – have resulted in the formation of more mobs than tribes and the cycles are 2019 are more vicious than they are virtuous.

However, I don’t think Godin was casting his gaze into the future through entirely rose colored glasses. He notes that crowds (and their blunt force object version: mobs) and tribes are “[t]wo different things: A crowd is a tribe without a leader. A crowd is a tribe without communication. Most organizations spend their time marketing to the crowd. Smart organizations assemble the tribe. Crowds are interesting, and they can create all sorts of worthwhile artifacts and market effects. But tribes are longer lasting and more effective.”

Several of the gold nuggets I picked up pointed to the importance of systemic thinking and analysis:

Leaders don’t care very much for organizational structure or the official blessing of whatever factory they work for. They use passion and ideas to lead people, as opposed to using threats and bureaucracy to manage them. Leaders must become aware of how the organization works, because this awareness allows them to change it.

Working in an environment that’s static is no fun. Even worse, working for an organization that is busy fighting off change is horrible.

When you fall in love with the system, you lose the ability to grow.

The status quo is persistent and resistant.

The last quote is a clear reflection of Shalloway’s Corollary. The status quo is the system pushing back.

I’ll round out this review with a few quotes that apply to a life in general.

Leaders have followers. Managers have employees.

If you need the alternative to be better than the status quo from the very start, you’ll never begin.

Life’s too short to fight the forces of change. Life’s too short to hate what you do all day. Life’s way too short to make mediocre stuff.

Defending mediocrity is exhausting.

Instead of wondering when your next vacation is, maybe you ought to set up a life you don’t need to escape from.

People don’t believe what you tell them. They rarely believe what you show them. They often believe what their friends tell them. They always believe what they tell themselves. What leaders do: they give people stories they can tell themselves. Stories about the future and about change.

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. Taken to it’s logical conclusion, 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.