Scrum framework at a glance
Scrum has become so popular, that many people confuse Scrum with agile. Needless to say, Scrum is not the same as agile, but one of the successful agile frameworks with a great impact on how agile teams operate.
The greatest merit of Scrum is that it created an easy-to-understand model for agile teams that includes practices, tools, and roles to navigate the organizational change towards agility.
If you're looking to read more about it, the most credible source of the Scrum framework is the Scrum Guide.
The theory behind Scrum
Scrum is built on the empirical process control theory, which claims that following a prescribed process in an uncertain environment is not a guarantee of results. As a consequence, the process must be adjusted as the team learns more about the problem.
This is why Scrum is not a methodology because every team needs to develop its unique system that suits their specific circumstances. Scrum provides the framework that specifies the essential elements and rules every Scrum team should apply.
To facilitate empirical process control, Scrum relies on three main pillars: transparency, inspection, and adaptation.
Transparency means that important aspects of the process must be visible for everyone whose decisions may affect the work. To ensure transparency, Scrum teams manage their work on a shared team board and make various visual representations (such as charts) of the progress publicly visible.
To ensure that the process applied by the team leads to desirable results, the team inspects both the end product and the process that led to the product at regular intervals. Based on the findings of the inspections, the team should adapt their process or product as soon as possible.
Scrum Team
The protagonist of the Scrum framework is the Scrum Team. As the framework borrowed its name from the rugby game, the Scrum Team is similar to a sports team; the members are committed to achieving a goal. The Scrum Team consists of 3-9 motivated team members. In Scrum, the team members are dedicated members which makes being a member of the Scrum team their primary role within the organization.
There is no Scrum without a cohesive team striving to achieve a shared goal.
Within the Scrum Team, the Scrum Guide defines three roles.
Everybody in the Scrum team who works on product development is a developer. Using the term developer for team members emphasizes the collective spirit of the Scrum team: "we're all here together to build a solution, and we all share the responsibility of achieving our goal". Software developers, testers, technical writers, and UX designers are all developers according to the Scrum terminology.
The Product Owner is the navigator of the team. The Product Owner has the best understanding of the business context of the product. The Product Owner knows the answer to the following questions:
- What are the competing solutions?
- What are the desired characteristics of the product from the end user's perspective?
- What elements of the product should be implemented first, and what's next?
It's the Product Owner's duty to develop and articulate a clear vision of the solution.
The Scrum Master is the servant leader of the team. She is the one who fully understands the philosophy and driving forces behind Scrum and knows how to leverage the potential of the Scrum team. It's also the Scrum Master who ensures that the organization around the team understands the dynamics of Scrum and respects the autonomy of the team.
Scrum values
The Scrum framework is a set of values, principles, and practices that guide the Scrum Team on their endeavor to building a successful product.
The latest update of the Scrum Guide adds emphasis to the values that drive the behavior of the members of the Scrum Team.
The five values of Scrum:
- commitment,
- courage,
- focus,
- openness,
- respect.
The presence of those values is vital to unleashing the potential of Scrum.
Scrum artifacts
During their effort in building the product, the Scrum team creates and maintains three artifacts.
- Potentially Releasable Product Increment
- Product Backlog
- Sprint Backlog
Like most agile frameworks, Scrum advocates for an incremental and iterative development approach, that is the team builds the solution up in small increments and refines the product every time they learn something new. The goal is to produce a potentially shippable product increment at the end of each sprint. A product increment is potentially shippable if it meets the quality standards of the team - it's tested - and it's integrated with the existing functionality of the product.
The potentially releasable product increment is the most important artifact in Scrum.
The product backlog is the single source of all work things that the team needs to implement to deliver the product. The product backlog contains functionality that is required by the users, known bugs, functionality improvements, and engineering tasks. It's a constantly evolving and ordered list, that contains its items in implementation order. That is, a backlog item at the top will be implemented sooner than the item below it. The product backlog is visible for everybody (especially for the members of the Scrum team) who make decisions regarding the development. As the team collects everything that needs to get done during the entire product development in the product backlog, the sprint backlog contains everything that the team aims to deliver in the sprint. The sprint backlog is a set of product backlog items selected into the sprint, and elements of the plan the team created to meet the sprint goal.
Events in Scrum
The Scrum Guide defines five events that every Scrum team performs regularly.
- The Sprint
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
All of these events are meant to serve transparency, inspection, and adaptation, the three pillars of Scrum we mentioned before.
To prevent wasting time and to boost focus, all events in Scrum are time-boxed, which means that every event has a maximum duration.
The most iconic element of the Scrum framework is the idea of sprints. The Sprint contains all other events and sets a steady cadence for the team. The length of the sprint sets a maximum latency in delivering new product increments and performing improvements through the inspection and adaptation cycles. Scrum limits the sprint length in one month with the preference of a shorter period. The most popular sprint length among development teams is two weeks.
The team sets their goal for the upcoming sprint and creates a plan to achieve that goal during the sprint planning meeting. It is also the team that creates the initial version of the Sprint Backlog on the Sprint Planning meeting.
The Daily Scrum is a synchronization event for the development team, where the team members plan their work for the next 24 hours and where they review their progress towards the sprint goal. The Daily Scrum meeting is held every day of the Sprint and its duration is limited to 15 minutes.
At the end of the sprint, the team and the stakeholders perform a Sprint Review where they inspect the Product Increment and adjust the Product Backlog based on the findings they uncovered. As a simplification, we can say that the team inspects and evaluates what they built.
After the Sprint Review, the team inspects itself in terms of performance, relationships, processes, and tools. Unlike the Sprint Review, the Sprint Retrospective is a private session for the team, where only team members are present. The Sprint Retrospective meeting reflects on how the team worked.
What to watch for when introducing Scrum?
Scrum scored itself the title of being the most popular agile framework, and for a good reason.
However, despite its unquestionable merits, the Scrum framework leaves many questions unanswered (some intentionally) and also room for misinterpretations.
The Scrum Guide is written in a rather prescriptive tone that creates the false impression of favoring a rigid behavior. Inexperienced Scrum Masters often borrow the prescriptive tone of the Scrum Guide and alienate themselves from the Development team and the rest of the organization.
A common criticism of the Scrum framework is that it doesn't provide any guidance for development teams in terms of practices and techniques. Although, this is intentional to leave the freedom for teams to discover and perfect their own custom method.
Scrum focuses on the Scrum Team and leaves organizational level questions unanswered.
Unfortunately, inexperienced leaders and coaches without a deep understanding of the underlying agile mindset often transform the former controlling culture into a Scrum-like hybrid model that miss most of the promises of real Scrum.
These failed transformations lead to an enormous loss in Scrum's reputation.
