Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Moving to Scrum: Making the Case to Management : Page 3

Bring the power and efficiency of lean-agile development to your organization. Learn how to lobby for the adoption of a lean-agile Scrum software project management methodology from someone who's been through it.


advertisement
Lukewarm Reaction?
It turns out that though I thought I was very convincing the development manager hadn't been very enthusiastic about the presentation. He wasn't in favor of "diverting resources to estimate and plan" when we could be going heads-down to push out functionality for the business. The obvious enthusiasm of the team to get out of the rut we were in ruled the day, with the majority of the development team urging the development manager to give Scrum a try. Since we started with Scrum this manager has become a true believer in the process. But at the time he was skeptical, so when he approached me the next day, asking "what do we do next?" I had my work cut out for me. Hopefully in your situation you will have more eager adopters but be prepared to help the skeptics along through the early phases of adoption.

There was just one little problem: I knew Scrum could work for our organization and I knew what a reasonable Scrum team looked like in action but how to get there from our current state was a question I hadn't deeply considered in a practical way. What are the concrete steps to get Scrum up and running? Mercifully, the answers I vaguely intuited are wonderfully explained in vivid detail in Mike Cohn's "Agile Estimating and Planning." I picked up my copy and read it in a hurry. I followed my sales pitch with a second presentation, aptly entitled "Concrete Next Steps to Implement the Scrum Process."

Concrete Steps to Implement the Scrum Process
The high-level view of what it takes to get up and running with Scrum is straightforward:

  1. Create a prioritized Product Backlog
  2. Hold a story point estimation session
  3. Allow the business to revise the backlog’s priorities based on the story point estimates
  4. Decide on the length of the sprint
  5. Hold an iteration planning session and commit to the package of work that the team believes it can accomplish in the sprint
  6. Commit to convene 15 minute daily team status meetings for team members to update everybody on their progress
  7. At the end of the sprint, review the sprint and roll out the functionality that is ready to go
The CTO was going to attend this presentation so I worked hard to lay out the practical considerations involved in these points and how it would help our efforts. I also emphasized that any new process takes time to get comfortable with so we wouldn’t be perfect at estimating and planning right away. With that said, I didn't attempt anything fancy. My prescription of what to do to get going with Scrum followed standard Scrum agile estimation and planning practices, beginning with the Product Backlog.



The iteration planning session is where the rubber meets the road as testers and developers break down a feature into its constituent tasks.
The Product Backlog is the indispensable element of Scrum from which everything else flows. This is the Scrum term for the list of features or stories that the business wants to implement and it is the source of the work commitments made by the development team. Making a firm commitment to getting a particular package of work completed in a sprint is a central tenet of Scrum. Without an up-to-date, prioritized product backlog, the development team has no guidance as to what work to undertake.

Once the Product Backlog was in place, I suggested a story point estimation session, which would give us a sense of the size of the various features being requested. Then the backlog would go back to the business to see if, based upon the relative estimated size of the various features, whether there was a preference to shuffle priorities. For example, perhaps the business would prefer that we knock off a few smaller items before a particular larger feature.

The iteration planning session is where the rubber meets the road as testers and developers break down a feature into its constituent tasks. Once the tasks are broken out and estimated they would be loaded into the Scrum Masters sprint workbook and we could see how the task hours added up. If more work was committed too than looked like it would fit then we would return the sprint to the backlog. If we could get to the work then it would be pulled back into the sprint, otherwise, it would be reprioritized for possible work in the next sprint.

Since the remaining operational activities of the sprint took less explanation and prompted less discussion I went through them pretty quickly. I did emphasize repeatedly that getting up to speed with Scrum would require some time. This gradual improvement notion didn't ruffle any feathers but perhaps a more critical audience would have grilled me as to how much time and when would Scrum "be working right."

The CTO was on board with this exercise and we were able to get a quick round trip of the backlog so we could begin our iteration planning. We chose to do a longer iteration for our first Scrum because there were a couple of larger features that we wanted to complete; in hindsight I think that we might have been better off starting with a shorter sprint. The key obstacle to initiating a shorter sprint schedule was the perception that the overhead of estimating and planning meetings was too high. This concern has already diminished as the value of the planning and task break outs has become clear but it was a significant issue at the start.

Achieving a Rhythm
At this point in our maturation as an organization using Scrum (3rd sprint) we're much more cognizant of what the issues were that prevented us from completing the work we wanted to accomplish in the first sprint. We have a variety of incoming queues of work. It is extremely challenging to prioritize them because the work supports different aspects of growing and stabilizing a rapidly evolving product. Scrum provides a robust and reliable mechanism to see the progress of our efforts and understand the trade-offs that are implicit in the choices the business makes. The metrics that the Scrum workbook provides are already indispensable tools in how the business makes decisions about what it can accomplish. While we're a few sprints away from achieving "a rhythm" I believe we're heading in the right direction.



Doug Tillman is a veteran Java and Python developer turned Scrum Master.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap