“I have a dream” was the famous public speech delivered by American civil rights activist Martin Luther King Jr. during March on Washington for jobs and freedom on August 28, 1963. I also have a dream for Scrum in Healthcare. I am thinking of us working together in self-organized and cross-functional teams for the patient's sake where hierarchy is replaced by teams designed to optimize, with flexibility, open creativity, and higher productivity to deliver changes in Healthcare systems/processes iteratively and incrementally, maximizing opportunities. Can Healthcare learn a lesson or two from the Scrum framework for developing, delivering, and sustaining complex products? The term “Scrum” was first introduced by Dr. Takeuchi and Dr. Nonaka in 1986 in the article The New Product Development Game published in the Harvard Business. Let’s take a closer look at the Scrum framework formalized by Ken Schwaber and Jeff Sutherland in 1995 based on Scrum guide©.
Definition of Scrum
Scrum is a framework (see below) within which the team can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum is lightweight, simple to understand, but difficult to master. Scrum continuously improve the product, the team, and the working environment. The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage. The rules of Scrum bind together the roles, events, and artifacts, governing the relationships and interaction between them.
Scrum Pillars and Values
Scrum also uses Agile Manifesto values and principles.
While there is value in the items on the right, Agile Manifesto value the items on the left more.
In both instances, just imagine if I replace the words like “software” by healthcare systems/processes or “developers” by engaged healthcare team consisting of both clinical and nonclinical individuals.
The Scrum Team
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.
The Product Owner
Is responsible for maximizing the value of the product resulting from the work of the Development Team. He is the sole person also responsible for managing the Product Backlog. For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog.
The Development Team
The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of "Done" product at the end of each Sprint. A "Done" increment is required at the Sprint Review. Only members of the Development Team create the Increment. Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness. Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Development Team members decrease interaction and result in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to be useful.
The Scrum Master
Is responsible for promoting and supporting Scrum by helping everyone understand Scrum theory, practices, rules, and values. The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.
Scrum Events
Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. All events are time-boxed events, such that every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process. These events are specifically designed to enable critical transparency and inspection.
The Sprint
The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product increment is created. A new Sprint starts immediately after the conclusion of the previous Sprint. Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective. Each Sprint has a goal of what is to be built, a design, and a flexible plan that will guide building it, the work, and the resultant product increment. A Sprint can be canceled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.
Sprint Planning
The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team. Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box. During Sprint Planning the Scrum Team also crafts a Sprint Goal.
Sprint Goal
The Sprint Goal is an objective set for the Sprint that can be met through the implementation of the Product Backlog. It provides guidance to the Development Team on why it is building the increment. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint.
Daily Scrum
The Daily Scrum is a 15-minute time-boxed event for the Development Team. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion-based. The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work. Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge. This is a key inspect and adapt meeting.
Sprint Review
A Sprint Review is held at the end of the Sprint to inspect the increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the increment is intended to elicit feedback and foster collaboration. This is at most a four-hour meeting for one-month Sprints. The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.
Sprint Retrospective
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is at most a three-hour meeting for one-month Sprints. The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process, and practices to make it more effective and enjoyable for the next Sprint. By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. The Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.
Scrum Artifacts
Scrum’s artifacts represent work or value to provide transparency and opportunities for inspection and adaptation. Artifacts defined by Scrum are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact.
Product Backlog
The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when "Done". Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team.
Sprint Backlog
The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next increment and the work needed to deliver that functionality into a "Done" increment. To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting. The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.
Product increment
The increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new increment must be "Done," which means it must be in useable condition and meet the Scrum Team’s definition of "Done". The increment is a step toward a vision or goal.
End Note
Scrum is free and offered in the complete Scrum guide. Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
In closing, I’m not suggesting replacing existing Healthcare systems/processes by Scrum framework, but to make a case for the Scrum framework in Healthcare. In this vibrant time, we're called to look behind what we have seen but to unseen or unimaginable where dreams come true even in Healthcare. Do you have a dream?
Marek
© 2017 Ken Schwaber and Jeff Sutherland.
Offered for license under the Attribution Share-Alike license of Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.