How to destroy Scrum? And How to save the essence of Scrum?

I have seen many companies that have just turned Scrum into a task management tool or scrum-waterfall. In this short story, I will explain the essence of Scrum and what we should consider for using it.

Let’s assume you live in a big and busy city like London or New York, and Unlike other days, today you’ve decided to commute to work by car. So the first thing for me is that open a navigation app like Waze: Select my destination, and Waze will generate a plan for my journey.
So I have a plan, the best route to my destination, based on recent accidents, traffic jams, speed traps, construction, and other obstacles that could slow me down. Waze’s estimation for this journey is 45 minutes.

Let’s go by this plan, but I will turn my phone’s internet off to be more efficient in cost saving. Finally, after 76 minutes, I arrived at my workplace. Wow, “Waze is a rubbish app; I need to find a new one with better prediction and planning.”

What is wrong with this story? Is Waze a rubbish app? Waze uses real-time data from the app’s users to provide the best route to the user’s destination, taking into account accidents, traffic jams, speed traps, construction, and other obstacles that could slow down a driver. But why did it not work for me?

It wasn’t about the game itself, it was about the playing field or rather the context of the game.

To simplify, There are two types of games: 1- Complicated and Complex. In complicated games, like a construction project, you need a significant upfront planning phase to create an accurate and detailed plan, and after that, you can start the implementation phase and follow the plan because your plan is reliable; this way of working is called waterfall or planned based project management.

But for Complex games, like software development projects or something like traffic, you need to get real-time feedback from the game field during the whole game and not just during the planning phase, Because the game field’s situation is not stable, and your plan needs to be adjusted based on new changes, like a new accident …

Waterfall or any traditional project management is valuable. Right now, agile is a trend; you should choose your planning and management practice based on your game field and context.

In my story with Waze, I turned off my phone’s internet; How was it possible for Waze to get real-time data on new accidents, traffic jams, … or any new incidents. The Initial plan of Waze was based on data of that time, not new data.

The traffic system is a complex problem, So we need to play in this field with complex systems rules; for a complex system, you need a short feedback cycle because there is always a bunch of newly discovered data that needs to take into account for adjusting our plan.

The number 1 rule for complex systems is, that our goal is not to follow a plan, we need to respond to change in order to reach desired outcomes. For example, Waze’s goal is to provide the best route to the user’s destination, but the initial route can be adjusted several times during a journey based on new data and changing situations of the live traffic.

So, If I keep my phone’s internet on during my journey, Waze would be able to get real-time data from the community(We call it Inspection capability); with the new data, Waze would be able to adjust the initial route to make it again the best route(We call it Adaptation capability) And finally, Waze will let me know, that the plan has been changed and will make it fully visible for me as its stakeholder(We call it Transparency capability), Also Waze, leaving the decision to change the route to the user too. In other words, if we are on the road and it detects a retention zone or slow traffic, Waze warns the driver and offers an alternative route, but the user must decide.

So, Scrum is like a Waze for Complex problems. In this context, it‘s impossible to predict everything upfront, and you will discover new things during your journey, and the game field is not stable too. Therefore, Scrum is based on three pillars: Inspection, Adaptation, and Transparency.

Scrum’s artefacts, like product backlog or sprint backlog, are a tool for maximizing transparency; what is going on in the game? What is the next important thing? What is the priority now? What has been done? The transparency will make it possible to find an opportunity to communicate about changes and how to adapt the plan.

Scrum events like sprint planning, daily Scrum, sprint review, and sprint retrospective are a chance to get together and do an inspection and adaptation on scrum artefacts like product backlog. For example, On a Daily Scrum, they inspect the sprint backlog and adjust it based on the team’s progress or any other unplanned stuff.

And Scrum Roles are responsible for inspecting and adapting and making the result transparent for stakeholders.

The final point is that Scrum is a simple framework designed for complex problems, but you can easily destroy the main capability of Scrumcrum to inspect and adapt (Like Waze, turn the phone’s internet off).

Best Regards
Asad