Jump to content

Scrum (software development)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Humu (talk | contribs) at 12:51, 27 August 2007 (→References). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

For other uses, see Scrum.

Scrum is an agile software development method for project management.

Scrum background

The approach was first described by Takeuchi and Nonaka in "The 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 likened these high-performing teams to the scrum formation in Rugby. In 1991, DeGrace and Stahl, in "Wicked Problems, Righteous Solutions" referred to this approach as Scrum. Ken Schwaber used an approach that led to Scrum at his company, Advanced Development Methods, in the early 1990's. At the same time, Jeff Sutherland, John Scumniotales, and Jeff McKenna developed a similar approach at Easel Corporation and were the first to call it Scrum. Jeff Sutherland and Ken jointly presented a paper describing Scrum at OOPSLA'96 in Austin, its first public appearance. Ken and Jeff collaborated during the following years to merge the above writings, their experiences, and industry best practices into what is now known as Scrum.

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

Characteristics of Scrum

  • A product backlog of prioritized work to be done;
  • Completion of a fixed set of backlog items in a series of short iterations or sprints;
  • A brief daily meeting or scrum, at which progress is explained, upcoming work is described and impediments are raised.
  • A brief sprint planning session in which the backlog items for the sprint will be defined.
  • A brief sprint retrospective, at which all team members reflect about the past sprint.

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-organising) but acts as a buffer between the team and any distracting influences.

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 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.

Adaptive project management

It is uncommon for a service provider to specify all the product characteristics and product requirements in a single shot. Many times, it becomes an incremental delivery or the software is not acceptable to the customer. Sometimes the customer might not be the end-user. In this scenario, complications result. The end user gives an "A" to the customer, and the customer gives an "A+-" to the service provider. In these kinds of complex scenarios, the only thing that rescues us is the lightweight process.

Following are some practices for the Scrum:

  • Customers become a part of the development team. (i.e., Customer must be genuinely interested in the output.) – VOC – In SDLC parlance, validate what you have planned to develop.
  • Frequent intermediate deliveries with working functionality. – Incremental development and releases (may be internal only) – providing you an opportunity to validate and verify at shorter intervals rather than only at the end; thereby, providing you time to fix, and reducing the cost to fix.
  • Frequent risk and mitigation plans developed by the development team itself. – Risk Mitigation, Monitoring and Management (risk analysis) at every stage and with genuinity – Make it live, and continuous activity.
  • A daily status discussion (Standup meetings) asking each team member:
    • What have you done since yesterday? (accomplishments)
    • What are you planning to do by tomorrow? (to be accomplished)
    • Do you have any problems preventing you from accomplishing your goal? (issues/concerns/risks)
  • 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."

Scheduling daily status discussions

A popular time for the daily status discussion is after the lunch break. Doing it in the morning may be troublesome especially if the team is working in a company using flextime. These status discussions don't take long, so one way is to do standup meetings where the team meets in front of a whiteboard. Because people tend to get tired after lunch, having a lively standup meeting at that time may keep their energy up. Because everybody has already been working that day, their minds are focused on the job and not on their personal issues.

Solo Scrum

Scrum is based on small teams. It enhances communication between team members. Nevertheless, there is a huge amount of software that is being 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.

Scrum terminology

Scrum Master: The person or persons in charge of the tracking and the daily updates for the scrum (equivalent to a project manager). Sometimes referred to as a Scrum Facilitator.
Scrum Team: A cross-functional team (developers, B.A.s, DBAs, and testers) responsible for developing the product.
Product Owner: The person responsible for maintaining the Product Backlog via continuous interaction with Clients and Stakeholders.
Product Backlog: The stories to be completed.
Story: A customer focused description of valued functionality.
Sprint: A time period (usually 2 to 4 weeks) in which development occurs on a set of stories that the team has committed to.
Burn Down Chart: Daily progress for a sprint over the sprint's length.

Other non-professional Scrum Terms

Scrum Toon: A cartoon used to explain scrum and its intricacies on teams where scrum is first implemented.
Pigs: Those who are members of the Scrum Team committed to the tasks (developers, B.A.s, DBAs, and testers).
Chickens: Those who are involved but do not have tasks (Project Owners, Scrum Masters, Stakeholders, Clients, etc...).
Pig & Chicken are used to describe the relationship between all persons associated with a product. The names, while strange, are derived from an allegory about the commitment involved in creating a ham and egg breakfast: the chicken is involved, but the pig is commited.

Books

Challenges to Adoption of Scrum

Many organizations are resistant to Scrum and other Agile methodologies. The power of the ideas and the associated change management effort impact how effectively companies can adopt Scrum. The increased transparency experienced from using this methodology forces accountability, responsibility, prioritization discussions, trade-offs, and often scope reduction. Scrum requires that managers behave differently than in the past. Instead of reviewing status reports, managers should attend Sprint reviews and retrospectives. Instead of waiting for team members to prepare and present updates, management should go to the project room and see the project's task board and burn down chart.

One wiki writer suggests that Scrum's adaptability allows it to be introduced "stealthily". E.g. using three steps:

  • Schedule a demo of the software with the customer/client a month from now
  • As a team, take a month to get your software ready for the demo – actually functioning, not just screen shots
  • At the demo, get feedback and use it to guide the next month's development work

While this might work, it does not address the fundamental changes in behavior that the project manager, the team, and management should commit to and undertake. Stealth mode implementations often cause "organizational antibodies" to form that will resist and undermine the changes.

Any disadvantages?

Any and all methodoligies have their pros and cons. Are there any disadvantages using Scrum?

Scrum gives much power to Scrum Team, so having inexperienced or heterogenious team brings in more uncertaintity. However, since a Sprint consists of a rather small amount of work, the Scrum Master can react to any skill related problem quite fast.

The Product Owner definies priorisation by using the Product Backlog, so in a sprint planning session the most important features will be selected. This may cause extra work to be done, because quite often there are critical - but somehow unnoticed modules or services to be implemented. The Scrum Team must handle situation like this with care and build a stub and may be reduce some functionality for current sprint.

References

  1. ^ http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf
  1. Agile Software Development with Scrum, Ken Schwaber & Mike Beedle, Prentice Hall, ISBN 0-13-067634-9

Sources

See also

Other Agile methods

Scrum in general project management

Retrieved from "https://en.wikipedia.org/w/index.php?title=Scrum_(software_development)&oldid=153942824"