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

Remote Teams: Non-verbal Communication

Scrum mastering remote teams demands an extra set of skills than those required for co-located teams. The non-verbal cues we’ve learned growing up and throughout our careers are often not available with remote teams. Consequently, we have to train our ears to listen more attentively and follow-up to verify any assumptions regarding meaning from conference call, email, or instant message communications.

As scrum masters, we also need to coach team members to deliberately introduce practices that accommodate the lack of non-verbal cues during scrum meetings. For example, there are two practices I implement during remote stand-ups that facilitate the feel of co-located stand-ups.

  1. I call out the name of the team member who’ll kick off the stand-up conversation. When they’ve completed informing the team what they’ve worked on yesterday, what they’re working on today, and anything in the way of success the delivery team member calls out the next team member to take the conversation. I’ve found this keeps the rest of the team focused on the conversation better as they won’t know when they’ll be called.  Everyone will have to track who has already presented to the team. In the past I would randomly call out names until everyone on the team had their chance to speak. While they didn’t know when their name would be called they could still count on me to make sure everyone had their turn. Frequently, however, I’d have to call out a name several times to get that person’s attention away from whatever it was they were “multitasking” on. Having the team call out the next person to present has helped resolve this issue.
  2. After the team member has presented and before they pass the conversation to the next team member, I coach them to pause and ask if there are any questions from the team. In addition to signaling the end of their presentation, this makes the remote stand-up a little less mechanical and puts the thought “Do I have any questions?” in the minds of the rest of the team. More specifically, I coach the team with some version of the following: “Pause after your presentation and ask the team if there are any questions, observations, suggestions, comments, or clever remarks.”

Using techniques like this with remote teams does not replace the richness of co-located scrum meetings. They do, however, move the two a little closer.

 

Photo by Ivars Krutainis on Unsplash