Continuing my summer revisiting some of my favorite posts from 5 years ago, here’s another in my early blog series on the key concerns of a product owner. I hope you enjoy these thoughts on how to think about changing requirements in an Agile development environment.

Sometimes it is the supposedly little changes that introduce the largest problems into a project.  An apparently small change to a requirement.  A minor feature introduced at the end of a sprint.  A slight tweak in the expected results.  Often it is those outside the actual development team who introduce this small request, asking for a feature or enhancement that appears easy on the surface (‘Can you make it also do this’ or ‘we want it to do something slightly different from what we originally asked for’).  Other times the seemingly simple change is introduced by a programmer late in the development cycle because ‘it’s so small it won’t really impact anything else and shouldn’t require major testing to confirm that it works fine.’

The small change looks as harmless as a little rabbit (just like this: http://www.youtube.com/watch?v=XcxKIJTb3Hg).  But of course, in truth it’s not that simple.  Sometimes the bunny has teeth, and what sounded like a minor change produces major headaches due to unintended consequences in other areas of the application or unanticipated results from the change itself.

So what’s the best way to handle these seemingly innocuous changes?  Remembering five (I mean three) simple things:

1. In truth it’s not that simple.  For complex software in which there are several layers of dependencies, no change is a really a little one.  Because a small change in one area may have an impact on other parts of the application.  Therefore it is important to involve the right set of people when deciding to make a change.  Involving key programmers and testers along with the product owner in these decisions may be slower than simply having one person make a ‘small’ change, but slowing the process down can save lots of headaches (or lost heads) later on.
2. Be careful when you make a change.  One of the benefits to Agile software development is the ability to react nimbly to changing requirements and expectations; but even here it is important to plan on the timing for making these changes.  Introducing new elements at the beginning of a development cycle or ‘sprint’ allows time to see what impacts the change has downstream, while making changes at the end of a sprint gives less time to observe and respond to the repercussions of even small changes.  My high school wrestling coach called this the P rule: proper prior planning prevents piss-poor performance.  It can also be a useful practice to incorporate feature switches around some functionality, allowing them to be turned off easily if unexpected problems crop up after they are deployed.

5. (I mean 3) Have a good testing plan around any changes that get made.  A strong testing team is really the ‘holy hand-grenade’ in dealing with the nasty rabbit of dangerous changes (here you go: http://www.youtube.com/watch?v=xOrgLj9lOwk).  Involving testers in the conversations about what changes to make and what the expected results are from those changes allows these developers to work hand-in-hand with the programmers to ensure that changes produce only the expected results.  And a full suite of automated regression tests help determine when there are unexpected impacts from changes that are introduced.  This is why the best development teams include a strong set of testers working closely with both the product owner and the programmers.

Few things can provoke panic and frustration in a software development process the way supposedly little changes that produce large negative consequences can.  Don’t be fooled when a request seems minor.  Instead remember the complexity behind the dependencies in software, plan when and how to introduce changes, and have strong testers that partner with the programmers.  This will at least help mitigate the impact of what look like small changes.

Of course, in truth it’s not that simple.