Blog

Scrum is a framework for solving complex adaptive problems with high levels of unknowns, uncertainties, or risks around what to build or how to build it. Scrum involves a cross-functional and self-managing Scrum team that uses empiricism to build products iteratively and incrementally to reduce risk and deliver early and often. The Scrum team uses the Scrum events to regularly inspect and adapt the 3 Scrum artifacts.

Scrum is founded on Lean thinking and empiricism. Lean thinking reduces waste and focuses on essentials. Empiricism asserts that knowledge comes from experiences. That is, do the work, see how it went, and then decide what to do next based on what was just learned. The 3 pillars of empiricism are transparency, inspection, and adaptation. Transparency into the work is necessary in order for the team to properly inspect the work and adapt accordingly. Regular timeouts are also necessary for the team to stop what they are doing, pause, look back at what just happened, and then decide how to move forward. In Scrum, the Product Increment provides transparency into what has been built so far. The Product Backlog provides transparency into what still needs to be built. The Sprint Backlog provides transparency into what is currently being built. The 4 events of Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective within the containing Sprint event provide the opportunity for the team to regularly inspect and adapt based on the transparency provided by the updated artifacts.

The events in Scrum are time-boxed. Once the end of the time-box is reached, the event ends and the team moves on (irrespective of whether the work to be done is completed or not). Based on the size of the Sprint, each event has a recommended maximum time limit. For a 1-week Sprint, Sprint Planning is timeboxed to 2 hours, Daily Scrum to 15 min/day, Sprint Review to 1 hour, and Sprint Retrospective to 45 min. The timebox limits increase proportionally for longer Sprints.

When the team has a short period of time to do something, the team prioritizes and figures out what’s most important to work on right now. The team breaks down large and complex work to fit in the timebox. The team focuses on finishing and delivering the work within the timebox. The team gets the opportunity to get feedback at the end of each timebox. With frequent feedback, the team adjusts and continuously improves to become more effective. These are all benefits of timeboxing.

Scrum is just a framework, which means it is purposely incomplete. It is not a prescriptive methodology with detailed instructions. Instead, it is just a lightweight guide that provides guard rails to keep teams heading in the right direction and prevents them from falling off. The Scrum rules, team structure, way of working, accountabilities, artifacts, and events, are set up to keep the team on track by regularly inspecting and adapting. If Scrum is only partially implemented, the guard rails might crack, and the team will not realize the benefits that Scrum delivers.

Based on a team’s context, organization, type of product being built, unique challenges, and their latest observations and learnings, a team may employ additional practices and techniques within the framework. What works for 1 team in 1 organization might not work for another team in another organization. It’s all contextual and there is no 1 best way of using Scrum. For those reasons, Scrum is said to be lightweight and simple to understand, yet difficult to master. Lightweight and simple to understand because the Scrum Guide is less than 20 pages and just lays out Scrum theory along with the Scrum accountabilities, artifacts, and events. It’s difficult to master because Scrum requires a change in how organizations and teams are traditionally structured and how they approach work, and many are resistant to change and find the necessary changes too disruptive. And that’s Scrum. A framework used for solving complex adaptive problems. There is no hiding in Scrum. A team has a short period of time to deliver value. If they can great! If they cannot, it will be obvious and transparent as to why. Scrum on its own, will not solve the team’s problems, but instead, Scrum shines a bright light on the team and organizational impediments. It’s up to the team and the organization to decide what to do about those impediments and how to address them for continued success.

For more details, sign up for an upcoming foundational ScrumMaster® (CSM®) class or a Certified Product Owner® (CSPO®) class or Certified Scrum Developer® (CSD®) class.

Next check out the entire Scrum in a Nutshell series: