Imagine a project where the interface to be delivered has been locked down 90%, and you are already in possession of a solid architectural design. Would an agile methodology still offer any value in this situation?
It seems to me that agile methodologies (and I'm thinking Scrum), offer most value where there is a high degree of uncertainty about the requirements.
Would an agile methodology still offer any value in this situation?
Yes.
It seems to me that agile methodologies (and I'm thinking Scrum), offer most value where there is a high degree of uncertainty about the requirements.
Also true.
Here's the point. Agile is a life-style. Read the Agile Manifesto a few times.
You are not prohibited from locking down the interface. You are not stopped from using a solid architectural design.
You are encouraged to interact, create software, collaborate and respond to change.
You are not prohibited from doing design work.
The point is to avoid hyper-complex, fussy processes and procedures for change control. Avoid the busy-work of writing long, detailed specifications when a conversation would do.
Agile could definitely still offer value, although it might not be worth switching if what you are already doing is working well.
Agile offers a lot of value in situations where priorities are unclear or change frequently, but I find it has other benefits as well. I find that Agile methods tend to improve developer morale (when used correctly), reduce unnecessary process, and increase communication both within the development team and between the development team and the business owners. The increased communication, IMO, is the biggest advantage to Scrum / Agile, as this leads to better risk management and more efficient processes.
I think the greatest risk is that Scrum takes a few sprints to get working smoothly. Scrum relies heavily on the ability of developers to make good estimates, and this is a learned ability. Also, most teams need to adjust the rules a little bit before it works well for them. Scrum provides a great process for this through the retrospectives, but the first two to five sprints can be a little discouraging. After that, I've generally seen teams pick up significantly and greatly increase their efficiency.
The idea that requirements can be locked down early in the project is exactly why agile came into existence in the first place. One fundamental agile idea is that the customer/user cannot know what they really want, until they can actually see and use the software. The agile approach is to release as early and often as possible and get real feedback from and adapt your project from that.
If your project requirements is truly "locked down", you loose the obvious benefits of early releases. I still think using agile is beneficial in this case anyway, because it can really help you dealing with nasty integration phases and testing (using continuous integration and automated testing for instance).
Agile has one BIG benefit - it prevents "Paralysis over analysis"
It forces you to code something (essential features first) and get it working and then and only then you can re-factor and continue with other features.
The essence is not to care about what could happen - because when it will happen you'll have "something" and your decisions will be much more easier.
