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.
You will probably need to spend more time in Foundations, driving a little more certainty around business processes affected, the technical design and such-like. Risk identification becomes more important and plans will necessarily become more detailed to mitigate some of those risks.
Consider doing more modelling of things like Customer Journey, which should be agreed with the customer as part of Foundations.
With your Business Ambassador / Advisors not available on a day-to-day basis, you will need to be a lot more clear about the requirements during Foundations. You will probably need more of them and in more detail than would otherwise be ideal.
Within each timebox, agile teams spend some time at the start Investigating the details of each story with the business. Without the business involvement this requires – and the additional detail in the user stories mentioned above – the Investigation part of the timebox need not be so long, and will mainly be focussed on technically drilling down to task level.
If the project has too high a percentage of Must Have requirements (more than 70% Musts poses an increased risk), you need to find contingency elsewhere – your 'Plan B', in case the project encounters problems. Think about adding an additional timebox to the Delivery Plan to give you time contingency, and/or add additional people to give you Cost (people) contingency… from the start of the project obviously. Having no contingency is not acceptable.
If business acceptance of the solution is a problem, resulting in fewer stories being completed within the timebox, you might have to plan for longer timeboxes to give you more time to get developments tested and accepted. This is especially true of things like documents that require an extended approval process.
Plan in additional time for getting customer acceptance from the (often external) customer, who may have to pass several layers of approval within their own organisation before they can sign off what we've delivered.
Consider the use of "surrogate" Business representatives – far from ideal but still better than running a full-on traditional project and relying solely on a specification. Surrogates need to know the customer and their requirements well – well enough to make informed day-to-day decisions to keep the project moving forward, even though the formal final customer acceptance of stories may be delayed to one or more timeboxes after the stories have been completed. For example a "surrogate Visionary" could be an account manager, a "surrogate Ambassador" an account exec.
During the project, continue to press the customer for on-going acceptance of the solution, even if this is running behind development – it still decreases the risk of delivering the wrong thing at the end.
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. Continue reading