One way of introducing Scrum
"You're right, Scrum looks like it could be a good fit for our project. Do you think we should implement it in all our teams right away?"
"No, I'm not sure that's the right approach."
"But you've just spent the last half-an-hour explaining how beneficial Scrum could be for us, so why don't you want our teams to use it?"
"I definitely want them to use it, but they have to want to use it too."
I went on to explain to my manager why I didn't think that a management driven, top-down, roll-out of Scrum was the correct approach for our project. I'd like to take five minutes of your time to explain why that might be the case for your project too.
The Scrum process relies heavily on the commitment and drive of the development team. If a team isn't fully on-board with Scrum then the endeavour is almost certainly destined for failure from the outset. What I recommended to my manager was that we implement Scrum in just one team, with the hope that the concept would spread organically throughout the rest of the project.
I worked in a five person development team, as part of a one hundred person project. There were several development teams in the project; each responsible for one system module. The teams interacted with each other on an ad-hoc basis, and at process driven meetings. In large projects it can be common for a "silo" culture to form, where each team becomes its own "island", and where shared ownership of the entire product can be difficult to cultivate. That was certainly the case at the beginning of this particular project, with teams tending to have an insular and protectionist culture. I felt that this type of project situation made it all the more important to attempt to grow Scrum from the ground up, rather than to force it upon the teams from above.
My suggestion to my manager was to try the Scrum process in my development team, and if it proved beneficial then we could introduce the concept at the project level and give other teams the opportunity to discuss Scrum with us if they were interested.
Selling the Scrum concept to my development team turned out to be easy. Everyone in the team immediately saw the potential benefits, especially as Scrum appeared to offer a solution for the two main problems our team faced; poor estimations and prioritization issues. I was designated as ScrumMaster and set to work on producing our Scrum Taskboard, which I made from flip-chart sheets sticky-taped together into a 2x2m "master" sheet and pinned to the wall in our team's area of the open-plan office. The Taskboard immediately attracted the attention of other teams in the vicinity and when people came over to enquire about it, we were presented with an early opportunity to evangelise about Scrum.
Our first Sprint finished with a number of Backlog Items left uncompleted on the Taskboard and a Burndown Chart that looked more like a plateau than a slope. In our first Sprint Retrospective we came to the conclusion that we had underestimated the time it took for us to complete documentation and testing Tasks. We also realized that we had received too many external interrupts during the Sprint, reducing our focus on the planned Tasks. We devised a strategy with my manager for reducing the external interrupts and agreed to increase estimates for documentation and testing Tasks in future Sprints.
In each subsequent Sprint we continued to improve our estimates, remove external interrupts, optimize our development and test environment, and improve our work prioritization. Our manager was happy with the improved estimates and the progress updates he received at daily stand-ups or by glancing at the Taskboard as he walked past. The team was happy with the greatly reduced interruptions and the clarity of knowing what task they should work on next. I was happy that my development team was working more efficiently and delivering more business value in less time.
The whole team agreed that using a paper Taskboard, post-it note Tasks, and a simple Excel spreadsheet template for the Burndown Chart, was the correct approach given our situation. The simplicity of the tools, the hands-on interaction required to manipulate them, and their strong visibility in the office, were all contributing factors to their perceived success.
By the time my team had completed its fifth Sprint, two other teams in the project had spontaneously decided to start using Scrum. I met with the two teams to discuss my team's experiences of Scrum and to make some best-practice recommendations. The teams put up Taskboards in their part of the office, and the 'from-the-ground-up' roll-out of Scrum had begun.
The next step was to introduce the Scrum concept to the project as a whole. I held a five minute overview of the Scrum process at an all-persons project meeting and invited team leaders to talk with me if they were interested in finding out more. Over the next few weeks a number of team leaders came over to discuss Scrum and how they could implement it in their team.
For the majority of these new Scrum teams, their only previous exposure to Scrum had been my five minute overview and perhaps a little research on the Internet. This meant that almost all of the new teams experienced teething problems in getting up-to-speed with Scrum. In fact, some of the teams found it particularly difficult in the beginning due to having ScrumMasters who hadn't fully comprehended the "hows" and the "whys" of Scrum. This was one of my main learning points from this particular Scrum roll-out; all of the ScrumMasters should have been given external ScrumMaster training to get them more comfortable with Scrum, before they attempted to apply it in their teams.
After a slightly rocky start for a couple of the new teams, less than six months after introducing Scrum in just a single team in the project, every major development team was using it. At no point did any managers mandate the use of Scrum - teams wanted to start using Scrum themselves because they saw it working well for the other teams around them.
It appears to be a psychological trait of human beings that we are more receptive to ideas that we have been gently introduced to, rather than those which have been forced upon us. For example, if you would like to convince someone who disagrees with you, it is often more effective to ask them questions that cause them to evaluate their position, rather than to put them "on the defensive" by declaring their position as incorrect. Bear this in mind if you are planning to introduce Scrum in your project; we did, and it worked for us.
James Trunk is an Agile consultant with eight years experience delivering cutting-edge Java solutions. For the past three years he has been involved in two Scrum managed projects; one as a team-member and the other as ScrumMaster.