How to "DeScale" Scrum- it's not what you think.

More with LeSS: Identifying the Product

In a recent Certified ScrumMaster course, students were expecting to learn about a concept referred to as “scaling” despite the fact that the learning objectives for a CSM do not include this advanced topic. Given the number of students that wanted to talk about the topic, we carved out time within the Product Owner discussion to talk about the concept.

Of the 30 people represented in the room, not one worked for a company even close to being ready for scaling real Scrum. They were under the impression that they did not need to change current project management structures. Scrum is doing work differently. It will mean changing existing structures. Likewise, trying to coordinate many teams of people using Scrum requires structure changes.

This post is the first in a series highlighting the steps that organizations skip when they rush to adopt Scrum. Yet they are critical to “scale” Scrum. The first step skipped, of course, is realizing that the organization doesn’t get bigger- it "descales." A framework for descaling the organization with Scrum described in this series is Large Scale Scrum (LeSS): https://less.works/

Identifying the Product

When deciding to use Scrum and LeSS, one of the first things to understand is what your product actually is. This may sound simplistic. Yet so many organizations skip this step and completely misidentify the product!

An example of getting the product wrong involves a project team assigned to upgrade the platform an application runs on. They will label that platform the product or the software the product. These are not only not the product, no change in that scenario occurs and remember, structure change is required. Project management is one way of doing work. Scrum is a different way of doing work.

They are not the same thing.

Scrum is not defined by the project management structure. There is a Product Owner. A Product Backlog. Working product increments. To get started we need to define product, not project.

But wait! Isn’t Scrum about continuous improvement? Providing transparency, then inspecting and adapting? In the spirit of continuous improvement and deciding on a place to start, it’s best to use powerful questions to get change going in the right direction.

Make the distinction between:

• The ‘ideal’ Product Definition – use broadening questions to identify

• The ‘practical’ Product Definition – use a subset of the ideal Product Definition to narrow it down and to start and improve from

Broadening Questions

Traditional ways of expressing work involve a Requirements Document focusing on the “system”. You might recall reading or writing things like “the system shall provide.” Effective questions used in Scrum and in LeSS are customer-centric. They include:

• Who are the actual end-customers?

• What does the user or customer consider the product to be?

• What is the end user or end customer paying for?

• What is the original problem that the product is solving?

Narrowing Questions

Results of asking Broadening Questions will provide the ideal Product Definition. In many organizations the structural change required to align for product delivery may seem impractical or too overwhelming to start. Use Narrowing Questions to look at the existing situation and organization and narrow the ideal Product Definition so that it’s more practical to start with. These questions include:

• What is within your company?

• What is within your control?

• Can you state a clear vision for the product?

Do not skip this step! Many organizations rush to assign a warm available body as the Product Owner without defining product. Only once you have decided on an ideal Product Definition or narrower practical Product Definition, are you ready to identify who the Product Owner is. Stay tuned for the next post in this series for tips on identifying the Product Owner.

Find our upcoming course opportunities with Craig Larman, co-creator of LeSS, by checking out our course schedule!

A New Definition of Insanity – Why Certified ScrumMaster Training?

---

In Certified ScrumMaster courses, I find myself using the old saying “The definition of insanity is doing the same thing over and over again and expecting a different result”. Agile approaches such as Scrum are completely different ways of doing work. Yet so many organizations today do not understand this.

Jeff Sutherland created Scrum largely because the traditional way of doing work, or “Waterfall”, physically delays any business value to the customer. Scrum and other Agile methods deliver value faster if used as directed.

So why do organizations insist on continuing to follow the same, old system development life cycles or build cycles that they were using 20-30 years ago? I call this the New Definition of Insanity since all they have changed is their vocabulary. They say things like Daily Scrum or Product Owner, ScrumMaster, Sprint but in reality they have not gotten something shippable into a customer’s hands any faster than the way they had been working.

If work is not done during a Sprint, there are constructs in Scrum to get to the root cause of this and to prevent this from happening again. Yet so many organizations report they simply “carry work over” to the next Sprint. Working in their old Waterfall ways.

In this day and age of Google, Amazon and Zappos, delighting the customer is key. If organizations cannot deliver value to their customers, someone else will. Are you working the same old way, but using new words to describe it?

Want to learn how Scrum delivers business value more quickly? Click here to view our upcoming classes and register for our next CSM or CSPO course.

Author: Collaborative Leadership Team. Learn more about our coaches and offerings here.