Checklist are not an efficient tool to choose between “Waterfall” or “Agile”
I’ll start to say that this question is one of the most fundamental one when approaching Agile and every organization typically has its own interpretation on it. But here’s mine:
The Stacey Complexity Matrix
The most frequent answer to “When should we use Waterfall or be Agile?” is almost always revolving around a version of the Stacey Matrix, like the one directly below:
Which reads like the two following questions:
Do you know what to do? (Requirement axis)
Do you know how to do it? (Technology axis)
If you can answer both question by ‘yes’, then you are really lucky and there is no real necessity to use Agile methods. It is also more likely that you could perform the work without using any management methods at all — you’d just need to do it!
If you are more or less sure of what to do and of how to do it, then you are in a complicated space which could be managed in a project with a waterfall management method. You could as well use something different and try Kanban or Scrum, depending on how you want to optimize your system — but you will definitely need something.
As soon as uncertainty is getting higher on the requirement side, risks on scope, time and budget are getting exponentially higher and higher. At this point, it is highly beneficial to fix one of these three constraints to reduce the overall complexity of your system and to simply be able to manage your development. As a rule of thumb, it is often easier to get rid of the time constraint by using time-boxing techniques such as Sprints — but something else could work for you.
Once you reach the Anarchy and Chaos scape, then you are screwed. You know absolutely nothing and you should stop all activities on the development immediately. It might not look that way on a daily basis but in Anarchy, the risk that you deliver a dysfunctional product, late and over-budget is getting really close to 100%. So, step back, take a deep breath, review your reality and question everything you do and why.
If you made it so far, then you should now be able to make the best possible choice on how to manage your development efforts … and you are ready to go one step deeper.
Being Human as the biggest issue
Big developments are often complex endeavors done by big teams, and as soon as you are dealing with people, nothing is black or white anymore. Having this in mind, a more realistic way to phrase the two questions on the Stacey Matrix would be to put a bigger emphasis on the human side of it:
How confident are you that you know what to do?
How confident are you that you know how to do it?
It is indeed very important to understand that we try to appreciate our feelings about a risk/cause relationship and that human-beings are terrible at doing so in an accurate and reliable manner. That’s why poker is a game for much of us, we have an access our chances of winning based on the current situation and we get it wrong most of the time, making the game exciting to play.
Do not worry though, some people are actually better at this that others, and you are clearly part of this group. That’s why you are in position to make decision for your organization, right? (Spoilers) No, we’re not … every one of us would burn a tremendous amount of cash playing poker at the casino.
So, what can we do about it, what are the next logical steps?
The Checklist Mirage
The normal temptation would be to remove the emotional part from the equation by defining a hard criteria-based checklist; but it should also be clear to you that each organization will need to define a specific checklist covering its context but also the bias that are driving its members.
It has now been proven that even Software or AI are carrying the cognitive or cultural bias of their creators. So, it is safe to assume that the same applies to any human written artefacts such as checklists or LinkedIn articles.
Checklist are carrying the bias of an organization and can’t/shouldn’t be reused.
Clearly, an organization that is biased toward innovation will create a checklist that will minimize the impact of risks or uncertainties — which will lead to a lot of challenging developments being run as super safe waterfall projects (and vice-versa a lot of classical projects might be rolled using Scrum or Fake Agile, and might end up in a very bad place).
Checklist are useful in a lot of cases, but in my opinion are absolutely useless when you are dealing about people or about changing context. Hard based criterion is quickly becoming irrelevant in the face of an ever-evolving world and you can get a glimpse at this when dealing with Management by Objectives. Objectives set in January are often obsolete by June and totally irrelevant in November, making this tool a sub-optimal way to involve and motivate employees.
Human Interactions over Tools and Processes
The best way to take an informed decision on how to run a new development effort is to reduce its complexity and to do so in a comprehensive way. Luckily, this is something that human beings are doing surprisingly well: Breaking down complex developments into simpler tasks was the basis on the industrial revolution — lead notably by Taylor and Ford — and it is still the basis of any good Project Management.
Breaking down complex developments into simpler tasks is the basis for more accurate estimations.
Try to do this when assessing what you think you know: it is hard to assess a big development effort involving hundreds of people over several years, but it is way easier to assess the requirement and technological complexity of just one functionality or a set of functionalities. It sounds familiar with how estimation is done in Scrum, and this is no accident, as estimations are at the heart of how Scrum is managed. It should be a source of inspiration when looking for moderation or estimation techniques.
But by breaking down the problem into small simpler parts — you haven’t reduced the impact of your own bias. Hopefully, there’s an easy solution to remove one-person own bias and that is to involve more people in the assessing or decision process. Bias are heavily dependent of the direct environment so make sure to involve a diverse group of people representing several parts on your organization.
Involving as many people as meaningful in your estimation process is an efficient way to reduce the impact is bias.
Finally, be afraid of people that think you are right — they are more likely biased toward you!
TL; DR
Agile is the goal of reducing the cost of changes in an organization, which makes its methods useful in complex environment. In more certain context, traditional methods are more likely to be successful and in full anarchy, nothing will ever save you.
Assessing the complexity of your environment can be done with the Stacy Matrix and by answering the two following questions:
- How confident are you that you know what to do? (Requirement axis)
- How confident are you that you know how to do it? (Technology axis)
The answers you will get to these questions are more likely incomplete and inaccurate and are highly subject to cognitive and social bias. To tackle this issue, a bit temptation is to use a hard-facts based checklist — but it is often an unsuccessful attempt as the complexity and the bias are still carried through.
The best way forward is to break down your environment is easier to grasp parts and to involve a diverse and representative group of people in the estimation process.
Here’s some ideas and tricks to drive your estimation process: Agile or Waterfall? 8 Tips to Help You Decide.
