Most organizations don’t get the potential benefits of Scrum. In fact, I would guess that out of all the people who have come through my Certified ScrumMaster or Certified Scrum Product Owner classes, fewer than 5% have gone back to their organizations and seen the 4 to 10 times growth in productivity that Scrum can enable.

Why?

Pragmatism – Arrogance and Defeatism

Pragmatism as applied to Scrum is the approach of taking only the “good things that are possible for us” from Scrum and using those in a team or an organization. This might mean doing the Daily Scrum meeting, but giving up on many of the obstacles raised there because they are too hard to overcome. Another common example of this is creating a team of technical people who contribute time to the Scrum Team and possibly to other priorities instead of the idea of creating truly cross-functional teams with all members fully committed to the Scrum Team.

This pragmatism often results in some benefits: better communication among team members, shorter feedback loops with users and customers with the team, or a stronger focus on business value for the scope being worked on by the team. It might amount, in practical terms, to a 15-25% productivity improvement.

But, really, it sucks, and it’s not Scrum.

For teams and organizations that are new to it (three years or less), this is like an individual going to a dojo to learn Karate and, after the first session, telling the Sensei, “hey, this was really interesting but I can’t stretch that way so I’m going to do the kick differently – don’t worry, it’s better than what I did before – let’s move on to other things that I can do!”. In other words, it’s arrogant and defeatist. Regrettably, a lot of arrogance and defeatism goes by the much more palatable label of pragmatism.

You can’t make up what you want to do and call it “Scrum”. Scrum has a definition (which has changed somewhat over time) and if you do something different from the definition, please call it something different.

But please, don’t mistake my comments for a call to…

Fundamentalism – Inoculation Against Scrum

It’s less common, but some people go here. They learn Scrum the one true way and decide that come hell or high water, they will make their team do it that way! Scrum this way is rigid and cultish. Nevertheless, done this way, Scrum can still have some (temporary) benefits, similar to the pragmatic approach. The challenge here is that it’s not usually sustainable and the people who participate in this type of Scrum are often “immunized” against it. They’ve had a bad emotional experience with Scrum due to the inflexible, intolerant approach to implementing it. Justifiably, those people don’t want to repeat the negative experience and so they actively avoid Scrum or even bash Scrum publicly.

It really is a process very much like how our antibodies work in human health: we are exposed to a microbial disease which itself may temporarily succeed in propagating in our body, even long enough to get us to infect someone else. But after our immune system fights it off, we are ready for the next attack, will recognize it and repulse it far more quickly so that it can’t spread. Trying to spread Scrum by doing it as an invasive take-over of an organization is very likely to cause the same sort of reaction among the people in the organization. And anyone who comes along a little while later, even with a much more appropriate way of doing Scrum will likely be quickly rejected by the long cultural memory of the Scrum antibodies!

So where does that leave us? There really is only one option for doing Scrum, allowing it to flourish, and getting amazing long-term results:

Transformation – The True Potential of Scrum

Remember that Scrum is based on the values and principles of the Agile Manifesto, and that Scrum itself has five values:

Commitment
Courage
Focus
Openness
Respect

Taken all together, these values and principles constitute the spirit of Scrum. They are the belief system. They are the energy behind the framework. This means that as a team uses Scrum, it must recall these values and principles and try to put them into practice through Scrum. Not just the team, but the team’s stakeholders also need to be aware of these values and principles and also try to put them into practice.

For example, if you are a functional manager for someone who is on a Scrum Team, it is tempting to ask that person to do work that is not actually part of the Scrum Team’s plan. This is a distraction and causes both the individual person and the other Team members to lose focus. Losing focus delays or prevents the creation of a high-performance team. Therefore, as a functional manager, it is much better for you to “cover” for your subordinate, not distract them, and in every way allow that person to focus on their work for the Scrum Team.

Transformation doesn’t come just from adopting a set of values and principles, nor does it come from using a framework of processes and artifacts. Transformation requires love and passion. Transformation occurs when all the members of the Scrum Team, and their stakeholders start to develop intense personal bonds and become passionate about the potential of using the Scrum tool.

I really like the “hammer analogy“. When you first use a hammer, you will likely find it annoying and painful to use. You hit your thumb, your muscles get tired, etc. But after getting better at using it, you start to see its potential: the hammer is an elegant, effective tool. In a small way, you love the hammer, in part because of the results you can get with it. Perhaps you have experienced this if you have ever tried to finish an unfinished basement: after you successfully put up your first stud wall, you think, “wow, I love doing this.” That sense of accomplishment gives you the passion to continue to use the hammer. So it is when using Scrum…

you allow Scrum to transform you and your organization not the other way around.