Are you too busy failing to learn how to succeed?
It is alarming how many of us seem to be. In fact, polls and studies conducted over the last 10 years show a remarkably bleak picture. Depending on sample set and how the question is posed, somewhere between 60% and 70% of all teams or organizations in the United States that attempt the shift to Agile will fail or back out before the transition is complete. Let me put a finer point on that because it’s a critically important concept: If you were aboard the Titanic when she sank, you would have had about the same chance of surviving as you do of changing your company from Waterfall to Scrum.
It is alarming how many of us seem to be. In fact, polls and studies conducted over the last 10 years show a remarkably bleak picture. Depending on sample set and how the question is posed, somewhere between 60% and 70% of all teams or organizations in the United States that attempt the shift to Agile will fail or back out before the transition is complete. Let me put a finer point on that because it’s a critically important concept: If you were aboard the Titanic when she sank, you would have had about the same chance of surviving as you do of changing your company from Waterfall to Scrum.
Is that because Scrum is defective? Overly-rigid? Or unrealistic? Well if it were because of shortcomings in Scrum, we wouldn't see the remarkably predictable success rate when organizations apply it completely as defined. Plus, we have to remember that Scrum was originally extracted as a set of best practices of highly successful teams who were actually doing it daily! Further analysis yields another culprit as the clear killer of Agile attempts. Just talk to some people who have participated in failed implementations and you’ll begin to see where it goes wrong. They’re not hard to find and they are almost all happy to pay for their own cup of coffee just to have an audience to hear their tale of woe. “Scrum just doesn't work,” they will announce with certainty and an air of wisdom.
“It is completely incapable of dealing with the complexities of an organization like ours. And as for complex projects? Forget it. We actually found that our productivity went down, morale hit the skids and defects in production went through the roof when we shifted to Scrum! Some of our most senior people quit because they refused to be treated like sheep. Ultimately, we had to get rid of it to save the company.”
As a coach and speaker, I am often confronted (both in person and electronically) by people with this type of experience. With just a few questions beyond their statement of Scrum’s absolute failure, I find out that it wasn't Scrum that failed them. It’s pretty easy to figure out that they failed to use Scrum. It’s so common that the Agile community has developed a couple of very clever “insider” nicknames we give those implementations: "Scrumbutt” (“We’ll do Scrum, BUT… we won’t use Story Points”, etc.) or “Murcs” (“Scrum” spelled backward). The hazards of hybrid models are well known to experienced Agilists but are deadly catnip to the uninitiated, who regularly set out to navigate this strange terrain without investing in quality training or coaching. Maybe they buy a book. Maybe they buy books for everyone. And maybe a few of them actually read part of it (though some will invariably try to get through the first few meetings by having glanced through the Wikipedia version instead). Or maybe they even find some poor saps who have never heard the word “Scrum” but want a little resume candy, and ship them directly to a Scrum Master Certification course. These are well-worn paths through the woods, my friends. And they all converge at nearly certain Failure. Again, let me be direct:
If you're wondering if Scrum will work in your current environment, let me save you a little time.
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.
The model we use for evaluating a new engineering tool – bringing it in house, having a few of your best people dabble with it and watching for smoke – simply doesn't work when you’re talking about organizational change. Before you go yanking the rug out from underneath your company, you need to first invest in gaining deep, effective understanding of not just the benefits but the pain points of becoming Agile as well.
That’s right, kids, it ain't all sunshine and roses. If you have an effective Scrum implementation, you will be struggling to cope with the pains of organizational change for months or even years. You should know where you’re going and what the ride will feel like along the way. When Scrum comes into the building, it isn't going to be "someone else's problem" to manage. It will invariably land on your desk -- no matter where your desk is -- and demand changes in how you do business. But the rewards are amazing if you adapt. Sadly, though, the state of Scrum in Corporate America today is akin to a couch potato deciding that he wants to ride the Tour de France, so he invests tens of thousands in equipment yet only trains by watching DVDs of previous Tours. If you’re serious, you’re going to have to peddle up some very steep hills while your muscles cry out to turn the bike downhill and coast back to sea level where breathing was easy and the paths were wide and flat. It takes serious training, and no organization or member of the organization gets a free pass.
There are a host of misunderstandings and misinformation floating around. Here are six hard truths that everyone considering Scrum should know:
1. Scrum is not for everyone.
Now if all of this sounds like I’m trying to discourage you from trying Scrum, then you probably scored high on all of your reading comprehension exams. There are enough hucksters out there whipping the hopeless masses into a failure-bound frenzy. Candidly, there was a time in my career when I was one of them. When you first see the elegant brilliance of an effective Scrum implementation, it is natural to brim with enthusiasm and try to light the path clearly so other travelers can follow. And I did – but no longer.
2. Scrum requires tremendous Discipline
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.
3. 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.
4. 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 the Twin Towers on 9/11/01 rapidly re-invented 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 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 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.
5. 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 Engineering. 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 & 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 & 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.
6. 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.
7. 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 who are 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.
8. The Implementation of Scrum Never Ends
It is perfectly natural to want to focus all of your time exclusively on whatever activity is represented on your degree. Coders want to code, testers want to test, managers want to manage and so on. There is nothing wrong with having a great passion for those activities, but to expect that they can exist in an exclusive vacuum is unrealistic. Every member of an organization must participate not only in the area of their passion but also in the art of creating a healthy and successful organization. This means that you have to think of your company not as a collection of skilled individuals but, rather, as a system in which skilled individuals achieve great things. And that system -- the glue that binds us into an harmonious delivery of value -- requires attention, maintenance and creativity. Again, we typically think of bringing in a new software tool as having a learning curve which we expect to flatten out and dissolve into daily activities in short order. We are willing to put time and effort into it -- for a while -- with the expectation that we can soon stop thinking about that tool and go back to doing what we enjoy. But with Scrum that never happens. There is always an improvement to be made, an experiment to be tried, a system to be optimized, a deficiency to be put right.
Too many uncommitted companies, that amount to little more than giant, incorporated couch potatoes, have been jumping aboard the Scrum bandwagon for all the wrong reasons. And, frankly, hanging out with that crowd is starting to tarnish our reputation. We all know that their predictably mangled corpses will just clutter up the pathways for the more committed competitors who are gladly enduring pain for gain's sake. So with a bit more wisdom and the benefit of better hindsight, I no longer believe in “Scrum for All”. I am now a Zen Master in art of “Scrum for the Elite Few”. After all, if everyone was doing Scrum well, where would young Scrum companies find slow, bloated adversaries on which to sharpen their hunting skills?
So go ahead and invest your time buying more comfortable chairs. Have a couple of Executive off-sites, re-org yourselves without changing anything too complicated and use the term “game-changing” a lot. Maybe licensing a few new engineering tools will create an illusion of progress and keep the troops placid. Besides, we all know that if you start Scrum now you will still be arguing about which of the Twelve Points don’t suit your remarkably unique environment by the time a serious Scrum company enters your market. So why bother? Who needs all that pointless stress? There is a lot to be said for a peaceful life lived among familiar surroundings. And aren’t you at a point in your career where you should just be able to coast based on the knowledge and certifications you’ve amassed so far? New systems are just a bother. So just sit back, put your feet up. Wrap yourself in the warm blanket of past achievements, pop open another cold one, grab the remote and check out what’s on ESPN.
One of our representatives will be by to see you before you know it.
