Tecnico

THE SCRUM PRIMER
An Introduction to Agile Project Management with Scrum
By Pete Deemer and Gabrielle Benefield
Version 1.04

goodagile>
scrum training in india and asia | www.goodagile.com

Pete Deemer is Chief Product Officer, Yahoo! Emerging Markets Group. Gabrielle Benefield is Senior Director of Agile Development at Yahoo! Inc. They lead Yahoo!’s large-scale global adoption of Scrum.A note to readers: There are many concise descriptions of Scrum available online, and this primer aims to provide the next level of detail on the practices. It is not intended as the final step in a Scrum education; teams that are considering adopting Scrum are advised to equip themselves with Ken Schwaber’s Agile Project Management with Scrum or Agile Software Development with Scrum, and takeadvantage of the many excellent Scrum training and coaching options that are available; full details are at scrumalliance.org. Our thanks go to Ken Schwaber, Dr. Jeff Sutherland, and Mike Cohn for their generous input. © 2007 Pete Deemer and Gabrielle Benefield

2

Traditional Software Development
The traditional way to build software, used by companies big and small, is commonly known as“The Waterfall”. There are many variants, but it typically begins with a detailed planning phase, where the end product is carefully thought through, designed, and documented in great detail. The tasks necessary to execute the design are determined, and the work is planned using tools like Gantt charts and programs like Microsoft Project. The team arrives at an estimate of how long the project willtake by adding up detailed estimates of the individual steps involved. Once stakeholders have thoroughly reviewed the plan and provided their approvals, the team starts to build. Team members complete their specialized portion of the work, and then hand it off to others in production-line fashion. Once the work is complete, it is delivered to a Quality Assurance organization, which completestesting prior to the product reaching the customer. Throughout the process, strict controls are placed on deviations from the plan, to ensure that what is produced is actually what was designed. This approach has strengths and weaknesses. Its great strength is that it is supremely logical: think before you build, write it all down, follow a plan, and keep everything as organized as possible. It has justone great weakness: humans are involved. For example: this approach requires that the good ideas all come at the beginning of the development cycle, where they can be incorporated into the plan. But as we all know, good ideas appear spontaneously throughout the process – in the beginning, the middle, and sometimes even the day before launch, and a process that doesn’t permit change will stiflethis innovation. With the Waterfall approach, a great idea late in the development cycle is not a gift, it’s a threat. The Waterfall approach also places a great emphasis on writing things down as a primary method for communicating critical information. The very reasonable assumption is that if I can write down on paper as much as possible of what’s in my head, it will more reliably make it into thehead of everyone else on the team; plus, if it’s on paper, there is tangible proof that I’ve done my job. The reality, though, is that most of the time, these highly detailed 50-page requirements documents just don’t get read. And that’s probably just as well, because when they do get read, the misunderstandings are often compounded. A written document is an incomplete abstraction of a picture Ihave in my head; when you read that document, you create yet another abstraction, which is now two steps away from what I’m really thinking of. It should come as no surprise that serious misunderstandings would occur. Something else that happens when you have humans involved is the hands-on “aha” moment – the first time that you actually use the working product, and you immediately think of 20...