Published on Agile Journal – March of 2011
How can you transform your team into an effective Scrum team?
Scrum is simple, but why is it so difficult to adopt? The dictionary definition of “adopt” is “to take and follow (a course of action, for example) by choice or assent.” So, in order to adopt Scrum, one needs to change, and change of any kind can be inherently difficult, especially for people working in teams. It would be a lot easier if we could break old habits by beginning with a clean slate whenever a new innovation comes along. Given human nature, however, that is not usually easy to accomplish.
Most people in the software industry have used at least one or more methodologies such as Water Fall, RUP, Rapid Prototyping and many more. 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 process) happens when a team fully understands why they need to change and what benefits the new process will bring them. Scrum is, after all, a frame work 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 to be an effective Scrum team. This article presents approaches that you can apply to your organization just to do that.
First, understand the current environment
Before introducing Scrum, understand your organization’s current environment. You can do this effectively by selecting one or two teams in your organization and finding 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 an in-depth analysis, or a meeting with an entire team for a quick analysis can be equally effective. Whichever way you chose you’ll want, at a minimum, to find out the following:
· What is working well?
· What is not working?
· What are the challenges they face?
· 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 questions above. 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’s time-boxing. For one-on-one analysis, make sure that you get everybody together to review the findings and agree on the improvements as a team. The findings will be used as the basis of 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 complied list, then work with an experienced Scum master or coach to identify what issues Scrum can resolve. For example, let’s say one of the problems is that the team constantly needs to work over time to meet their deadlines. There are probably many reasons for this, but working together with an experienced Scrum master or coach, the team will review the underlying issues contributing to the problem and decide whether Scrum will solve it, 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 and, in the end, you’ll be able to generate a list of improvements and see, very clearly, how much more efficient your teams will 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. When setting transition goals, set goals that are realistic and achievable. Next, execute them one sprint at a time. There are a certain set of Scrum practices that the team must employ initially. See the next section for the part of Scrum that the team must include initially, and what part of Scrum they can be included incrementally.
Implement Scrum/XP incrementally
This part of Scrum must be employed initially:
Provided that the team has had its scrum training and a product owner has a product backlog ready for the team, the following meetings of Scrum must be included first. Failure to follow this process will greatly minimize the benefits you will get from Scrum. They are:
· Sprint Planning
· Daily Scrum Meeting
· Scrum Review (Demo)
· Retrospective
In addition to the above, you will need to make sure that the scrum team has a goal for the sprint.
Introduce and implement the following incrementally:
After finishing the first sprint, the team can take on more to adopt. As mentioned earlier, select the items that the team needs and wants and then have a common transition goal behind them. Having a common transition goal will 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 – This is not easy to adopt for some developers, especially those not doing unit testing. If difficult, first 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. Put a plan together for how the team can become a cross functional team by looking at the team’s skills and the composition of the team. 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 with them 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 Scrum master or a coach to suggest a team velocity. Do keep a log of each velocity. The team will improve as it gains experience with the framework and with working together as a team.
· 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. A realistic and effective release planning is when it 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 into Scrum without properly preparing and guiding their teams though the adoption process. As I mentioned at the outset, for a team, the individuals actually doing the work, it is vital that they understand why, what, when and how they should use the Scum framework.
I didn’t talk at all about the support need from the upper management and the rest of organization. Yes, they, too, are indeed needed for the successful adoption of Scrum. Fodder for my next article.