I’m continuing my midsummer reblogs this week as I take a little vacation. I’m revisiting some of my earliest blog posts from 2012 and finding that the ideas that originally motivated me to start this blog still resonate for me today. Posting at a slightly different time so I don’t get lost in July 4th celebrations. Hope you enjoy this one. Thanks as always for reading.

Perhaps in an ideal world of software development, all of the requirements for a product can be anticipated and articulated at the start of a project, all obstacles avoided during the development cycle, and all time lines and budget projections can be hit with precision.

Of course, in truth it’s not that simple.  It never is. Unanticipated difficulties emerge that will impact the timing of the project, the cost of the project, or the set of features that the project will deliver.  Beyond that, as new software is developed the target market for that product can change in subtle or significant ways.  New insight can be gained into the true needs of the target users.  Any of these factors can produce changes to the originally articulated requirements for the product.  How does a software development team react to those changing requirements?

Here’s a link to one of my favorite examples of changing requirements (if you’ve been following this blog you can probably guess where this comes from): http://www.youtube.com/watch?v=QTQfGd3G6dg&feature=related

The original requirements seemed fairly straight-forward: ‘Bring us a shrubbery.’  But once that requirement had been met, new requirements emerged: ‘Bring us another shrubbery… [and] place it here beside this shrubbery, only slightly higher so you get a two-level effect with a little path running down the middle.’  Then a third requirement of a completely different nature was added to the first two: ‘Cut down the mightiest tree in the forest… with… a herring!’

Hopefully most software development projects don’t have such swings in the definition of their requirements.  But the goals of any long-term project will evolve over time.  Software development teams following an Agile methodology will respond to these changes in very different ways from those that a team using a waterfall methodology would respond.

Under more traditional waterfall approaches, before any development takes place all of the requirements for the product are discussed and written down in a set of documents that all parties agree to follow.  Once the development commences, any changes to those requirements provoke a ‘change management process’ typically led by a project manager.  Work effectively ceases until new requirements can be defined, documented, and agreed upon and new time and budget estimates can be developed and approved.  Then the project picks up again.  Alternately, the decision might be made to go ahead based on the original plan and later retrofit the product in an attempt to meet the newly discovered requirements.  In some cases the entire project might be scrapped and the team would go back to the drawing board.  Changing requirements becomes complex and costly, potentially jeopardizing the success of the entire project.

Agile software development teams react differently to changing requirements.  In fact, one of the primary goals of this methodology is to enable nimble responses to changing requirements and priorities – because this approach assumes that the world is always changing.  Software development projects are not planned and executed in massive blocks that require huge efforts to turn once they begin.  Instead work is planned in short ‘sprints’ that allow for the development, testing, and deployment of smaller increments of useful software throughout the project.  Each new sprint (typically 1-4 weeks in length) begins with assessment and prioritization of the requirements for the next stage of development, allowing the product owner and the team as a whole to respond to unexpected difficulties, changing user needs, newly available technologies, and fresh requirements.

An Agile approach is particularly useful when dealing with software development that addresses highly complicated and complex problems.  As the Cynefin framework points out (see http://en.wikipedia.org/wiki/Cynefin) some kinds of problems don’t lend themselves well to upfront analysis followed by solution development.  Instead the nature of the problem to be addressed means it is much more effective to work iteratively between probing and responding, allowing solutions to emerge as the team gains new insight into the underlying issues.

Developing software solutions for complex problems works best when the approach anticipates and responds well to the changing market and technology landscape.  This central aspect of the Agile software development methodology makes it much easier for a team to handle requirements that change during the course of a project.  The approach allows teams to adapt and reprioritize quickly in response to newly articulated user needs.

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