When agile just doesn’t seem to fit, it’s time to back up and think about what assumptions agile makes. If the basic assumptions of agile don’t hold on your project, then agile “by the book” isn’t likely to produce the results you want. You need the right tool for the job.
Agile methods assume high uncertainty, which generally does hold true.
- We aren’t sure what the user really wants – and asking doesn’t necessarily work.
- The users’ desires may change over time.
- The environment in which the software works has many unknowns – operating systems, networks, and so forth change without warning.
- It’s difficult to predict how long it will take to complete a feature.
Agile methods also assume low cost of change:
- A feature can be reworked in a matter of hours or days.
Agile essentially learns by doing – take your best guess, implement it, and find out if you were right. This works very well when uncertainty is high and cost of change is low. Software is naturally pretty malleable, and agile teams are motivated to develop practices and tools to further lower the cost of change, such as automating their regression testing.
But what about when the cost of change isn’t low?
For instance, the cost of change for major architecture decisions is often quite high. If you’re writing a big suite of payroll tools wrapped around a Commercial Off-the-Shelf (COTS) application, switching from one COTS app to another midstream is likely to be very expensive. Learn by doing isn’t very practical.
In this situation, it makes more sense to research and experiment instead, until you have enough information to make the right decision, and then do traditional agile. If there’s only a little research, it can be managed within an agile project as a “spike”. However, agile isn’t really optimized for managing research – it’s optimized around delivering software. When you have many spikes to manage, it can be more effective to use an agile method that *is* optimized to manage research.
The Rapid Learning Cycles framework is an adaptation of agile specifically for managing learning and research in the early stages of a project. It was designed for hardware projects, where cost of change typically is very high, but it’s also applicable to some software projects which have unusually high cost-of-change. The Rapid Learning Cycles framework doesn’t replace agile, but rather is used side-by-side to manage the learning and research while traditional agile methods are used for the actual software development.
That’s an example of using a different tool from the agile family for a job where traditional agile doesn’t quite fit.
Learn more: Agile for COTS projects