Six Hard Truths About Moving to Scrum

The following is an excerpt from “You’re Just Going to Fail, So Why Bother?” by Scott Downey, Owner, RapidScrum.com. For the full article, visit the RapidScrum blog page.

If you’re wondering if Scrum will work in your current environment, let me save you a little time.

No. It won’t.

 

But if you’re looking at Scrum, it’s probably because there’s something that isn’t working now. What needs to change is your environment, not the framework of Scrum. And that’s a big, huge, hairy deal.

There are a host of misunderstandings and misinformation floating around. Here are six hard truths that everyone considering a Scrum transition should know:

1. Scrum is not for everyone

Achieving the results that attracted you to it in the first place requires a tremendous amount of discipline, initiative and motivation. Most companies simply won’t do the hard work to achieve a sustainable, expanding implementation. It’s a lot like organizational psychotherapy. Sometimes, you uncover something horrifying and, once the elephant is in the room, you’re stuck dealing with it.

The most common coping mechanism is to blame it on Scrum, revert to old behaviors and have coffee with lots of friends so you can tell them how Scrum failed you. Denial is so comforting – for a while.

My advice to anyone considering the move to Scrum is to first list the reasons you think it is right for you. If you have only gotten as far as the “whiter teeth and fresher breath” sales pitch, back up and ask some deeper questions before you drag your company on an expensive and sometimes lethal boondoggle. If you’re getting pumped up on Scrum by a coach who cannot address some of the pain points you’re likely to experience, you may well have a charlatan on the line.

Remember, if your current system is not giving you the results you need, something – perhaps lots of “somethings” – will have to change. If your understanding of Scrum is all benefit and no pain, your implementation will most likely be all talk and no action.

2. Scrum is not an org chart

I frequently have people ask me, “If I become a Scrum Master, what is that going to do to my career?” or “What is my path for promotion from Scrum Product Owner?” But the much more common form of the question is, “I’m a Development Manager. Do I not have a job in Scrum?”

The honest answer is that the early years of Scrum were riddled with calls to fire all people with the word “Manager” in their titles – Product, Development, QA, Project, Program, etc. That is (thankfully) no longer the common wisdom and certainly is not my advice to anyone. Good management still has a vital role to fill but we do need a particular breed of manager. Command-and-control, authoritarian types will not thrive in a Scrum company unless they turn over a new leaf. Micro-managers, however successful they may have been under the old system, will need to be retrained or replaced under the new one.

You should go into this decision knowing that serious organizational change means being serious about changing the organization. But it doesn’t go so far as eliminating everyone whose title falls outside the three Scrum roles. Leaders who have never been interested in facts and prefer to just bully and threaten people are not going to suddenly start responding positively when Scrum paints an even clearer picture of the reality they wouldn’t acknowledge in the first place.

So while companies still need leadership, just be sure you have the right type. If your corner offices are clogged with sacred cows who refuse to learn new behaviors, know up front that this will dramatically (perhaps mortally) wound your attempt at change.

3. Scrum has nothing whatsoever to do with software

While it is true that the overwhelming majority of Scrum adopters are software organizations, it is equally true that none of the Twelve Points of Scrum directly or indirectly addresses anything particular to software engineering.

Scrum is about human beings. It is a framework that allows people to effectively solve complex problems. But it is the people who solve the problems, not the software. Try this on for size: many churches use Scrum. So do non-technical, non-profit organizations. And perhaps the most heroic use was when the rescue workers at Ground Zero on 9/11 rapidly reinvented a way of working together that almost perfectly mirrors the Twelve Points of Scrum. Remember Scrum’s origin: “Best practices of highly effective teams.”

But if you have been looking to Scrum for a rule about code reviews — stop. It isn’t there. If anyone demands that you cannot have specialists on a Scrum team, make them tell you which of the Twelve Points made them believe this. There isn’t one. If someone tells you that Test-driven development (TDD) is required to do Scrum, correct them. They are wrong, and you can tell them I said so. And if you think I have said that to you, please come see me right away.

I’m a tremendous fan of TDD, to be sure. It pairs well with Scrum – like chocolate and peanut butter. But Scrum only cares that you finish a sprint with a completed, working product. How you achieve that is entirely up to you. Use Magical Quality Gnomes if you have them. I certainly would.

There are several best practices emerging – like combining Scrum with LEAN, XP, TDD and so on. But don’t be sold a lot of religious zealotry, however well-intended, under the guise of following a Scrum mandate. Scrum is about taking a group of humans and achieving a series of goals. Period.

4. Scrum will not fix your company

Scrum will relentlessly and remorselessly identify your company’s problems. It will point a finger as easily at the president of your company as it will at the most junior member of the engineering team. But the Scrum framework doesn’t tell you what to do about the problem. You and the leadership have to sort that out yourselves. It’s why you get the big bucks. You will have to make some tough, uncomfortable decisions. Sometimes, you won’t be popular.

Consider, for example…

What would you do if that founding architect just can’t stop meddling with teams and constantly causes Sprints to fail? Will you correct the architect’s behavior, or order the team to cope as best they can? And what if your sales and marketing department refuses to deal in realistic dates? Will you press your teams into long, late hours, ignoring the skyrocketing defect injection rate and mountain of technical debt? Or will you make the necessary changes in sales and marketing to improve the situation? What if Scrum tells you that your own behavior is counterproductive? Scrum will tell you it’s happening, but will you take responsibility for fixing that problem?

If you will stand up to these challenges and more, you may be well suited for Scrum – and let your competition beware.

5. Scrum eventually changes everything

There is no office in the building that won’t eventually see change with Scrum. There is no institution, division, process, architecture or tradition that won’t eventually feel its impact. “Inspect. Adapt. Iterate.” It sounds so simple – and it is. But simplicity and ease are distinct notions for a reason. If you’re going to make a success of this transition, you need to understand that you are slowly rebuilding your company from within, and every truss and rivet will be touched before you finish.

In one of my previous positions, I was the engineering manager for a core component that changed very frequently. We often referred to our releases, which auto-installed directly to production, as “changing the wheels on a moving bus”. It’s an apt analogy for shifting to Scrum. You have to keep the business moving while you fundamentally change its structure and essential functions.

6. Self-organization does not mean “go do whatever you want to do”

I have worked with scores of individuals who saw the Scrum ethic of self-organization as a warrant to defy direction and just work on whatever made them happy. I’ll try to be as clear and uncomplicated as I can be: if you do that, you will probably be fired.

Self-organization applies to the team, not to individuals. The company has (or should have) a distinct, well-defined set of goals that they need you to achieve. Empowering the team to decide how the problem gets solved is an overdue extension of respect for the professionalism and intelligence of the team that is doing the work. But be very clear on this critical point: the solution and coordination is up to the team, but the choice of which problem to solve is not.

This is an excerpt from “You’re Just Going to Fail, So Why Bother?” by Scott Downey. For the full article, visit the RapidScrum blog page.