Reacting to change

When dealing with the possibility of change in requirements in the middle of development, I’ve generally seen three reactions:

• Explicitly reject the possibility
• Ignore it completely, hope it goes away
• Accept and embrace it

Of these three, only two are valid reactions.  There’s a time for explicit rejection of new requirements, even in Agile and iterative development.  Unfortunately, most of the places I’ve encountered fall into the middle bucket, ignoring new requirements or actively subverting those expressing them.

Explicit rejection

There’s nothing wrong with explicit rejection of new requirements.  In iterative development, once the stories have been selected for an iteration, no new stories can be added to that iteration.  Stories are often split during planning, and sometimes new stories are surfaced during an iteration.  Agile teams have to be disciplined not to take on new work during an iteration, as this can jeopardize finishing the original stories selected.

By keeping iterations short (1-2 weeks), business owners never feel too bad about new requirements (and eventually stories) being surfaced.  It’s a natural part of the development process.  As software is delivered incrementally, assumptions are challenged and directions can change.  But not during an iteration, as the team needs stable direction towards a defined goal.

Explicit rejection also occurs in phased-based development.  I’m moving away from the term “waterfall”, as it’s beginning to be a loaded term.  Instead, think hand-offs, sign-offs, and phases (planning, development, testing, delivery, etc.)  Changes in requirements are explicitly rejected during the development phase, but the realities of software development tend to force compromises in this area.  This can lead to contentious relationships between analysts and developers, as each tries to maneuver and politic to get their way.

The way I’ve seen this go down is usually developers will assign very high estimates on items surfaced late in the game, so that those signing the checks can’t justify the new features getting added.  Then it becomes a trick of the analysts to ask for 100 features all with “Must Have” priority, with the full knowledge that only 10 will actually get delivered.

Ignore and hope

Explicit rejection in phase-based processes lead to ignoring and hoping changes don’t come in.  There are plenty of ways to ignore change requests, such as ignoring emails and dismissing changes out-of-hand.  Even explicit rejection is a form of ignoring, as it ignores the reality of software development.  As soon as a user sees the software for the first time, all presumptions of usability are thrown out the window.

Teams hope for no change requests by filling their plate as much as possible, so even the slightest deviation from the plan would cause delivery delays.  If change requests do come in, I’ve seen software teams keep track of them, for ammunition in later “blamestorming” meetings.

We can hope change requests won’t happen by attempting to design as long as possible up front.  Elaborate UML diagrams create the illusion that if we design everything before our fingers hit the keyboard, we won’t have to worry about analysts asking for change.  They had their chance, right?

Again, phase-based approaches lead to contentious (and even bilious) relationships between owners of each phase.  By assuming that all decisions can be made in the design phase, it’s little more than hoping that changes won’t get requested during development.

Accept and embrace

In iterative and incremental development, such as XP, changes are accepted and even embraced.  Because all assumptions are shattered the moment the user uses the software for the first time, your process should take this into account.  By allowing regular feedback, changes can be introduced, implemented and scrutinized in a very short time-frame.

It’s not all wine and roses of course, as feedback only surfaces problems, not solve them.  But instead of ignoring or rejecting changes, you have a regular mechanism for dealing with them.  Our team deals with changes by writing every task or story on a card.  If it’s on a card, it can be estimated and prioritized.

Since we use cards, a change in a story takes as much effort as ripping up the incorrect story card and writing a new one.  The less friction our process documents change requests, the more the business will be encouraged to explore new ideas.  Nothing’s worse than a hulking software requirements tool that stifles imagination through the tedium of managing lists of requirements.

Flexibility and Control

Since change is inevitable, we want to introduce a system that allows us to introduce change, as well as garner feedback on the effectiveness of these changes.  But we don’t want too much change, as this will introduce unnecessary chaos and churn.

The trick is to gather and respond to enough feedback, but not too much where the team is overwhelmed and is unable to deliver.  We want to be flexible to handle feedback from a variety of sources but control over when and how we receive it.

So how does a team perfect flexibility and control?  With more feedback of course!  Through regular Scrum retrospectives, a team can reflect on how they’re delivering, making small tweaks along the way.  In the end, we want a system that can handle and respond to change to maximize the business’ return on investment.