Over the last few years, I have been asked a few times variations on the question; “What projects are suitable for agile, and which aren’t.” It’s a fascinating question, and one I think has a relatively simple answer. It depends. It depends on how much you have of two specific things which are absolutely essential for agile to work, however you define what Agile is – active business involvement in a cross-functional team, and flexible requirements prioritisation, i.e. not all requirements are Must Have.
If you have a very actively-engaged Business Ambassador (Product Owner in Scrum terms), and less than 60% of your requirements are Must Have essentials, you can afford to be agile, and you can set your project up accordingly. In other words, you can afford to defer exploration into the details of requirements and the solution until the last responsible moment, because the business is there to have those discussions and you have contingency to play with if your estimates are not spot-on, so you can plan at a higher-level, start earlier and develop iteratively.
But what if you don’t have those things?
We have coined the term ‘specification-led’ which means that the business or technical environment around your project is such that you are not able to be fully agile, and that you are forced to do more up-front specification than would otherwise be ideal. A ‘fully agile’ project is one :
· that has daily active business involvement, which allows the solution to evolve to meet the business need,
· that has feature-contingency in the shape of sufficient Should have and Could have requirements.
· in which the project can integrate and test the evolving solution frequently.
It is important to plan your Foundations stage based on the answers to the Project Approach Questionnaire, so the first thing to do – during the Feasibility phase – is to complete the PAQ. This should give you an idea of the environment you are operating in.
Project Managers are advised to always try to establish the most ‘agile-friendly’ environment possible. Any compromises constitute a risk to delivery and these should always be escalated for resolution or mitigation where necessary.
Having said that, if you don’t have that ideal environment, what do you do? Fortunately, the DSDM framework allows this sort of tailoring (indeed encourages it), but here are a number of things you might need to do.
Thinking of DSDM as a flexible framework that can be tailored to any project is the answer to the question I posed at the beginning. It doesn’t really matter which projects are suited for Agile, we can always tailor DSDM appropriately.
Remember though, that you are still striving to be as agile as possible, and it may be more than you initially think.
With thanks to Dave Lyon and Barbara Roberts for their help with this article.