How to fail with a Scrum introduction

The journey of introducing Scrum in an organization is a huge topic in itself, and nowadays there are loads of books and articles describing different aspects of this. Tens of thousands of companies have successfully adopted an Agile methodology. “Scrum” is no longer just a buzzword as it was a few years ago. The hype, the initial excitement and thereby, hopefully, some of the overconfidence has settled a bit. At least that is the feeling I get when speaking to managers and colleagues “out there”. One would think, then, that the process of introducing Scrum would be easier today. With all that collective experience in the industry, with all those books and articles.


But looking around at all those companies and organizations who claim they have adopted (or tried to adopt) Scrum, I wonder how many of them are/were really doing Scrum “by the book”? How many of them modified Scrum beyond what could still reasonably, with a clean conscience, be called Scrum – and struggled and had problems with what they thought was Scrum because of it?


It doesn’t really matter in the successful cases, where the modifications to Scrum work and the result is something that is at least as good as whatever was being done previously. I guess those organizations would still, in the end, claim that their Scrum implementation was successful – regardless of it really is Scrum or not. But what about all those cases where an organization tried Scrum, concluded it didn’t work, and maybe even decided to go back to dysfunctional..err..sorry, traditional, waterfall-based approach? How many of those ever stopped and pondered on the reasons – the root causes – of why Scrum didn’t work? Ever heard something like “Well, Scrum just didn’t suit our organization/business/team, I think Scrum is over-rated and as I thought it wasn’t the magic bullet answer to everything”?


Scrum and Agile is so simple and made up mostly of common sense behaviors and values, that if it really doesn’t work for you then you’re really special. And no offence but it is likely that you’re pretty much like everyone else – no matter how special you want to believe you are.


So why doesn’t Scrum work?


The person responsible for driving the Scrum introduction – the “Scrum driver” – is key to the outcome of the change. In my experience there are four (five) common traps that a Scrum adopting organization risk falling into. All relate to the Scrum driver:

1. He or she lacks sufficient knowledge about what the Scrum methodology and the Agile philosophy is all about.
2. He or she is also a Project Manager (or a group of Project Managers).
3. He or she lacks enough time to focus on things like coaching, monitoring, adjusting, educating and motivating the Scrum teams and the stakeholders.
4. There is no plan on how to introduce Scrum.

Maybe a fifth one should be listed also, for the record; the failure to realize that there is need for a “Scrum driver”.


Lack of conviction


I think a common reason for failing with Scrum is that the introduction is driven by someone who lacks conviction and (true) passion – i.e. someone who consequently lacks credibility in the eyes of all stakeholders. Introducing Scrum requires a firm and honest belief in its benefits. The need for conviction is not unique to a Scrum driver but apply to any change process. Introducing Scrum will mean drastic changes for everyone; team members, project managers, stakeholders and managers surrounding the development organization/team. The ways of thinking, the methods, attitudes and expectations will need to change. From day one. You can’t introduce Scrum in steps. It’s All in – or leave the table. And people are naturally conservative. It’s always easier to stick to what you know and have experience with. The unknown is scary. Especially at times of stress, when the going gets tough. That’s when conviction and passion will be required in order for the changes – the Scrum methodology – to persevere.


A Project Manager is put in charge


A Project Manager ought to be the one with the best understanding of how to run a software development project. Right? They are (mostly) educated, intelligent, communicative and multi-tasking individuals with loads of real-life experience of stressful situations, risk management and change management. They are used to following checklists, processes and project methodologies. If anyone should be able to introduce Scrum it would be a Project Manager. Right? Well. Would you let a taxi driver be responsible for introducing free subways? Silly analogy perhaps, but my point is that it would be fair to expect their level of commitment to be less than maximal.


