Scrumfall: The Fall of Scrum

The Origin of Scrum

In his book Scrum: The Art of Doing Twice the Work in Half the Time, Jeff Sutherland introduces us to the idea and origins of Scrum. He brings us to a time when he was serving as a pilot in the air force during the Vietnam war. They had a clear directive - OODA: observe, orient, decide and act. It is a four-step approach to decision-making that focuses on filtering available information, putting it in context, and quickly making the most appropriate decision while also understanding that changes can be made as more data becomes available. The only way this could be done was through empowered individuals that followed these core values, later translated as the pillars of Scrum: Transparency, Inspection, and Adaptation.

Drawing from this experience and inspired by the development of the first Roomba robot, he put the first Scrum team in action. How was this team similar to the vacuum cleaner we use today? Well, the Roomba is blind. It starts in a direction opposite of its base and drives until it hits an impediment it cannot cross. Then it inspects its surroundings by slightly changing direction and trying to move that way slowly; if the way is clear, it starts to increase velocity until it hits an obstacle again. But, it also remembers where it has already been and records how far from the first obstacle it traveled. This way, it knows where the barriers to its path are relative to the base and the distance-direction traveled. It slows down before touching them the next time to reorient and drive in a different direction.

Ok, so this is Roomba Scrum, what we have been doing all along, right? - you might ask. Sadly, the answer for some (or rather most) of us is no.

Paradox: What have we been doing?

The tendency of nature is to take its most stable state; the tendency of men is to take their most secure one. This is all so evident that many anti-patterns have emerged to capture it; to name a few, “Information Silo”, “Mushroom Management”, “Peter Principle” and so on. This state is completely at odds with the value of empowered individuals, the driving force of Scrum. So what happens here is that these hierarchical structures transform the flow of Scrum flow into the fall of Scrum, a Water-Scrum-Fall scandal.

What is it, and how did we come to it?

I started my management career in mechanical engineering, where we did standard waterfall planning, with Gantt charts, budgets and resource allocations, delivery timetables, and a lot of promises and wishful thinking/gambling, creating beautiful charts and graphs that were never true but as the CEO once said, “Pictures for Directors” or we can use the abbreviation PRD (pun intended). 

One day, my line manager came to me and said: ”Where is your sprint backlog?” You see, he was inspired by the IT department in the company doing Scrum and delivering twice the value for half the time. I had no idea what log he was talking about. So he enrolled me in a Scrum course where I got my Professional Scrum Master certificate - I still had no clue what Scrum is, but … oh well, I was a Scrum Master now. (emphasis intentional!) 

The birth of the Water-Scrum-Fall framework wrapper

So the natural next step was to bring the rest of the team up to speed, to implement what I’ve learned about iterations and reviews, change direction to bring the most value, and inspect and adapt the process. The problem was, that we were already found in a mid-project execution, so the scope, the delivery plan, budget, and resources were already defined (and approved! - what we did wrong is a story for another time). What we started doing was Scrum inside a Waterfall project, at least for the “development” phase. It looked something like this:

So we decided on 3-week iterations, finishing with a demo, to collect feedback from SMEs, to act quickly on that feedback, and improve the design to reach a satisfactory state of the product that we pitched to the board of innovations, awaiting approval for manufacturing (The “Steins” Gate).

But this was mechanical engineering, and we were developing hardware, so it was possible to work like this. We had to plan upfront, to have a conceptual design that needed to be evaluated by a third vendor that will manufacture it. If it was even possible to create it as we envisioned, give an estimated cost, manufacturing and delivery time, as well as consult with other third-party vendors that supplied equipment that later had to be integrated with the main construction.

Using this method, we developed a “test” machine that had to be put in operation first to measure certain signals that will dictate the looks and performances of the final design. We developed a prototype of the final design as well, but one that could have been easily modified and adapted if needed after learning a thing or two from the “test” unit. This is in a broad sense, in the spirit of Agile, but put in hardware. Software is another story.

Where things went haywire

