Top Five Tips for Successful Agile/Scrum Transformation, and How I Learned Them

We’re going to… what?

My first agile project was at Microsoft in September 2001. It was a large infrastructure project, working across multiple teams and organizations. We were told that the project would be using something called extreme programming. I went to a one-hour brown bag meeting and listened to a program manager from another team explain how extreme programming (or XP) worked. We would have a customer in the room, we would be doing test driven development, we would have unit tests, we would be working off of a thing called a backlog, and we wouldn’t have a traditional requirements document or specification phase. As I sat there and listened, I remember thinking to myself how crazy it all sounded. The person standing up there clearly didn’t know a damn thing about how to build software. I knew, then and there, this extreme programming thing wasn’t going to be for me.

“What the hell is this stupid XP thing?”

Walking back to our offices and chatting, I distinctly remember saying to a colleague, “What the hell is this stupid XP thing? We have an operating system called Windows XP—why do we need this? And our testers don’t know anything about test driven development, so I don’t know how that’s going to work. And since we have 50 stakeholders, it’s impossible to have them in the room. This whole thing is going to fail.”

And fail it did. But why? Not because extreme programming doesn’t work, not because agile practices don’t work. It was the mindset of the people trying to implement it. We were told from the top down what to do. Our training was that brown bag meeting with that program manager from another team. We were given an extreme programming book from the Kent Beck series and told to read it—all the answers to our questions should be there. No discussion.

Impending doom

After that we just started. I don’t know what we started because there was no coordination and no central repository of requirements, no common product backlog. Instead, every functional team had its own backlog. Every functional team had its own perceived customer in the room, which typically was just a program manager who was rebranded and renamed. We did things the same way we always had, just with different names and an excuse for skipping steps (we didn’t document anything, for example), because that’s agile. Everybody quickly realized that the project was off track and that the lack of coordination and understanding meant that impending doom was upon us.

What we missed

So yes, it failed. But not for the reasons I brought up with my colleague in the hallway, nor for any other reasons I could see at the time.

We were given an extreme programming book from the Kent Beck series and told to read it—all the answers to our questions should be there. No discussion.

Now, with hindsight and reflection, I know what was missing: the core fundamental values and principles of why we do the work. We didn’t have a common way of thinking that would align people into a common way of doing. Instead everybody questioned everything. The seeds of doubt were sown early, and then we were told to go read a book if we had any questions.

And what’s worse, our leadership team expected us to do everything just a little bit faster. Leadership had read somewhere that this agile stuff would get everything delivered to market quicker. They went about it wrong, and we did, too. But it was sure easy to blame agile for the failure.

Prevent failure when you bring agile into your organization

How do you prevent failure when you bring agile into your organization? Simple. Start with this easy five-step approach.

1. Create a common set of values and principles. Together. It’s meaningless if it is handed down from leadership and management, so make sure everyone has a say.
2. Write an organizational mission statement. Understand what is important to you and your organization, and how questions should get answered.
3. Understand the order in which decisions will be made. Too often do I see decision-making starting with an individual at a company looking at what’s best for them, and then working its way back to the customer. I suggest, when making decisions, we start by asking what’s best for the customer, then working your way back to individual company employees.
4. Invest in coaching and training. If you’ve ever gone to the gym and had a personal trainer or even taken a fitness class, you understand the value of a trainer-led workout. They can see things that we—the people working out—can’t possibly perceive about our form and fitness. We use those insights to help improve our form. Your business is no different: if the process is taken seriously and the advice is followed truthfully and honestly, coaches and trainers confer great benefits.
5. Recognize that learning something new is hard. Ensure there’s room for failure as well as growth. People are not going to experiment or try new things if they are penalized for making errors.

How did I get from that initial disaster of an agile project at Microsoft all those years ago to actually writing a book about agile and Scrum, and being a Certified Scrum Trainer? By applying the five steps I just told you. They’re the concrete expression of an attitude. What’s the attitude? “We’re in this together.” Maybe you noticed that’s the exact opposite of my first agile project!