Software development has changed substantially since that cold February day in Utah when 17 developers came together and agreed upon the fundamental principles that drive what we now know as Agile. Many development teams have adopted these principles and have started to embrace the individuals who will use the applications they create, and appreciate how those users will interact with what should be truly great working software.
These principles are fantastic as they allow the true stakeholders to get the software they want. However there’s one piece to that Agile Manifesto that often time leaves me in a bad place… The notion of responding to change over following a plan on the surface is great, in principle that is.
My interpretation of this ‘responding-to-change’ thing is that you start with a fundamental list of requirements that need to be achieved to create “working software”. After getting into the development process there’s an expectation that some of what you’ve deemed required has been modified in some way and developers should be prepared for this. They’re producing working software in smaller iterations (compared to traditional big bang releases) and they’re collaborating more closely with the business to periodically ensure they are heading in the right direction. All sounds great so far – what’s the problem?
The problem is what happens when embracing change leads to completely reworking what were thought to be complete builds. Ok, so maybe that’s a bit drastic – but what happens when those previous builds need an amount of rework that you need build periods dedicated to just these changes? Well we have a couple options, then:
- We can just accept it and expect to have to increase the number of build periods by at least one.
- We can hope the principles of this methodology allow for the users to understand that they don’t need as much of the functionality as they originally requested which will give us this time back by the end of the complete development cycle.
It’s my experience that rarely do the stakeholders agree that they don’t need things they originally ask for. Often times we figure out a better mouse trap, meaning we accomplish what they need with less effort as it doesn’t need to be as sophisticated as they originally defined. This is great but typically isn’t going to buy us enough time to keep on our original estimation for delivery. I know, I know, we’re delivering at the end of every build cycle. But let’s be honest – this is a service, and we aren’t done until we’re done.
Ok, so with all of that said, let’s get to my original point. Can we afford to be Agile? It seems to me that projects based on an Agile methodology might end up going a little longer than expected, but what they also do is result in software that is truly what stakeholders need. This slight increase in development hours will always outweigh the cost of developing software that misses the mark, and that makes the cost conversation around Agile a lot easier to make. If we consider change an inevitable variable in every software project (as Agile does), there is an innate value in using an this methodology – not for its time-savings (there are other ways of speeding up development) – but for its adaptability.