Scrum is simple, so how can it be so difficult to adopt? The dictionary definition of adopt is “to take and follow (a course of action, for example) by choice or assent.” [1] In order to adopt Scrum, one needs to change, and change of any kind can be inherently difficult, especially for people working in teams. When change is required, it would be a lot easier if we could break old habits and begin with a clean slate. Given human nature, however, this is not easy to accomplish.

Most people in the software industry have used one or more methodologies—waterfall, RUP, Rapid Prototyping, or others. Needless to say, adopting Scrum requires learning new practices. So the question becomes: How can Scrum be introduced in a way that effectively and elegantly transforms an established team into a Scrum team? Based on my experience, the successful adoption of Scrum—or any other process—happens when a team fully understands why they need to change and what benefits the new process offers them. Scrum is, after all, a framework for a team—the people actually doing the work. So, its successful implementation takes place most effectively when the team understands why, when, and how to use the framework. This article presents approaches that you can apply to your organization to do just that.

Understand the Current Environment
Before introducing Scrum, understand your organization’s current environment. Select one or two teams in your organization and find out what processes they are currently following, what challenges and impediments they face in accomplishing what they need to do, and what improvements they need or would like to make. Conducting one-on-one interviews with each team member for in-depth analysis or meeting with an entire team for a quick analysis can be equally effective. Whichever you choose, you’ll want, at a minimum, to find out the following:

• What is working well?
• What is not working?
• What are the challenges the team faces?
• What impediments does the team face? What are the issues underlying those impediments?
• What urgent improvements does the team need or want to make? Why are they needed?

It is important not to go overboard collecting too many answers to the above questions. Put a limit to the number of answers you get, but do make sure that you get input from everyone. One way to limit the answers is to employ the Scrum method of timeboxing, which cuts short the length of time of tasks and meetings. Make sure you get everyone together to review the findings and agree as a team on the improvements. The findings will be the basis for the team’s transformation. To compile an effective and objective list of the findings, consider bringing in an outside facilitator to conduct these sessions. The results will give you a good idea whether your organization is running smoothly and effectively.

Find Out What Scrum Can Do for the Team
After gaining a thorough understanding of the current environment, the next step is to find out what Scrum can do for your team. First, prioritize the compiled list and then work with an experienced ScrumMaster or coach to identify what issues Scrum can resolve. For example, let’s say one problem is that the team constantly needs to work overtime to meet their deadlines. There are probably many reasons for this, but working together with an experienced ScrumMaster and coach, the team will review the underlying issues contributing to the problem and decide whether Scrum will solve them—and if so, how. You’ll also find out the costs or benefits of not addressing the problems at all. Do the same for all the challenges and impediments. In the end, you’ll be able to generate a list of improvements and very clearly see how much more efficient your teams can become.

Set the Stage for Adoption and Implementation One Sprint at a Time  (But Be Realistic!)
Let me make this point very clear: Scrum does not solve all the challenges and problems in delivering a successful software product. But a Scrum team will manage those problems more effectively through transparency, inspection, and adaptation. Gaining an understanding of your current environment, the cost of not fixing the problems that have been uncovered, and discovering how Scrum can help, all give the team a thorough understanding of why they need to adopt Scrum. The next step is to put this knowledge into action by grouping related items behind a common transition goal. Set transition goals that are realistic and achievable. Next, execute them—one sprint at a time. The next section discusses which Scrum practices the team must employ initially and which Scrum practices they can employ incrementally.

Implement Scrum/XP
Employ These Scrum Practices Initially:
Provided that the team has had its Scrum training and a product owner has a product backlog ready for the team, the following scrum meetings must be included first:

• Sprint planning
• Daily scrum meeting
• Scrum review (demo)
• Retrospective

Failure to follow this process will greatly minimize the benefits of Scrum. In addition to the above meetings, you need to make sure that the Scrum team has a goal for each sprint.

Introduce and Implement the Following Scrum Practices Incrementally:
After finishing the first sprint, the team can take on more. As mentioned earlier, select the items that the team needs and wants, and have a common transition goal behind them to guide the team and bring focus to what they need and want to change. A good time to do this is during a retrospective meeting. Below is a list of suggested items that they can adopt incrementally:

• Definition of done – Continuously revisit the definition of done. This helps a Scrum team estimate work more accurately. Start with a simple one and then revisit it continuously during the retrospective meeting.
• TDD – Some developers have difficulty adopting TDD, especially those not doing unit testing. If TDD is difficult, start by agreeing with a product owner on a “what and how-to demo”; then automate the test cases, finally moving them into TDD.
• Potentially shippable products – Continuously look at ways to automate manual processes via automated tools and scripts so the team can deliver a potentially shippable product while increasing their velocity.
• Cross-functional team – This is not easy to implement initially. Look at the team’s skills and the composition of the team to put a plan together for how the team can become cross-functional. If this is difficult to adopt, start first with pair programming and move them into becoming a cross-functional team.
• Techniques used during a retrospective – There are many techniques for conducting this meeting, so experiment to find out what works for the team or invite an experienced facilitator to conduct the meeting.
• Velocity – Do not put too much emphasis on getting a correct velocity initially but rather rely on an experienced ScrumMaster or coach to suggest a team velocity. Do keep a log of each velocity. The team will improve as it works together and gains experience with the framework.
• Sprint and release burndown charts – Apply the same techniques as in velocity to get these measurements.
• Release planning – If your organization already does release planning, review the process but avoid spending too much time up front. Realistic and effective release planning is done right after a sprint.

Conclusion
Yes, Scrum is simple. Yes, it is the most effective framework for delivering a software product in a complex and competitive market. But too many organizations jump right in to Scrum without properly preparing and guiding their teams through the adoption process. As I mentioned at the outset, it is vital that the team—the individuals actually doing the work—understand why, what, when, and how they should use the Scrum framework.

I haven’t talked at all about the support needed from upper management and the rest of the organization. Be assured that the successful adoption of Scrum does require their support. Hmm...fodder for my next article.

References

[1] The Free Dictionary, http://www.thefreedictionary.com/adopting

Trackback(0)

TrackBack URI for this entry

Comments (1)

...
written by Javin Paul, May 03, 2011

Great article , you have indeed covered the topic details. I have always seen articles with flowery content on SCRUM but I never agree that one process could be very effective until it been tweaked based upon team's requirement, need and strucutre.

Javin
How Classpath works in Java

• 
• +1
• 
• 

Write comment

Show/hide comment form

Name

Comment

smaller | bigger

Subscribe via email (registered users only)

Write the displayed characters

Add Comment Preview