One interesting thing to mention here is the reality of the “Second-system effect”, a term coined by Fred Brooks, saying that there is a tendency for small, elegant, and successful systems to be succeeded by over-engineered, bloated systems due to inflated expectations and overconfidence.

Jeff Sutherland says throughout his book that it is not the people’s fault, rather, it's the system’s fault or us allowing the systems to guide us, and not the other way around. This has been proven right time and again. Seeing that the “Scrum-fall” process (and it is a process, not a framework like Scrum) works for a specific scenario doesn’t mean it is good, and it can work as a generic solution. I’ve seen this process camouflaged in statements containing wordings such as “pure Scrum” and alike in IT departments on several occasions.

This is how “pure Scrum” works:

• The “Top Management” people have an idea that is put into a “Requirements” document
• There is an R&D team that develops that idea, specifying it to its finest details, providing mockups, wireframes, and solution proposals
• The idea is presented to IT  representatives (Solution Architects and Product Managers)
• After some back and forth, the idea is refined and accepted, and it moves into the “Design” phase
• The UI/UX team produces detailed designs while the Product Managers and the Architects craft the stories:
• The development team, working in Scrum!, follows step-by-step instructions called Stories and Tasks and delivers the requirements in successive order
• There isn’t a review or a demo session. It is not needed since it is already signed off, and stakeholders are too busy producing other ideas and design documents
• The PM team produces “Deployment reports” informing the users that there is a new feature, where it can be found, and how it can be used. It doesn’t matter if they want it, need it, like it, or have some concerns or constructive feedback
• Well, if some agile proponent pushes, concerns are documented, placed into the backlog, and left there to rot before they become or are deemed obsolete (by someone up the ladder) and are removed completely

When I first saw this, you can safely guess it was a shock. This is not Scrum, this is not even Agile, this is “pure Waterfall” or an unsuccessful try at Scrum-fall. It was brutal and completely demotivating to the development team, but when the concern was raised, the reply was, “This is how it has always been done”, of course. When even a small deviation from the process was tried or a small move closer to actual Scrum, all hell broke loose, with comments like “You are not working as Agile as before”. Oh well…

What we need to be wary of!

Scrummerfall. n. The practice of combining Scrum and Waterfall so as to ensure failure at a much faster rate than you had with Waterfall alone.

Sometimes failing fast is a good thing, it yields good results, and it gives an insight into what and how much we are wrong. But we need to track its signals, measure them, analyze it and act on it (again, the Observe, Orient, Decide, and Act). Only when we are empowered to guide the system in the direction where it is useful for us and to voice our concerns when it is destructive can we make a change for the better. 

Empowering is not a one-off thing. It is a constant process that extends from the individual to the team, from the manager to the implementer. As we go back to Sutherland's wartime story and draw the analogy a bit further, a pilot never flies solo; even fighter jets fly in formation, not to mention the complexity of doing a reconnaissance mission or flying into enemy territory with a squadron. Knowing the history of many IT projects, and that trend continues even nowadays, their domain usually falls in the complex or chaotic quadrant of the Cynefin chart. And this is where true Scrum shines. Understand your domain, accept your position, make a stand in your chain of command and change the organization’s mindset.

We cannot see that we are failing because it is not transparent or because we are complacent - that’s how things are done here. And it is not transparent because the hierarchy of influence hides it in ever-increasing information silos, securing and strengthening people’s positions and importance in the company, like a virus that forces its host to destroy itself from the inside out.

This is the deadliest poison to the agile mindset. We need to create a system, a structure, and a process that will work towards bringing the highest value for the customer, liberated from gates and sign-offs, change requests, and approvals, that will only bring value to the disruptors and the executioners of agile, for the fall of Scrum.

About the author

Borjan Petreski is a Service Delivery Manager working in the engineering hub in Skopje.

Borjan is a versatile Service Delivery Manager and Scrum Master who has experience working within different agile frameworks, such as Scrum, Kanban, or "Scrumfall." Borjan managed multiple projects and products simultaneously with varying stakeholders and SMEs from various fields.