One of the biggest critiques of Agile software development methodologies is that the planning is almost non-existent. Indeed, there are some Agile teams that get pretty aggressive and begin developing with very little detail of the system requirements. The idea is that as they receive more information, they’ll just refactor their code as necessary. While the ability to quickly refactor is a valuable skill, this approach can be taken to an extreme. Consider construction of a building. If you decided 3 months into the project that you want blue paint instead of yellow, no big deal. Changed your mind on the shag carpet? No problemo. Decided it should be a 40 story building, not a 3 story building? Hmmm…lots of wasted time and money that could have been saved by doing a reasonable amount of planning.
No matter what project methodology you use, certain planning activities are necessary for a successful software development project. Here is a link to a slide of the Agile software development lifecycle (SDLC). It also shows the activities by phase. Over the next few months I’ll expand on each of the activities identified on this slide.
The slide identifies 4 main project phases. These are pretty standard across methodologies, although they often go by different names:
- Discovery – Identify business case and high level project scope
- Design – Define requirements and mitigate risks pre-development
- Delivery – Develop, test, and release working software
- Deployment – Deploy working software and provide support
OK, so I’ve been going on and on about how much Agile follows the same SDLC as other methodologies. While the high level activities are the same, the timing and depth of each activity can differ greatly. The main point is that Agile is iterative, i.e. you don’t complete all work in one phase and move to the next, as in Waterfall projects and many RUP projects that I have seen. Instead you complete enough planning early to mitigate overall project risks and provide adequate direction to begin the highest priority development as soon as possible. Reams of documentation can be impressive, but at the end of the day, it is the working software delivered early and often that puts the smile on your customer’s face!
Excellent article - no matter which method is used, you have to be able to build in extensive contingicies e.g. the blue paint example you gave.
ReplyDeleteAlso the postmortem & party - rarely happens!