Don’t get me wrong, some people are less conservative than others. Open-mindedness is a property that some people have more of – and some less. Introducing Scrum will without a doubt affect the every-day work of the Project Manager, their entire role and responsibility. It may even eliminate the need for a Project Manager altogether. Therefore, to me at least, it is simply not natural that the project manager by default becomes the person responsible for driving that change. They are an involved and affected party. Someone else should be in the driver’s seat, someone like a line manager, a manager of the project office, whoever is the project manager’s boss, or even someone external to the team.


Underestimating the challenge


Introducing Scrum isn’t free – and I’m not talking about a few thousand bucks to get someone a Scrum Master certification, or a couple of books. The adopting organization will need to put the money where its mouth is. In my mind it is not enough to only educate whoever becomes Scrum Master. The entire team needs to have a good (or great) understanding of Scrum; about what problems it solves, what are Agile attitudes (and what are not), what parts of Scrum are fundamental and about what parts can be tailored to the organization/business/team (and which can’t). Educating an entire team will cost time and money.


And education is only the beginning. Using Scrum will require lots of monitoring, coaching and adjustments along the way. Continuous improvement. Inspect and adapt. At first that will be managed by the person driving the Scrum implementation, and therefore will require a lot of time & effort from that person to stay close to the team, to keep up-to-date – by the hour – about what’s going on in the team and outside. But as the Scrum team grows used to the new way of working they will start helping each other out, correcting each other and helping each other with staying within the boundaries of Scrum.


Another aspect often underestimated may be that of getting everyone onboard. Getting the team members to accept Scrum is a pretty obvious challenge that has to be dealt with. The same should be true for the project manager(s), and maybe even the customer(s). But what about surrounding managers, departments and other roles and neighbors within the organization? Those are the people that will be indirectly affected by the Scrum introduction. It is important to have a good idea about who those persons are, so that you can actively work on their expectations. Take control. If surrounding expectations are not in-line with what Scrum is capable of you’re in trouble. That’s why it’s a good idea to form a plan on how to get them to accept Scrum.


Lack of strategy, lack of plan


It’s surprising (disturbing), I think, how little planning is generally made for introducing Scrum – considering that it happens in an environment where people are usually very used to making rigorous plans, managing risks, etc.
A sufficient “plan” in this case would mean taking the time to think about things like;

• Why are we introducing Scrum? What are the expected benefits? Are they realistic?
• What are the expected drawbacks of introducing Scrum? Will all stakeholders accept those?
• Who will be in charge of the Scrum introduction, i.e. who will be the “Scrum driver”? Is the person in charge also a Project Manager?
• Which persons will be directly affected by the change? Is the Scrum driver one of them?
• Which persons will be indirectly affected? Is the Scrum driver one of them?
• What is the level of credibility, passion and conviction of the Scrum driver? Is he/she able and ready to be a source of inspiration to others during the change process?
• Are all affected persons (directly and indirectly) onboard?
• Do we have any key people to get onboard as assisting informal Scrum advocates within the organization/business/team?
• What is our education plan (plan for getting people on the bus) for people directly as well as indirectly affected by the Scrum introduction?
• What is the budget for “education” (getting people on the bus), in people-time or in money, for the persons directly affected by the change?
• What is the budget for “education” (getting people on the bus), in people-time or in money, for the persons indirectly affected by the change?

Summary


Introducing Scrum is a challenge. But I’m pretty sure most would agree that it’s worth the effort, if you can get it to work for you. But please don’t underestimate the challenge. And please consider letting someone other than a Project Manager be in charge of the Scrum introduction.


Whoever is put in charge of the Scrum introduction it needs to be someone with:

1. mandate and authority to implement the change; and
2. someone with a wholehearted belief in the benefits of the change; and
3. someone with a budget for the extra effort caused by the Scrum introduction.

Let me be clear on this: I don’t think that Scrum really is the solution to everything. I’m sure there are many cases and circumstances where it simply doesn’t suit the organization/business/team. But if you tried it and failed, I think it’s worth to ponder on whether or not it was Scrum that really failed – or the implementation of it.


As always, I’m interested in getting some feedback via comments on this blog.


Cheers.