zzScrum (development)

 

http://en.wikipedia.org/wiki/Scrum_(development)

Scrum (development)

From Wikipedia, the free encyclopedia

Jump to: navigation, search

For other uses, see Scrum.

Software development process

Activities and steps

Requirements | Architecture | Design | Implementation | Testing | Deployment

Models

Agile | Cleanroom | Iterative | RAD | RUP | Spiral | Waterfall | XP | Scrum

Supporting disciplines

Configuration management | Documentation | Software quality assurance (SQA) | Project management | User experience design

Scrum is a project management method for agile software development.

The approach was first described by Hirotaka Takeuchi and Ikujiro Nonaka in The New New Product Development Game (Harvard Business Review, Jan-Feb 1986). They noted that projects using small, cross-functional teams historically produce the best results, and referred to this as the "rugby approach". In 1991, DeGrace and Stahl, in Wicked Problems, Righteous Solutions^[1] referred to this approach as Scrum, a rugby term mentioned in the article by Takeuchi and Nonaka. Ken Schwaber used an approach that led to Scrum at his company, Advanced Development Methods, in the early 1990s. At the same time, Jeff Sutherland developed a similar approach at Easel Corporation and was the first to call it Scrum^[2]. Sutherland and Schwaber jointly presented a paper describing Scrum at OOPSLA '96 in Austin, its first public appearance. Schwaber and Sutherland collaborated during the following years to merge the above writings, their experiences, and industry best practices into what is now known as Scrum. Schwaber teamed up with Mike Beedle in 2001 to write up the method in the book Agile Software Development with SCRUM.

Although Scrum was intended to be for management of software development projects, it can be used in running software maintenance teams, or as a program management approach: Scrum of Scrums.

Contents

[hide]

• 1 Characteristics of Scrum
• 2 Scrum Roles
  • 2.1 "Pig" Roles
  • 2.2 "Chicken" Roles
• 3 The Scrum meeting
• 4 Documents
  • 4.1 Product backlog
  • 4.2 Sprint backlog
  • 4.3 Burn down
• 5 Adaptive project management
• 6 Solo Scrum
• 7 Scrum terminology
• 8 Sources
• 9 See also
  • 9.1 Other Agile methods
• 10 External links
• 11 References

//

[edit] Characteristics of Scrum

The Scrum process

Scrum is a process skeleton that includes a set of practices and predefined roles. The main roles in scrum are the ScrumMaster who maintains the processes and works similar to a project manager, the Product Owner who represents the stakeholders and the Team which includes the developers.

During each sprint, a 15-30 day period (length decided by the team), the team creates an increment of shippable software. The set of features that go into each sprint come from the product backlog, which is a prioritized set of high level requirements of work to be done. What backlog items go into the sprint is determined during the sprint planning meeting. During this meeting the Product Owner informs the items in the product backlog that he wants completed. The team then determines how much of this they can commit to complete during the next sprint.^[3]

During the sprint, the team completes the fixed set of items called backlog items. During the sprint no one is able to change the backlog, which means that the requirements are frozen for sprint.

[edit] Scrum Roles

Several roles are defined in Scrum; these are divided into two groups; pigs and chickens, based on a joke about a pig and a chicken.^[3]

A pig and a chicken are walking down a road. The chicken looks at the pig and says, "Hey, why don't we open a restaurant?" The pig looks back at the chicken and says, "Good idea, what do you want to call it?" The chicken thinks about it and says, "Why don't we call it 'Ham and Eggs'?" "I don't think so," says the pig, "I'd be committed but you'd only be involved."

So the pigs are committed to building software regularly and frequently, while everyone else are chickens that are interested in the project but are really irrelevant because if it fails they're not a pig, that is they weren't the ones that committed to doing it. The needs, desires, ideas and influences of the chicken roles are taken into account, but not in any way letting it affect or distort or get in the way of the actual Scrum project.

[edit] "Pig" Roles

Pigs are the ones committed to the project and the Scrum process; they are the ones with "their bacon on the line".

Product Owner

The Product Owner represents the voice of the customer. They ensure that the Scrum Team works with the right things from a business perspective. The Product Owner writes User Stories, prioritizes them, then places them in the Product Backlog.

ScrumMaster (or Facilitator)

Scrum is facilitated by a ScrumMaster, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal. The ScrumMaster is not the leader of the team (as they are self-organizing) but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended. The ScrumMaster is the enforcer of rules and sprints of practice.

Scrum Team

A small team of 5-9 people with cross-functional skills to do the actual work (designer, developer etc.).

[edit] "Chicken" Roles

Chicken roles are not part of the actual Scrum process, but must be taken into account. An important aspect of Agile approach is the practice of involving users, business and stakeholders into part of the process. It is important for these people to be engaged and provide feedback into the outputs for review and planning of each sprint.

Users

The software is being built for someone! Never forget that software that is not used is like a tree falling in the forest - was it ever written?

Stakeholders

The people that will enable the project, but not directly involved in the process. This includes Executives.

Consulting Experts

These are people who provide expertise that is not required on every sprint. Often these chickens will become a pig as part of the Scrum Team during some sprints.

[edit] The Scrum meeting

Each day during the sprint, a project status meeting is arranged. This is called a scrum. The scrum has specific guidelines:

• The meeting starts precisely on time with team-decided punishments for tardiness (e.g. money, push-ups, hanging a rubber chicken around your neck)
• All are welcome, but only "pigs" may speak
• The meeting is timeboxed at 15 minutes regardless of the team's size
• All attendees should stand
• The meeting should happen at the same location and same time every day

During the meeting, each team member answers three questions^[3]:

