Summary:
So, you want to practice Scrum? Great idea, but don't be fooled. Great ideas are rarely easy to implement. Alicia Yanik found implementing Scrum to be anything but easy. In this week's column, Alicia contests that the process is certainly worthwhile, makes sense, yet definitely is nothing close to easy to implement.I come from a rogue band of project managers who firmly believe there has to be something better than chaos, waterfall, and complete control. Six years into my project management experience a colleague recommended I look into Scrum. It was like entering the promise land for buck-the-system type project managers - and it all made so much common sense.
The company I worked for at the time existed in the land of chaos. Those at the top thought the implementation of any process would lead to the inevitable demise and downfall of the free world. Yet they bought off on Scrum, or rather, on what they heard when I described Scrum. This is important, so pay attention: they bought off on what they wanted to hear. It's easy to evangelize Scrum, to explain the benefits, and show how -- by implementing Scrum -- an organization achieves success every thirty days. Who wouldn't want to give Scrum a shot with those odds? The executives heard "daily status," "just enough documentation and requirements to be successful," and "new increments every thirty days." What they didn't hear was "no interruptions for thirty days," and "the sprint goal doesn't change during the sprint."
I succeeded in getting approval for Scrum, but then I floundered. Where should I start? What should I do? How was I going to make this happen? I found myself reading any article I could find related to Agile practices and Scrum in particular. I ordered books, I joined user groups, I even posted to user groups (and as all good introverts can attest, we NEVER post to user groups).
I decided to begin with the logistics of Scrum by holding daily stand ups, creating a backlog, tracking the burn down, and then I thought about what should come next. I believed the logistics of Scrum were easy to implement, but the power of Scrum doesn't lie in the logistics. The Scrum team holds the power. The team was initially hesitant about Scrum, but they quickly embraced it. I created a "mini-training" for the team, and was zealous in my excitement for Scrum and Agile in general. I always had a "scrummy" solution for removing any obstacle in our path.
The team didn't face many of the traditional pitfalls of software development. We released often, the work was always on time, and the team worked exceptionally well together. Our problems were in the planning, or rather, the fact that the planning never stopped and the priorities were never set. Our code was released literally as soon as it was written. The pace was quietly frantic and nothing was sustainable about our release process. With only four developers to write new code and support existing products, determine priority, define requirements, and perform any and all testing, we were headed for Burn-Out Fest '04.
We had the Scrum logistics in place, but I struggled with harnessing the team's power. I devoured more Scrum information and turned to the team for their ideas. We spent time in every team meeting talking about Scrum and how to move forward. Ken Schwaber noted in class that it's quite possible, and likely, someone on a new-to-Scrum team won't like Scrum. I found that to be the case with one of my software developers who pitted himself against Scrum and the rest of the team. Ultimately, Scrum wasn't for him so I stopped the bus, he got off, and someone new climbed on. I also faced resistance from a product manager who decided we needed process and documentation before we could even begin to start with something as simple as the daily stand ups.
Then I took a closer look and noticed the team problem solving, self-organizing, and trying out Scrum practices without any nudging from me. Within a month of their introduction to Scrum, the team was making changes to their environment and beginning to introduce new practices into their coding conventions. Within six months the team decided to re-architect their entire code base - to make it more Agile! The skeptics on the team were starting to ask for books and beginning to encourage each other to try new practices. We adopted a try-it-before-you-buy-it approach, so if something didn't work, we would throw it on the give-away pile. We reached that point where you just know you're practicing Scrum because you feel it.
So, where are we now? We continue to struggle with interruptions and bits of scope creep. I'm more aware of how often I was controlling, even as a self-professed non-controlling project manager. Our sprint goals aren't particularly impressive, but we work together as a collective group. Two new members joined the ranks and have already become an integral part of our team. Our release schedules and pace are sustainable and our ability to plan is markedly better each month. The priorities of the organization are clear and aligned. We continue to try new ideas: the latest is the integration of User Stories as requirements. We are excited to come to work. Recently, a co-worker described the development team as the most productive, focused, and excited as he's ever seen them (he's worked with this team for five years). I maintain implementing Scrum is one of the harder things I've done in my career as a project manager--and I believe one of the most rewarding as well.
The company I worked for at the time existed in the land of chaos. Those at the top thought the implementation of any process would lead to the inevitable demise and downfall of the free world. Yet they bought off on Scrum, or rather, on what they heard when I described Scrum. This is important, so pay attention: they bought off on what they wanted to hear. It's easy to evangelize Scrum, to explain the benefits, and show how -- by implementing Scrum -- an organization achieves success every thirty days. Who wouldn't want to give Scrum a shot with those odds? The executives heard "daily status," "just enough documentation and requirements to be successful," and "new increments every thirty days." What they didn't hear was "no interruptions for thirty days," and "the sprint goal doesn't change during the sprint."
I succeeded in getting approval for Scrum, but then I floundered. Where should I start? What should I do? How was I going to make this happen? I found myself reading any article I could find related to Agile practices and Scrum in particular. I ordered books, I joined user groups, I even posted to user groups (and as all good introverts can attest, we NEVER post to user groups).
I decided to begin with the logistics of Scrum by holding daily stand ups, creating a backlog, tracking the burn down, and then I thought about what should come next. I believed the logistics of Scrum were easy to implement, but the power of Scrum doesn't lie in the logistics. The Scrum team holds the power. The team was initially hesitant about Scrum, but they quickly embraced it. I created a "mini-training" for the team, and was zealous in my excitement for Scrum and Agile in general. I always had a "scrummy" solution for removing any obstacle in our path.
The team didn't face many of the traditional pitfalls of software development. We released often, the work was always on time, and the team worked exceptionally well together. Our problems were in the planning, or rather, the fact that the planning never stopped and the priorities were never set. Our code was released literally as soon as it was written. The pace was quietly frantic and nothing was sustainable about our release process. With only four developers to write new code and support existing products, determine priority, define requirements, and perform any and all testing, we were headed for Burn-Out Fest '04.
We had the Scrum logistics in place, but I struggled with harnessing the team's power. I devoured more Scrum information and turned to the team for their ideas. We spent time in every team meeting talking about Scrum and how to move forward. Ken Schwaber noted in class that it's quite possible, and likely, someone on a new-to-Scrum team won't like Scrum. I found that to be the case with one of my software developers who pitted himself against Scrum and the rest of the team. Ultimately, Scrum wasn't for him so I stopped the bus, he got off, and someone new climbed on. I also faced resistance from a product manager who decided we needed process and documentation before we could even begin to start with something as simple as the daily stand ups.
Then I took a closer look and noticed the team problem solving, self-organizing, and trying out Scrum practices without any nudging from me. Within a month of their introduction to Scrum, the team was making changes to their environment and beginning to introduce new practices into their coding conventions. Within six months the team decided to re-architect their entire code base - to make it more Agile! The skeptics on the team were starting to ask for books and beginning to encourage each other to try new practices. We adopted a try-it-before-you-buy-it approach, so if something didn't work, we would throw it on the give-away pile. We reached that point where you just know you're practicing Scrum because you feel it.
So, where are we now? We continue to struggle with interruptions and bits of scope creep. I'm more aware of how often I was controlling, even as a self-professed non-controlling project manager. Our sprint goals aren't particularly impressive, but we work together as a collective group. Two new members joined the ranks and have already become an integral part of our team. Our release schedules and pace are sustainable and our ability to plan is markedly better each month. The priorities of the organization are clear and aligned. We continue to try new ideas: the latest is the integration of User Stories as requirements. We are excited to come to work. Recently, a co-worker described the development team as the most productive, focused, and excited as he's ever seen them (he's worked with this team for five years). I maintain implementing Scrum is one of the harder things I've done in my career as a project manager--and I believe one of the most rewarding as well.
