Scrum is poorly understood today. Large companies have adopted only some of it, and when this is pointed out, people from all levels of the organization will protest that being agile is about being flexible. “It’s agile, so we can do whatever we want.” That’s not what being agile means, and that’s not how Scrum was intended to work.
Other objections include:
- “That won’t work here.”
- “That isn’t how we did it at the other places I worked.”
- “What we are doing now is working fine.”
All of these statements miss the point of adopting new practices in order to change the status quo and get results.
What is Agile?
Agile is not something you do. The Scrum framework is a set of rules for a product development team to follow. The purpose of Scrum is to help the team become agile. There is no “agile” that you can do. Rather, it is something that you become. When an organization can be described as agile, it means they make their highest priority the frequent delivery of working software to satisfy the customer. In other words, agility is having a low Time to Market (TTM). The TTM of any value stream is the measure of your agility.
To answer the question,
“How agile are we?”
respond with the number of days that it takes for their to be an idea and for something, any part of it that works, whether or not it is release quality, to get into the hands of a customer and receive their feedback. If that time is months, I would not consider that agile. If that time is a few weeks, that sounds more agile to me.
Adopt Scrum to Create Agility
“We need to look at the way we do Agile/Scrum…
There is no such thing as Agile/Scrum. Agile is an adjective describing how many days stand between you having an idea and getting it into the hands of a customer. Scrum is a rules pamphlet that you can follow to help you change your organization to become more agile. Therefore, the purpose for adopting Scrum is to create agility to improve delivery. Many of Scrum’s rules exist to help simplify becoming agile for people who don’t know what to focus on or where to start.
Scrum intentionally creates friction within an organization between what the Scrum team is trying to do and what the organization demands of the team. Scrum exposes the things the organization does and the ways that it works so that you can change them so that agility is not impeded by your traditions and habits you have, over years, adopted as immutable rules to follow.
Customizing Scrum
Some think you can pick and choose which rules of Scrum to ignore. I agree. There are a few places where you can make tweaks and it may not result in much loss. Especially if you already work in a lean organization where lean thinking drives everything that you do. But Scrum, for the most part, is deployed in large companies where lean thinking is the opposite of almost everything that they do.
In such organizations, which rules can you ignore and still improve delivery and create agility? Since each element of Scrum is intended to create agility and challenge the status quo of a non-lean organization, which ones can you ditch and still get results? And, what are you measuring A/B before and after your customizations to see if things improved or became worse?
It’s a pretty bold claim to say,
We can do whatever we want and be agile.
I don’t believe that is true. Do you? Do you think that you can get a desired business result by doing random things that you prefer to do? Or do you believe that you have to do things with purpose and intent to get desired outcomes? I’m going to assume that the people saying this are not being held accountable to deliver improvements to delivery which can be objectively measured.
Agility does not mean everyone has to be flexible and accept that all things will lead to the same good results. That would just result in covering up a problem to protect the status quo or trying something that any reasonable individual would easily identify as not leading to good outcomes.
Agility is measurable. You can count the number of days it takes for an idea to traverse a value stream and generate feedback. The flexibility comes from self-managing teams not having single points of failure. The flexibility is management allowing teams to operate themselves differently from one another. The flexibility comes from the team delivering in short bursts that allow for feedback to drive new short plans and inspect and adapt rapidly.
“Flexible” does not mean that the Scrum Master has to allow the organization to keep doing the same thing day after day hoping for an improved result. That’s the definition of insanity.
Left Out of Scrum
My observation is that most people don’t know why Scrum has the rules it does, and they hate following rules they don’t understand.
I’m not saying you can’t leave things out of your Scrum practice and improve.
I just don’t believe most people know enough about why the elements of Scrum exist to make wise decisions when picking and choosing. Most adaptations seem intended to conform to the status quo and cover up its problems instead of creating transparency and friction so improvements can be made.
Usually the rules that are ignored the most are: self-management, cross-functionality, empiricism, lean thinking, and the product owner’s authority over the product. The result? Zombie Scrum.
That said I have seen some rare instances where teams came up with new and better ways of working that did not create Zombie Scrum but actually created even more transparency and improved inspect and adapt possibilities. The first teams to throw out the three questions and adopt item aging are a great example.
What about you? How confident are you that the Scrum you are doing is better than not bothering at all? Has it resulted in improvement? What improved? How do you know?
Or did you layer 4 meetings on top of your waterfall?
Warning: Customization often covers up problems
So, go ahead and customize Scrum. But make sure your TTM is improving. If you cannot show objective measures of improvement, then it’s not an improvement. If you are leaving things out of Scrum because “that won’t work here,” I think you may have missed the whole point.
