How Scrum helps you change what needs to be changed within your organization

Last week, Gunther Verheijen posted a much-needed article showing worrying interpretations of Scrum. Please read it carefully if you care about professional Scrum.

In my role as an agile coach, I hear people say awkward things about Scrum on a daily basis. Stuff like Gunther mentions. There's nothing wrong with that...as long as these people learn, correct themselves, and start making a difference. 

What worries me more is that many people advocating Scrum haven't read the Scrum Guide. Or even the Agile Manifesto. They apparently weren't curious enough to find out what Scrum truly is. Most of these people thus limit themselves to explaining their interpretations of merely the roles, artifacts, and ceremonies, putting emphasis on how to perform a daily "standup" or what a Scum Master should do and then still faltering at that. How odd! 

Scrum, when "applied" well, is extremely powerful. Teams can double, triple, or quadruple their productivity with ease. More importantly: they will actually deliver working, releasable software that truly helps shorten time to market. The core of Scrum, as Gunther explains.

But...Scrum is not for free. Far from it. It comes at the cost of your organization's current structures including your personal work environment, your role, your privileges, and hence your comfort zone.

Due to the nature of incremental delivery AND the focus on getting the software truly "done" (as in working, releasable), you will need to radically change everything in and around the team.

You start your sprint one with a bunch of requirements. Two weeks later, some potentially releasable software is expected. So...the team immediately needs some space to work, tools for development and collaboration, architecture guidelines, access to users, proper environments, privileges, connections to databases, working services from other teams (alignment horror!).

It is incremental delivery with the strong requirement to have a potentially shippable increment by the end of every single iteration/sprint that is most disruptive. Alas, without it you are not really doing Scrum according to its makers and most of its knowledgeable supporters.

Now, do you still want Scrum? Do you want to be part of such a challenge as a team member, chasing organizational impediments like a mad man? Do you, as a manager, want development teams to turn into autonomous productivity monsters at the cost of your span of control?

Think about it.

And don't believe that any other agile framework or method will save your ass. ALL of them support incremental delivery. Only the weaker ones (or better: the misinterpreted ones) do not put focus on working, releasable software.

Of course you can game everything by just pretending you are using Scrum. You could stress the importance of a print zero, put a proxy product owner in place, organize hardening sprints, explain that "done" in your company means something special, stick to steering committees, etc. Just come up with anything that comforts you and puts your mind at ease.

Or actually...please don't. 

Do you want to be truly succesful with agile and Scrum or any other framework? Then face your fears, expect radical change and have the people who do the actual work help you through that change in a decent way. There will be pain, but...no gain without pain ;-)

Enjoy your challenge!