Scrum (management)

From Wikipedia, the free encyclopedia

You have new messages (last change).
It has been suggested that this article or section be merged with Scrum (development). (Discuss)

Scrum is an agile method for project management. Scrum was named as a project management style in auto and consumer product manufacturing companies by Takeuchi and 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 likened these high-performing teams to the scrum formation in Rugby. Jeff Sutherland, John Scumniotales, and Jeff McKenna documented, conceived and implemented Scrum as it is described below at Easel Corporation in 1993, incorporating team management styles noted by Takeuchi and Nonaka. In 1995, Ken Schwaber formalized the definition of Scrum and helped deploy it worldwide in software development.

Its intended use is for management of software development projects, and it has been successfully used to "wrap" Extreme Programming and other development methodologies. However, it can theoretically be applied to any context where a group of people need to work together to achieve a common goal - such as setting up a small school, scientific research projects or planning a wedding.

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.

Contents

[edit] Characteristics of Scrum

  • A living backlog of prioritized work to be done;
  • Completion of a largely 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 planning session in which the backlog items for the sprint will be defined.
  • A brief heartbeat 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 productivity buffer between the team and any destabilising influences.

Scrum enables the creation of self-organising teams by encouraging verbal communication across all team members and across all 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 "process control" 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 respond in an agile manner to emerging challenges.

Notably missing from Scrum is the "cookbook" approach to project management exemplified in the Project Management Body of Knowledge or Prince2 - both of which have as their goal quality through application of a series of prescribed processes.

[edit] Simplified Scrum

Many organizations are resistant to methodologies introduced at a grass-roots level. However, 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

With this process the essence of the Scrum patterns is implemented and can be built upon.

[edit] 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. No one wants to pin down a customer who is not clear on their requirements. 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.)
  • Frequent intermediate deliveries with working functionality.
  • Frequent risk and mitigation plans developed by the development team itself.
  • Daily status discussion with the team.
  • A daily discussion asking each team member:
    • 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?
  • Transparency in planning and module development.
  • Frequent stakeholder meetings to monitor progress
  • No problems are swept under the carpet. No one is penalized for recognizing or describing any unforseen problem.
  • Workplaces and working hours must be energized. "Working more hours" does not necessarily mean "producing more output."

[edit] 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.

[edit] See also

[edit] Books

[edit] External links

Retrieved from "http://en.wikipedia.org../../../s/c/r/Scrum_%28management%29.html"