• What have you done since yesterday?
• What are you planning to do by tomorrow?
• Do you have any problems preventing you from accomplishing your goal? (It is the role of the ScrumMaster to remember these impediments.)

After each sprint a brief sprint retrospective is held, at which all team members reflect about the past sprint. The purpose of the retrospective is to make continuous process improvement. This meeting is timeboxed at four hours.

Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication across all team members and disciplines that are involved in the project.

A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that fundamentally empirical challenges cannot be addressed successfully in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach – accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly and respond to emerging requirements.

[edit] Documents

[edit] Product backlog

The product backlog is a high-level document for the entire project. It contains broad descriptions of all required features, wish-list items, etc. It is the "What" that will be built. It is open and editable by anyone. It contains rough estimates, usually in days. This estimate helps the Product Owner to gauge the timeline and, to a limited extent, priority (e.g. if "add spellcheck" feature is estimated at 3 days vs 3 months, that may affect the Product Owner's desire).

[edit] Sprint backlog

The sprint backlog is a greatly detailed document containing information about how the team is going to implement the requirements for the upcoming sprint. Tasks are broken down into hours with no task being more than 16 hours. If a task is greater than 16 hours, it should be broken down further. Tasks on the sprint backlog are never assigned, rather tasks are signed-up for by the team members as they like.

[edit] Burn down

Publicly displayed chart showing effort remaining for the current sprint.

[edit] Adaptive project management

Following are some general practices of Scrum:

• Customers become a part of the development team. (i.e. the customer must be genuinely interested in the output.)
• Like all other forms of agile software processes, Scrum has frequent intermediate deliveries with working functionality. This enables the customer to get working software earlier and enables the project to change its requirements according to changing needs.
• Frequent risk and mitigation plans developed by the development team itself. – Risk Mitigation, Monitoring and Management (risk analysis) at every stage and with genuinity.
• Transparency in planning and module development – Let everyone know who is accountable for what and by when.
• Frequent stakeholder meetings to monitor progress – Balanced (Delivery, Customer, Employee, Process) Dashboard updates – Stakeholders' update – You have to have Advance Warning Mechanism, i.e. visibility to potential slippage / deviation ahead of time.
• No problems are swept under the carpet. No one is penalized for recognizing or describing any unforeseen problem.
• Workplaces and working hours must be energized. – "Working more hours" does not necessarily mean "producing more output."

[edit] Solo Scrum

Scrum is based on small teams. It enhances communication between team members. Nevertheless, there is a huge amount of software that is developed by solo programmers. A software system being built by a single programmer can still benefit from some of the Scrum principles such as: a product backlog, a sprint backlog, a sprint and a sprint retrospective. Solo Scrum is an adapted version of Scrum for use by solo programmers.

[edit] Scrum terminology

The following terminology is used in Scrum^[3]:

• Burn Down Chart: Daily progress for a sprint over the sprint's length.
• Product Backlog: A prioritized list of high level requirements.
• Product Owner: The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders.
• ScrumMaster: The person responsible for the Scrum process, making sure it is used correctly and maximizes it benefits.
• Sprint: A time period (usually 2 to 4 weeks) in which development occurs on a set of backlog items that the Team has committed to.
• Sprint Backlog: A list of tasks to be completed during the sprint.
• Team: A cross-functional group of people responsible for managing itself to develop the product.

[edit] Sources

• (PDF) Rising, L., Janoff, N.S. (2000). The Scrum Software Development Process for Small Teams Retrieved March 15, 2007
• (PDF) Schwaber, K. Advanced Development Methods. SCRUM Development Process Retrieved August 15, 2006
• (PDF) Dr. Sutherland, J. (October 2004) Agile Development: Lessons learned from the first scrum Retrieved August 15, 2006
• (video) Jeff Sutherland in Scrum Tuning: Lessons learned from Scrum implementation at Google Retrieved 2007-12-15
• (video) Ken Shwaber in Scrum et al. Retrieved 2008-01-19

[edit] See also

• Kaizen
• List of software development philosophies
• User story
• Cowboy coding
• Agilo for Scrum

[edit] Other Agile methods

• Dynamic System Development Method
• Feature Driven Development
• Extreme programming (XP) - often driven by scrum

[edit] External links

• Scrum in five minutes
• Scrum Alliance
• Scrum et al - Google Techtalk with Ken Schwaber
• Scrum and XP from the Trenches
• Scrum articles directory
• Agile Alliance's Scrum library
• InfoQ.com / Agile - Tracking change and innovation in the enterprise software development community (News, Articles, Books, Video)
• Agilo for Scrum (Open Source Scrum Tool, Scrum Software)
• Scrum and XP from the Trenches by Henrik Kniberg. A 130-page PDF book describing in detail how Scrum and XP can be implemented from a practical perspective
• Ken Schwaber lecturing at Google video Effective summary with the best ideas of Scrum
• The New New Product Development Game by Takeuchi and Nonaka. The paper that started it all.
• Scrum Delivers or Scrum and the Toyota Way by Boris Gloger. This paper maps the principles of Toyota explained by Liker, with the practices of Scrum.

[edit] References

1. ^ Peter DeGrace, Leslie Hulet Stahl, Wicked problems, righteous solutions, 1990, ISBN 0-13-590126-X
2. ^ Jeff Sutherland, AGILE DEVELOPMENT: LESSONS LEARNED FROM THE FIRST SCRUM, 2004 [1]
3. ^ ^{a b c d} Agile Project Management with Scrum, Ken Schwaber, Microsoft Press, January 2004, 163pp, ISBN 0-7356-1993-X