When you start to use Scrum (or any other Agile framework), it will suck. So you try to fix it. Your mindset will define which way you will go – either back to Waterfall or to actual Agile.

To understand what I mean, please imagine a project that seeks to deliver a customer a system they request for. At the end of the project, we find out that the customer doesn’t like the outcome, despite the fact that it matches their original request. 

Why did that happen?

Our brain seeks to understand why things happen around us they way they do. These explanations, for the scenario above, tend to fall into two primary beliefs for the cause:

1. We didn’t do good enough a job in defining the requirements up front, so we naturally built the wrong thing since, well, we built the wrong thing, as planned.
2. We did not show the results early enough for people to detect the difference between “want” and “need”, so we were exposed to actual requirements too late.

The first one we might call “predictable mindset” (or “waterfall mindset”). It is founded on the belief that the most optimal way to build something is to find out all the requirements up front, then plan the optimal way to solve the problem, and finally deliver it according to the plan. In this mindset, when things go wrong, it is because we didn’t do some earlier steps well enough, and the processes are fixed by doing (and spending more time on) the early steps better next time.

The second one we might call “emergent mindset” (or “Agile mindset”). That mindset is founded on a belief that people suck* at defining requirements up front for anything more complicated than a simple physical thing (and there’s a really hilarious video about defining requirements for sandwich) and that the most effective way to detect what people really want is by showing them something and then listening what they say when they try to use it. Obviously, a person with this mindset will think first, to establish what to build as a first iteration, but they never trust the input completely. 

You can “listen” to your own mindset by retrospecting what was your initial reaction or interpretation to the scenario, or when things go wrong in real life. Which response was stronger? Sometimes you trigger both, but probably one tends to dominate in most circumstances.

[* An Agilist would never blame anyone for that, though, since they recognise they themselves are just as bad at defining requirements.]

How does this belief affect our use of Agile frameworks?

Let’s imagine another scenario. Let’s say we try to use Scrum for the first time. Unsurprisingly, we will discover many things that do not work fine. The new process feels awkward and in many places it doesn’t live up to our expectations**. Thus, we need to change our ways of working in some way in an effort to try to fix [our use of] Scrum. 

[** Scrum has never promised to fix our problems; only that it will show all our problems to us. It’s up to us to fix our problems.]

If the predictable mindset is strong in us, then the way we fix our problems is by trying to improve the inputs into our process. We will add preliminary steps and effort. We will try to do the up-front planning better, in the hopes of delivering a righter product in a righter way. Multiply this a hundred times, for all the problems that we discovered, and what do we get?

We’re back to waterfall. In our efforts to fix our Scrum, we rebuilt the up-front planning, try-to-do-everything-right-the-first-time process. Every step of the way we tried to improve things, yet we got back to where we tried to get away from. 

If the emergent mindset is stronger, then the way we fix our problems is by introducing intermediate points where we expose our work to our users and customers, and seek their feedback on the things we’ve completed so far. In order to do this, we need to build less at a time, and make it work so that it can be used in some way. It will also force us to discover techniques that allow us to design, code, test, and deploy in smaller steps. Multiply _this_ a hundred times, and what do we get?

The process we end up with may not be Scrum, but it will be very effective at discovering every possible assumption we might have and aggressively testing it on our users. The process will find ways to very rapidly deploy very small pieces of functionality, and also modify anything we have done in the past without excessive costs. 

As a classic Agile quote says, we learn to “turn on a dime, for a dime”, or any other suitably small coin.

And that’s what Agile techniques are all about – enabling us to inflict change on our product without killing ourselves doing it. 

It doesn’t really matter which framework you start with

My favourite is Scrum, but I like Kanban almost as much. Lean Startup is awesome, too. I like SAFe less, and LeSS more. But never mind, the selected framework is not really relevant. What is relevant is how you modify it, or how you modify your organisation, as you learn the challenges the selected framework reveals to you. 

The way you interpret causality, and consequently how you try to fix the system, define whether you can be Agile or not***. That mindset defines where the road will take you, regardless of where you started from. It is impossible to make Scrum or Kanban work if your improvements re-establish up-front effort as the standard solution to problems. 

[*** Assuming you want to solve complex problems using Scrum and Agile]

So is predictable mindset just wrong?

No. There are many systems, mostly mechanical, where the causality is in fact predictable and where the right approach to fix processes is to increase (or improve the quality of) up-front planning. Most of engineering is in that camp. Also a lot of manufacturing and logistics is there. Waterfall is the archetypal framework to developing those predictable systems. Our very advanced technologies and capabilities are a testament to the value of the mindset, and its application there.

The problem lies in using the same mindset in systems that do not have predictable causality. We need the emergent mindset to explain how to deliver value and improve processes in social systems. And even in engineering, the research and planning of how to be able to do something is a human system and thus “Scrummifiable”, though not in exactly the same way as in software.

So I do not wish to remove the predictable mindset from engineering, only to highlight that a single mindset is not sufficient to understand our reality and be effective in unpredictable systems.