Scrum

Scrum is a framework for project management with an initial emphasis on software development, although it has been used in other fields including research, sales, marketing and advanced technologies. It is designed for teams of ten or fewer members who break their work into goals that can be completed within time-boxed iterations, called sprints, no longer than one month and most commonly two weeks. The scrum team assesses progress in time-boxed daily meetings of 15 minutes or fewer, called daily scrums (a form of stand-up meeting). At the end of the sprint, the team holds two further meetings: one sprint review intended to demonstrate the work done for stakeholders and elicit feedback, and one sprint retrospective intended to enable the team to reflect and improve.

The term scrum is borrowed from rugby, where it is a formation of players. The term scrum was chosen by the paper's authors because it implies teamwork.[4] The software development term scrum was first used in a 1986 paper titled "The New New Product Development Game" by Hirotaka Takeuchi and Ikujiro Nonaka.[5][6] The paper was published in the Jan 1986 issue of Harvard Business Review.

Scrum is occasionally seen written in all-capitals, as SCRUM.[7] While the word itself is not an acronym, its capitalized styling likely comes from an early paper by Ken Schwaber[8] that capitalized SCRUM in its title.[9][10]

While the trademark on the term scrum itself has been allowed to lapse, it is now deemed as a generic trademark owned by the wider community rather than an individual.[11]

Key ideas

Scrum is a lightweight, iterative, and incremental framework for developing, delivering, and sustaining complex products.[12][13] The framework challenges assumptions of the traditional, sequential approach to product development, and enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members, as well as daily face-to-face communication among all team members and disciplines involved.

A key principle of scrum is the dual recognition that customers will change the scope of what is wanted (often called requirements volatility[14]) and that there will be unpredictable challenges—for which a predictive or planned approach is not suited. These changes come from a variety of sources, but according to scrum, understanding why is irrelevant, and change should simply be accepted, embraced, and analyzed for benefits.

History

Hirotaka Takeuchi and Ikujiro Nonaka introduced the term scrum in the context of product development in their 1986 Harvard Business Review article, 'The New New Product Development Game'.[15] Takeuchi and Nonaka later argued in The Knowledge Creating Company[16] that it is a form of "organizational knowledge creation, […] especially good at bringing about innovation continuously, incrementally and spirally".

The authors described a new approach to commercial product development that would increase speed and flexibility, based on case studies from manufacturing firms in the automotive, photocopier, and printer industries.[15] They called this the holistic or rugby approach, as the whole process is performed by one cross-functional team across multiple overlapping phases, in which the team "tries to go the distance as a unit, passing the ball back and forth".[15] (In rugby football, a scrum is used to restart play, as the forwards of each team interlock with their heads down and attempt to gain possession of the ball.[17])

The scrum framework was based on research by Schwaber with Babatunde Ogunnaike at DuPont Research Station and University of Delaware.[9] Ogunnaike advised that attempts to develop complex products, such as software, that weren't based in empiricism were doomed to higher risks and rates of failure as the initial conditions and assumptions change. Empiricism, using frequent inspection and adaptation, with flexibility and transparency is the most suitable approach.

In the early 1990s, Ken Schwaber used what would become scrum at his company, Advanced Development Methods; while Jeff Sutherland, John Scumniotales and Jeff McKenna developed a similar approach at Easel Corporation, referring to it using the single word Scrum.[18]

Sutherland and Schwaber worked together to integrate their ideas into a single framework, scrum. They tested scrum and continually improved it, leading to their 1995 paper,[19] contributions to the Manifesto for Agile Software Development in 2001,[20] and the worldwide spread and use of scrum since 2002.

In 1995, Sutherland and Schwaber jointly presented a paper describing the scrum framework at the Business Object Design and Implementation Workshop held as part of Object-Oriented Programming, Systems, Languages & Applications '95 (OOPSLA '95) in Austin, Texas.[19] Over the following years, Schwaber and Sutherland collaborated to combine this material—with their experience and evolving good practice—to develop what became known as scrum.[3]

In 2001, Schwaber worked with Mike Beedle to describe the method in the book, Agile Software Development with Scrum.[21] Scrum's approach to planning and managing product development involves bringing decision-making authority to the level of operation properties and certainties.[9]

In 2002, Schwaber with others founded the Scrum Alliance[22] and set up the Certified Scrum accreditation series. Schwaber left the Scrum Alliance in late 2009 and founded Scrum.org[23] which oversees the parallel Professional Scrum accreditation series.[24]

Scrum Team

The fundamental unit of scrum is a small team of people, consisting of a product owner, a scrum master, and developers. The team is self-managing, cross-functional and focuses on one objective at a time: the product goal.

