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.Â