Agile Delivery Kit for Software Organisations

v1.0.18

How to work in an agile way. This starter kit provides the strategies, recipes. workshops, technologies, practices, and guides that will help you and your people create a way of work that enables success.

Overview

Professional Scrum

Technology

  

8 minutes to read

Last Updated: Wed 25 Oct 2023 11:15

Scrum is a Social Technology defined in the Scrum Guide to enable a shift to a collaborative, creative approach that helps us deal with the increasingly complex world that relies on increasingly difficult technologies and products.

What is Professional Scrum?

Professional Scrum is a version of Scrum implemented by professionals for professional companies professionally.

Our mission remains the same as it was when we started - to help our profession rise to the demands of an increasingly complex world that relies on increasingly complex technologies and products. Advances in materials and techniques can only succeed if we shift to a collaborative, creative approach… As we use Scrum, we continue to find new opportunities for professional improvement.
–Ken Schwaber

First Principals of Scrum

  • Transparency: It is the enabling principle to build trust among Scrum Team members, the stakeholders, and the organization in general. Without trust, no one can handle the complexity of product development.
  • Self-organization: Problems are best solved by those closest to it; it is key to autonomy and thus accountability and overcoming the industrial paradigm. Scrum Values: Without courage, openness, and respect, there is no transparency.
  • Quality: Nothing great has ever originated from substandard, mediocre work and a lack of craftsmanship. (I consider “done” an attribute of quality.)

Wording of the Scrum Guide

The Scrum Guide is a document that uses one word when it should really use ten in an effort to minimize any mandated or constraining element beyond the minimum required to deliver an empirical system.

There are 9 load bearing elements of Scrum that are identified by the word “MUST”, and seven elements using the word “SHOULD”. Everything else is present in service to those core elements and are open to different implementations that maintain the integrity of the outcome of empiricism.

What MUST Scrum have?

There are only a very few things that MUST be there for Scrum to be Scrum and they are:

  1. The emergent process and work must be visible to those performing the work as well as those receiving the work.
  2. The Scrum artifacts and the progress toward agreed goals must be inspected frequently and diligently to detect potentially undesirable variances or problems. To help with inspection, Scrum provides cadence in the form of its five events.
  3. If any aspects of a process deviate outside acceptable limits or if the resulting product is unacceptable, the process being applied or the materials being produced must be adjusted. The adjustment must be made as soon as possible to minimize further deviation.
  4. For Product Owners to succeed, the entire organization must respect their decisions.
  5. The Sprint Goal must be finalized prior to the end of Sprint Planning.
  6. They must fulfill (or abandon) one objective (Product Goal) before taking on the next.
  7. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.
  8. If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.
  9. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.

What SHOULD Scrum have?

There are only a very few things that SHOULD be there for Scrum to be Scrum and they are:

  1. The decisions that are made, the steps taken, and the way Scrum is used should reinforce [the Scrum Values], not diminish or undermine them.
  2. If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product.
  3. [Multiple teams working on the same product] should share the same Product Goal, Product Backlog, and Product Owner.
  4. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.
  5. [The Sprint Backlog] should have enough detail that [the Developers] can inspect their progress in the Daily Scrum.
  6. The Sprint Review should never be considered a gate to releasing value.

What about all the other things in Scrum?

All of the named artifacts with commitments, events, and accountability’s are there to serve empiricism and the above elements. Implement them how you see fit to fulfill the spirit and not the letter of the Scrum Guide.

But the Scrum Guide says its Immutable?

The Scrum Guide is immutable of definition but not of implementation!

This means that what is defined in the Scrum Guide should be considered the definition of Scrum and if we deviate from it then we would no longer be doing Scrum but instead our own custom process based on Scrum. Which, by the way, is totally cool!

The Scrum framework, as outlined herein, is immutable. While 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. –Scrum Guide

This part of the Scrum Guide should not be taken to mean that if you don’t follow the Scrum Guide precisely that you are not doing Scrum. However it is worth considering the impact of the changes that you company are making to Scrum to see if your implementation is missing something critical. I like to think of the Scrum Guide to be like the timber frame of my house. It informs but does not control the use I put each room to, and how I decorate it. If I want to change the timber frame I can, but I may need to consult experts to determine if that part of the frame is load baring, and what I would need to do to maintain the structural integrity of the building.

So feel free to change any aspect of Scrum that you like, with due consideration to the structural integrity of empiricism, self-organization, and continuous improvement.

What about things not mentioned?

The Scrum Guide is only focused on the aspects of a teams work that enable empiricism and thus there are a lot of things that might be useful that it does not have an opinion on.

  • User Stories
  • Estimation
  • Story Points
  • etc..

These are all not mentioned in the Scrum Guide. You can check out our list of complimentary practices and add your own.

Overview of The Scrum Framework

Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems. The Scrum Framework is made up of five values, three accountability’s, three artifacts, and five events. This video gives an overview of each one, explaining what they are for and why they are there. The focus will be on the process itself, and we will leave the complementary practices until later.

Transparency

  • Product Backlog - The purpose of the Product Backlog is to provide transparency of the future; what are we doing next.
  • Sprint Backlog - The purpose of the Sprint Backlog is to provide transparency of the present; what are we doing now.
  • Increment - The purpose of the Increment is to provide transparency of the past; what have we done.

Inspection & Adaption

  • Sprint Planning - The purpose of Sprint Planning is to plan the Sprint.
  • Daily Scrum - The purpose of the Daily Scrum is to update the plan for the Sprint.
  • Sprint Review - The purpose of the Sprint Review is to update the plan for the next few Sprints.
  • Sprint Retrospective - The purpose of the Sprint Retrospective is to update our way of work to improve our effectiveness.

Common failures or Anti-Patterns

  • Unprofessional Behaviour - We need to stop normalising unprofessional behaviour and call it out whenever we hear it.
  • The Hero - The Hero takes it upon him or herself to be the saviour.
  • The Eye Roller - The Eye Roller sees Scrum as unnecessary and vocally complains about using it, falling just short of refusing to participate.
  • The Avoider - The Avoider uses the letter of their perceived law in their defence.
  • The Absent Product Owner - The Absent Product Owner is frequently too busy to attend to their responsibilities as prescribed by Scrum.
  • The 90 Percenter - The 90 Percenter is frequently “almost done” with whatever they are working on.

References: Related papers and Articles

Recommended Content

  • Manifesto for Agile Software Development (Guide)
    We are uncovering better ways of developing software by doing it and helping others do it. These are our values and principles.
  • The Scrum Guide (Guide)
    The Scrum Guide contains the definition of Scrum.
  • Kanban Guide for Scrum Teams (Guide)
    The flow-based perspective of Kanban can enhance and complement the Scrum framework and its implementation.
  • The Evidence-Based Management Guide (Guide)
    Evidence-Based Management (EBM) is an empirical approach that helps organizations to continuously improve customer outcomes, organizational capabilities, and business results under conditions of uncertainty.
  • Service Level Expectation (SLE) (Practice)
    A service level expectation (SLE) forecasts how long it should take a given item to flow from start to finish within the Scrum Team's Workflow.

Recommended Videos

Overview of The Scrum Framework
What is Professional Scrum?
Join the Community
The league of extraordinary lean-agile practitioners is a group of peers and seasoned practitioners that continuously learn, share emergent practices, and discuss topics with courage, commitment, focus, respect, & openness!
More Technologies
In this article