Exploring Scrum's Horizons: Expanding Possibilities in Regulated Industries
Commander Jon Haase's Extraordinary Journey featured in The Scrum Fieldbook
At Scrum Inc., the boundaries of Scrum and Agile principles extend far beyond IT and software development. In this excerpt from "The Scrum Fieldbook: Faster Performance, Better Results. Starting Now.," author JJ Sutherland in consultation with Dr. Jeff Sutherland, co-creator of Scrum, addresses the skepticism that often arises when considering the adoption of Scrum and Agile in complex, regulated environments, like the government and military sectors.
We’ve heard it over and over again. “It can’t work here” comes from many in structured, hierarchical industries. However, through the lens of U.S. Navy Commander Jon Haase’s experience, we’ll uncover below how Scrum defies these assumptions and demonstrates the efficacy and effectiveness in even the most demanding, high-stake environments.
"It Can’t Work Here" - An Excerpt from The Scrum Fieldbook
The following excerpt is from The Scrum Fieldbook: Faster Performance, Better Results. Starting Now. by JJ Sutherland, CEO of Scrum Inc.
There’s a common refrain I hear from Scrum skeptics; it can’t work here. What we do is too complex. Too unpredictable. Too difficult for a system that gives autonomy to teams. For some reason I can’t quite fathom why they think traditional project management actually can handle their special snowflake of a project, but they believe it fervently. Or they say that it may be fine for software, but in their super-complex domain that is so much more difficult than software it just can’t apply.
I teach classes open to the public fairly often. And what is incredible is just the sheer range of people who come. They range from bankers, manufacturers, publishers, and those who make biopharmaceuticals to researchers, service providers, educators, and non-profit workers. The students almost always represent an amazing diversity of industries, expertise and roles.
But if you are one of those skeptics, I want to share the experience of one person with you that has implemented Scrum in a domain that most likely is higher stakes, faster moving, and with far less room for error than what you are trying to accomplish. Probably.
U.S. Navy Commander Jon Haase called me up a couple of years ago. He had recently taken command of an alphabet soup of a unit EODMU2 (Explosive Ordnance Disposal Mobile Unit 2). He wanted to implement Scrum in his unit and called me up for advice. He wanted to go faster, with higher quality in one of the most demanding environments on the planet.
Explosive Ordnance Disposal are the smallest of the US Special Forces. Couple thousand people. But they have to be able to deploy with any of the other units anywhere on the planet in any environment. They deal with the bombs. They’re tasked with destroying, rendering inert, anything that can go boom. From mines and shells to the improvised explosive devices like the
roadside bombs made infamous in places like Iraq. They work on land and underwater. And can even render safe the world’s most deadly weapons, those loaded with nuclear, chemical or biological payloads. They do other things too but just what is classified.
And Jon decided to run his command, one of the most demanding in the military, with Scrum. Given the nature of his work, interviews with someone like Jon are rare. Still, I sent him a list of 12 questions about Scrum and his work. He was cleared to answer nine of them over email. I don’t want to put words into his mouth, so I’ll share with you the email I received from him.
His response begins with this disclaimer: The views provided are those of the author and do not necessarily represent the views of Navy Expeditionary Combat Command, the Department of the Navy, the Department of Defense, or the United States Government.
Q - When did you first hear about Scrum?
I first heard about Scrum when I was preparing for my command tour. I was reaching out to mentors and assembling a reading list which covered many topics from leadership and management to communication and emotional intelligence. It was through this process that I found Scrum. When I saw it, I committed to learning more by reading ‘Scrum: The Art of Doing Twice the Work in Half the Time’. This was approximately 2 years ago and began my journey learning about Agility and the Scrum framework.
Q - What inspired you to implement Scrum at EOD?
Instead of making decisions we try experiments whenever possible. These experiments have some necessary conditions to be implemented. The first is that the cost must be low and the risk must be very low. These experiments must also be temporary in nature and reversible if the
experiment proves unsuccessful. Finally, there must be some metric that we can monitor to see if the experiment had the intended outcome.
Implementing Scrum met all of these requirements.
It took no money to start the experiment, there was low risk to implementing Scrum, it was temporary and could be easily reversed if it was unsuccessful, and it had metrics such as velocity included to evaluate its effectiveness. By measuring productivity from week to week, weekly productivity can be tracked and is known as Team Velocity.
Q - How was it structured? How did you set it up?
We structured our Scrum implementation to be consistent with the Scrum framework roles, activities, and artifacts. The Scrum Master was the Executive Officer, the Product Owner was the Commanding Officer, and the Scrum Team was the remainder of key staff positions. The composition of the group changed over time as we refined our understanding of what products and services each member of the command supported.
Q - What was the impact immediately?
Team Velocity started at four points per day and steadily grew to 50 points per day. The immediate impact was to improve communications, prioritization, and task accomplishment.
Q - What were the elements that had the most impact? Why?
The elements that had the most impact were defining the objectives and agenda for all of the activities. While many of the activities mirrored actions that are customary and military life, they lacked the objectives and agenda clarity that they gained with our Scrum implementation.
Timeboxing also became an essential part of our daily life.
The reason that Timeboxing and understanding the objectives of every event became so vital to us is we could measure our effectiveness against common, understood, thoughtful
objectives each time the team met. This allowed us to be more focused and this focus allowed us to achieve more meaningful work.
Q - Can you give an example of something you were able to do with Scrum that you weren't before?
As a leader, I am much more attuned to the effects my actions have on the team. By conducting rigorous Retrospectives, I know how my actions impact team happiness.
As an example, I pushed the team during one Sprint to accomplish a specific objective that was out of line with some of our priorities heading into that Sprint. At the Retrospective, I asked the team for their input and got honest feedback on how my actions had caused a steep drop in team happiness. Without Scrum, the team never would've had a mechanism to deliver that feedback to me, and I would never have known the results of my actions.
Q - What was hard? Did you have to modify anything?
It was hard to convince the team that we needed to conduct all events in the Sprint. While there was broad acceptance of the Daily Scrum, people felt that we were spending a lot of time in meetings by doing Backlog Refinement and Retrospectives, which wasn't always appreciated. Gradually, as the Team began to understand the impact of things like having a clean and ready backlog or soliciting team happiness and continuous improvement suggestions at Retrospectives, the team gained more approval and acceptance of these events.
Q - Run through your Sprint...how and where did you do each event?
The Sprint starts Monday morning when we meet with all of our platoons for our weekly synchronization meeting. This allows us to solicit feedback from all of the teams operating within the command.
From there, we go into Sprint Planning where we can take the input we just received and incorporated into our Sprint plan. When the Sprint plan is complete, we moved into Daily Scrum and discuss how will begin our work. This is all done in our conference room.
We then have Daily Scrum in that same conference room using our team board which is available to anyone in the command to see. On Wednesday afternoon we meet to conduct Backlog Refinement in front of our team board. Backlog Refinement involves discussing and prioritizing work to be done. On Friday we have an all-hands call with our sailors to present to them the work we've accomplished. This is our Sprint Review. Friday afternoon will gather the Team for our Retrospective in front of the team board.
Q - Will it last after you move on?
The futures impossible to know, but the groundwork is in place, and infrastructure exists for Scrum to outlive my tenure.
Now, think back on what you just read. Take out the occasional mention of rank and sailors and focus on the key points. This is not a military example, it’s an example of Scrum working in a complex, difficult and unpredictable environment.
Commander Haase and his team were always highly skilled and motivated. As Special Forces they are the best of the best almost by default. Yet, after implementing Scrum, Haase and his team saw productivity improve from four to 50 points a day in 18 months. That’s an increase of 1250 percent.
And though the work they do can be high-tech, this is not the story of a software startup, or even a Team that is creating a product. In a way they are a services company with a highly specialized, dangerous, and lethal delivery. Since working with Jon there have been a steady stream of Navy Special Warfare folk coming through my classes. And these are people who,
above all, focus on results. There is zero tolerance for anything that doesn’t make them faster and more effective.
As a former journalist I know skepticism can be healthy. But it must be balanced with acceptance of proof. If not then skepticism can be counterproductive, even destructive. Especially when skepticism is just a disguise for simple fear of change.
Defying the Odds in Regulated Industries
Commander Haase's story serves as a testament to the adaptability and effectiveness of Scrum and Agile methodologies in regulated industries. It's not just about software development or startups; it's about fundamentally transforming how teams work, even in the most complex and demanding settings. The results are undeniable: a 1250 percent boost in productivity in 18 months. As skepticism meets the reality of positive change, we're reminded that questioning is healthy, but embracing evidence-based transformation can lead to unprecedented success. So, let this account of Scrum in action in the most challenging of environments inspire your belief in its potential, even in the face of "It can't work here" skeptics.
English 
French 
Spanish