Changing requirements, why and when to say “no”

One of the biggest challenges I hear with developing software is requirements stability.  Change has a nasty effect on code quality, and that effect is not necessarily overcome simply by going to Agile software development.  Change in itself is not a bad thing, but how we deal with change can be.

If we simply march forward leaving the delivery date as is, we’ve effectively played a game of chicken with a well known limitation – in any stable software development methodology you may set two of these three parameters: features, time or cost.  Pick any two; the third you cannot control.  So, when change comes along and you don’t modify the resources or the delivery date AND you add more features an implicit feature gets dropped.  That implicit feature is quality. 

We’ve gone so far to study this, and found the effect to be both statistically significant and practically significant.  Projects which accept change controls have defect densities which are, on median, 85% higher than projects which do not experience change.

So what can we do?  The first reaction I’ve heard from development teams is to go tell the business to produce better requirements.  Fair enough.  If the business knew exactly what they wanted and specified it, the issue would be solved.  Alas, even though LEAN thinking would prefer we solve the problem holistically, we often find ourselves in situations where we lack the ability to change the inputs we get.  We have to do the best we can with less than perfect requirements, and we need to know where to push back for more clarity and when to refuse change.

Here are the rules of thumb that I believe could guide these decisions:

  1. Differentiate between “I didn’t know I had that requirement” and “I didn’t bother to figure it out.”  There is a place for new requirements to appear that nobody realized we had.  That’s distinctly different from a lazy business partner who thinks you can make do with a napkin spec and is unwilling to sit with you to be constantly involved.  For the former, c’est la vie, accept they exist and determine what is going to change to include it – late delivery, more resources, or let the quality slide.  For the latter, spend some time bugging the user up front to help them figure out their requirement(s).  Even though they’re unwilling to do it themselves, prototype something up and show them.  Spend a little bit of money to learn a lot rather than having an expensive rework situation later.
  2. Differentiate between “I’d like this different” and “this matters”.  If upon building the piece of the system the users says “wouldn’t it be neat if…”, put it on the to-do list.  If the user can articulate a competitive disadvantage if the feature isn’t changed, change it.  As an organization, we all have lots of ideas about how software should work, but you can get drowned in gold plated features that have negligible impact on value in the eyes of our customer.  As a development organization it is not wrong to ask the business to articulate how this change will improve the customer experience and politely suggest that maybe that change wait until later or perhaps never.
  3. Tom and Mary Poppendieck suggest “delay commitment.”  They’re drawing from LEAN’s philosophy of pull.  If nobody is asking for it, then why are you building it?  Generally, I agree with this concept – don’t gold plate your software with developer ideas that nobody asked for.  However, if a user knows they require a new report, you aren’t delaying commitment when you ask them to specify what that is.  What you can delay commitment on, however, is exactly how it looks.  The critical piece to architecting a system isn’t what the user interface (and yes, a report is a form of a user interface) looks like, it’s knowing what data you’ll need when and where.  You don’t need commitment on the smallest detail, but you do need commitment on the key data elements you’ll have to spit out.  If you can’t get the key bits, maybe it’s time to put the brakes on.

It’s never my goal to not serve our customers, but there are techniques we can leverage to make change less likely to occur.  We will never avoid all change, because there are things nobody could have anticipated such as changes in the marketplace.  But we can create a sense of stability by proactively extracting knowledge instead of attempting to read the tea leaves of vague requirements.  It doesn’t need to be all or nothing.  Then combine it with a LEAN development approach to create the software efficiently so requirements don’t become stale just because you’re moving slowly.