Choosing the best methodology for your project is easily done. However, while the right choice can help your project succeed, the wrong one can cause you endless grief and heartache. I will try and show how you can make good choices and the basis on which the choice should be made.
“Choose well. Your choice is brief, and yet endless.” Goethe
Firstly, avoid the zealots
You know the ones. They have committed to one methodology or another and invested time, effort, money and emotion in a particular approach and neither love nor money will divert them from their chosen path. The particular sin that they practice is the narrow focus that they bring to, what are in general, complex problems. After all, if all you have is a hammer, after a while everything starts to look like a nail. Listen out for the signs “we always…..”
Understand the nature of your project
What are you trying to do? Is it a process heavy piece of integration with well understood interfaces to third party systems, or is it a start-up idea that’s trying to fill a gap in the market? How much uncertainty is there versus how much documentation?
Lean is ideal if you have an idea to test and you want to (potentially) ‘fail fast’ (and succeed sooner) before you’ve over committed, uncertainty is high and it is the base hypothesis that you are testing.
Agile is good where there is a known requirement but where there is some uncertainty, scope is changing rapidly, and where there is flexibility for decisions to be made later on.
Waterfall works best where the environment is known, it’s important to cross “t”s and dot “i”s and there’s a need for Reliability, Availability and Serviceability (RAS).
Consider how you will test
Understanding the landscape you are living in will help you to understand what your focus should be. I find it useful to think how I will be testing my solution as that gives insight into approach as well.
Will it be testable against a fixed requirements list (or fixed outcome) or will it be testable against customers? If it’s testable against customers, is it something they are used to or is it a new proposition?
Why are we testing / what is valuable to test? E.g. project works well across all iOS devices, or that it’s a useful tool users would want to use (proposition)?
Testing against fixed outcomes does require a more formal approach, with repeatability and reliability to the fore, so Waterfall fits into that mode well. The flighty nature of people makes Agile more suitable because you test and verify on a regular basis and understand and embrace change.
Testing for unknown things is very much in the Lean world, where you rapidly test propositions and incorporate feedback and lessons learnt into further iterations. There are no maps here so you have to find your way almost by touch.
Decide what’s important
For many projects there are three levers you can pull — cost, features and quality (although in practice there are many more factors you can trade off, but let’s keep it simple ). But as we all know, you can only have two out of those three. You can have lots of features at low cost but you compromise on quality. Equally, if features and quality are the issue, then cost will increase.
Estimating against certain features with high quality thresholds means that costs can be accurate — which suits Waterfall.
Lean works well when there is more of a focus on cost and quality, choose a feature to test, do it well, and iterate it by releasing early and releasing often.
Agile allows you to set a budget (number of sprints) and dial features up and down according to progress whilst keeping a constant level of quality.
Don’t ignore the people
Experience suggests that Agile teams achieve greater engagement and satisfaction than Waterfall teams (sweeping generalisation there), and the benefits of working in interdisciplinary teams covering the full lifecycle gives greater efficiency and better outcomes.
This is very compelling compared to the grind of building something that someone else in the organisation specified, in an inefficient way, that you can’t realistically change and where you are unclear of the purpose and benefits (we’ve all been there folks).
However, there is some benefit to the rigour that Waterfall brings, the certainty and focus that the specification has and the knowledge that the outcome has a known shape. When it’s done it is demonstrably done. And don’t forget that people brought up in the rigour of Waterfall, with its emphasis on RAS can find both Lean and Agile and their lack of certainty and structure quite challenging and disconcerting.
Time and Cost
There are also time/cost implications for the different approaches. These are generally related to uncertainty and risk and these will be related to the nature and needs of the project. The more you try and reduce your risk, the more costly and time consuming things become.
If there is lots of risk and you want to offload that risk to the project, then the time and cost will rise. If you can be more flexible in scope and outcome, maybe where “good enough” works then you can take on more of the risk yourself and decide how far you want to fund later further down the line.
It’s for you to decide who takes the risk on and what that is worth. You can of course outsource that to an agency, but remember they will be costing in the risk as well, so asking for fixed price and fixed deliverables will reflect the risk element that they are taking on.
Blur the lines
Ultimately the choice is actually broader than it seems, Lean often employs Agile methods especially Scrum and Kanban boards, Waterfall is useful on some Agile projects where some form of certainty is required at the outset — especially where there is a need for budgetary signoff — so you start with some specifying but then move into Agile sprints for delivery phases.
So, be flexible. There is no one size fits all, no silver bullet, no right answer. What is more important is to understand the approaches, understand their strengths and weaknesses, master your PM tools and use them appropriately.
However, a good rule of thumb to take forward is:
Waterfall — where there is certainty and risk.
Agile — where there is uncertainty and flexibility.
Lean (Lean/Agile) — where there is no certainty but some big questions.
That way you will hopefully deliver the project, retain your sanity and achieve great results.