I have an application development background so I’m well aware of the benefits of agile methodologies. It’s hard to argue against the “deliver early, deliver often” approach. However, I often get on my soapbox about blindly following best practice and the agile approach is not without its sins.
When I was at university it was drummed into us that we should do the hard things first. This approach has served me well – and it makes sense. Delivering the most complex part of the system first:
- allows you to validate your architecture against the ‘worst case scenario’
- lets you assess the feasibility f the entire project early
- prevents complex parts of the solution being rushed at the end when the deadline looms
- it gives you more time to refactor/tune/test your solution
- it gives users more time to use the beta and provide feedback
Unfortunately, misunderstanding the agile approach leads teams to take the opposite approach. I recently came across a project that was keen to “deliver early”. Nothing wrong with that – except that the team was planning to achieve this by “leaving the hard stuff for later”. The “hard stuff” included critical architecture decisions. This is crazy. The first release of any solution should have limited business scope but must be architecturally sound. Why deliver something that will become “instant legacy”?
So how can you reconcile the need to “deliver early” with the need to “do the hard stuff first”? Luckily the solution is simple: develop a proof of concept before the project begins. Doing R&D during a project is a recipe for disaster. Doing a prototype means that you have a chance to tackle the hard stuff and you can also deliver it early when the actual project starts.