Agile software development methodologies are all the rage, but how do you get this powerful iterative approach right?
Done well an agile approach to development can lead to far more efficient, inclusive projects, helping to keep everything on track and delivering exactly what’s required. But done badly and with the wrong expectations they can lead to project chaos, with increased timescales and out of control costs.
What I’m referring to with ‘agile’ is an iterative approach to defining and delivering systems requirements. There are many specific agile methodologies and techniques, such as Scrum and DSDM, but they are all based on an iterative approach rather than a more traditional Waterfall methodology.
How do you get this iterative approach right?
What to avoid
First up, here are a few common agile mistakes and misconceptions that will take your project off course.
“Agile means everything is going to be quicker and easier”
Maybe it’s the term ‘agile’, but more often than not, companies moving to an agile approach for the first time are convinced that this guarantees shorter overall project timescales. This is simply not the case and not, in my opinion the point of agile. Agile is all about reducing risk. Reduced risk may well lead to shorter timescales, but you how would you know! Simply saying ‘we’re going to do this in an agile way, so we can bring our completion date forward’ is wrong. And when you’re running out of time you can’t just make your project ‘more agile’ to compensate.
“Agile means less project management”
Agile is not an excuse for not planning or managing your project. In my opinion, agile methodologies, with their more fluid approach, require stronger project management throughout the whole duration of the project, to ensure the everyone is delivering their tasks to ensure each iteration is ready to begin and delivering what is expected.
“Agile means you don’t need to do the requirements”
“We don’t need to do the requirements, because we’re agile”. Not true. What is true is that you might not need to understand the details of the requirements at the beginning of the project. But unless you have planned for a lot of contingency to rework the development, then it is essential you have a good understanding of the high level project requirements.
Having no requirements is akin to a ‘prototyping’ methodology where you are prepared to throw the whole thing away and start again. This, in my mind, is not what agile is about.
Every project needs to be built on firm foundations and to get the foundations right you need to have a good idea of what the project is going to deliver. If your know your building is going to require an underground car park, you don’t spring it on your builders two weeks before construction ends!
How to get agile right
Plan your iterations well, know what your iterating over and manage expectations.
Some projects like to iterate over detailed requirements and build, and then deliver the project as a whole into test, other times you do more upfront requirements analysis, and iterate around the build and test. Just make sure everyone knows what is coming and what the limitations of each iteration are. Testers who are constantly raising defects on requirements that haven’t been delivered, is a common side effect – annoying for all involved (especially the testers) and a cause of confusion and poor project morale.
Make sure you have planned for rework and changes.
The very nature of an iterative approach means that changes to the initial requirements are inevitable, since that is one of the main reasons of this approach. However, this rework must must be expected and planned. When timescales are tight, it is all too easy to plan out all your iterations right up to the deadline leaving no room for contingency.
Remember, you don’t know what you don’t know, and there’s probably a lot you didn’t know at the start.
When done right, agile methodologies keep everyone more involved in the project, keep enthusiasm high and ensures your project delivers functionality that everyone is happy with. Done badly and you can kill off the morale, and quickly loose control of timescales and costs, so approach with thought and care.