Successful projects have one thing in common: they are examples of downhill triangles. But what is a downhill triangle? To understand that properly, we first define the opposite, which is an uphill triangle.
Every project has the dimensions time and fuzz. By fuzz we mean:
If you draw a diagram with "time" as the X-axis and amount of “fuzz” as the Y-axis, projects with an uphill triangle tend to look like this:
You often see crisis situations at the end of uphill triangle projects. For example, large meetings where everyone is called together to get the project right or people saying “How is it possible that we are only noticing this now?”
A typical reaction is to add extra people. However - aligned with Brooks's law - this usually makes the situation even worse.
Uphill triangles have a very negative influence on both the quality of the delivered product and the satisfaction of the team.
However, you have a choice and an alternative, which is to manage projects into downhill triangles.
The downhill triangle is the opposite of an uphill triangle, and preferred by Wieni. The entire team and stakeholders make a commitment to cause as much fuzz as possible as early as possible.
This does not mean you have to set the scope of your project in stone at the start. On the contrary. You focus on the broad horizon of your project at the start, and gradually refine it towards the end.
The downhill triangle is all about clarifying shared objectives early in the process. Eliminate risk as fast as possible. Validate assumptions about value at the start. What is valuable to the user? What is the most technically efficient and effective way to deal with this?
By doing this, you evolve from a push to a pull way of working. You don't wait for issues to come to you, but as a team, you proactively look for potential threats to the project.
When you apply this philosophy, everything changes. Projects are delivered on time (or even too early) and with quality. With hardly any adjustments after launch and almost no bugs. And more importantly, without fuzz. It even feels a bit awkward, because you no longer have the adrenaline rushing throughout the lifespan of your project - a property of a downhill triangle.
How do you approach projects in such a way that an uphill triangle becomes a downhill triangle? How do you tilt the triangle?
It is no coincidence that agile practices are popular for software development. They contain practices that facilitate downhill triangles. The focus on transparency, iterative work, user stories, sprints, ... are all practices that - when applied the right way - cause fuzz from the start.