Product owner

The product owner, representing the product's stakeholders and the voice of the customer (or may represent the desires of a committee[25]), is responsible for delivering good business results.[26] Hence, the product owner is accountable for the product backlog and for maximizing the value that the team delivers.[25] The product owner defines the product in terms of customer-centric outcomes (typically - but not limited to - user stories), adds them to the product backlog, and prioritizes them based on importance and dependencies.[27] A scrum team should have only one product owner (although a product owner could support more than one team)[28] and it is strongly advised against combining this role with the role of the scrum master. The product owner should focus on the business side of product development and spend the majority of time liaising with stakeholders and the team. The product owner does not dictate how the team reaches a technical solution, but seeks consensus among team members.[29][30][31][better source needed] This role is crucial and requires a deep understanding of both sides: the business and the engineers (developers) in the scrum team. Therefore, a good product owner should be able to communicate what the business needs, ask why they need it (because there may be better ways to achieve that), and convey the message to all stakeholders including the developers using technical language, as required. The product owner uses scrum's empirical tools to manage highly complex work while controlling risk and achieving value.

Communication is a core responsibility of the product owner. The ability to convey priorities and empathize with team members and stakeholders is vital to steer product development in the right direction. The product owner role bridges the communication gap between the team and its stakeholders, serving as a proxy for stakeholders to the team and as a team representative to the overall stakeholder community.[32][33]

As the face of the team to the stakeholders, the following are some of the communication tasks of the product owner to the stakeholders:[34]

  • Define and announce releases.
  • Communicate delivery and product status.
  • Share progress during governance meetings.
  • Share significant RIDAs (risks, impediments, dependencies, and assumptions) with stakeholders.
  • Negotiate priorities, scope, funding, and schedule.
  • Ensure that the product backlog is visible, transparent and clear.
  • Ability to relate is a key attribute for a product owner to have—the ability to put one's self in another's shoes. A product owner converses with different stakeholders with a variety of backgrounds, job roles, and objectives - and should be able to appreciate these different points of view. To be effective, it is wise for a product owner to know the level of detail the audience needs. The developers need thorough feedback and specifications so they can build a product up to expectation, while an executive sponsor may just need summaries of progress. Providing more information than necessary may lose stakeholder interest and waste time. A direct means of communication is preferred by seasoned product owners.[28]

A product owner's ability to communicate effectively is also enhanced by being skilled in techniques that identify stakeholder needs, negotiate priorities between stakeholder interests, and collaborate with developers to ensure effective implementation of requirements.

Developers

The developers carry out all work required to build increments of value every sprint.[27]

The term developers[3] refers to anyone who plays a role in the development and support of the system or product, and can include researchers, architects, designers, data specialists, statisticians, analysts, engineers, programmers, and testers, among others.[35] However, due to the confusion that can arise when some people do not feel the term 'developer' applies to them, they are often referred to just as team members.

The team is self-organizing. While no work should come to the team except through the product owner, and the scrum master is expected to protect the team from distractions, the team are encouraged to interact directly with customers and/or stakeholders to gain maximum understanding and immediacy of feedback.[27]

Scrum master

Scrum is facilitated by a scrum master, who is accountable for removing impediments to the ability of the team to deliver the product goals and deliverables.[36] The scrum master is not a traditional team lead or project manager but acts as a barrier between the team and any distracting influences. The scrum master ensures that the scrum framework is followed by coaching the team in scrum theory and concepts, often facilitating key sessions, and encourages the team to grow and to improve. The role has also been referred to as a team facilitator or servant-leader to reinforce these dual perspectives.

The core responsibilities of a scrum master include (but are not limited to):[37]

  • Helping the product owner maintain the product backlog in a way that ensures the needed work is well understood so the team can continually make forward progress
  • Helping the team to determine the definition of done for the product, with input from key stakeholders
  • Coaching the team, within the scrum principles, in order to deliver high-quality features for its product[38]
  • Educating key stakeholders and the rest of the organization on scrum (and possibly agile) principles
  • Helping the scrum team avoid or remove impediments to its progress, whether internal or external to the team
  • Promoting self-organization and cross-functionality within the team
  • Facilitating team events to ensure regular progress
  • The scrum master helps people and organizations adopt empirical and lean thinking, leaving behind hopes for certainty and predictability.

One of the ways the scrum master role differs from a project manager is that the latter may have people management responsibilities and the scrum master does not. A scrum master provides a limited amount of direction since the team is expected to be empowered and self-organizing.[39] Scrum does not formally recognize the role of project manager, as traditional command and control tendencies would cause difficulties.[40]

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License