Scrum Guide — Decomposition, Part 1

When I was studying to do my PSM I Certification, I decided to deconstruct the Scrum Guide. I would write out paragraphs by hand, then write down what I understood about them. Over the next few posts, baring anything more interesting coming up, I would like to share my thoughts on the Scrum Guide.

Sections in italics will be taken from the Scrum Guide. I'm not going to do a cut and paste, but re-type out what is present. Therefore there may be mistakes.

Sections in normal print will be me rephrasing or my interpretations of the paragraph. This I would like to think of as the positive aspects of Scrum.

Sections underlined will be the negative aspects that I see, or have been told, read or anything else negative. Sometimes these will sound silly as it I find it difficult to find negative aspects, this is where I ask for help. If you have more constructive negative feedback about a paragraph, please let me know in the comments.

Now, let's get on with the deconstruction.

Purpose Of The Scrum Guide

Scrum is a framework for developing, delivering and sustaining complex products. This guide contains the definition of Scrum. This definition consists of Scrum's riles, events, artifacts and the rules that bind them together. Ken Schwaber and Jeff Sutherland developed Scrum; the Scrum Guide is written and provided by them. Together, they stand behind the Scrum Guide.

Definition Of Scrum

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Scrum is a framework, not a methodology. A Framework implies that it is something you build upon.

A framework implies it is not complete.

It addresses complex and adaptive problems because it uses an empirical process to analyze the work to be done by regularly 'checking' to see if the right thing is being done.

• Productively - By continuously looking for ways to do things better (Retrospective).

• Creatively - By using everyone's input to solve problems. Problems are raised through the daily Scrum and retrospective.

• Highest possible Value - defining quality through the definition of done. Never compromising on quality.

Open to abuse. People who use Scrum as a method to get things done quickly leave out quality altogether.

Scrum is:

• Lightweight
• Simple to understand
• Difficult to master

Because it is so simple, it is easily communicated.

Because it is simple, things can be skipped and misinterpreted opening up avenues of abuse. Its simplicity can give a false sense of mastery, especially when not fully understood.

Scrum is a process framework that has been used to manage work on complex products since the early 1990s.

It is not new. It has been around for over 20 years!

Ages does not guarantee feasibility - but it's a good argument for it.

Scrum is not a process, technique or definitive method. Rather, it is a framework within which you can employ various processes and techniques.

A framework is something to build upon. A base.

The mere fact that it is a framework invites chopping and changing to suit your needs - it implies things can be "taken out."

Scrum makes clear and relative efficacy of your product management and work techniques so that you can continuously improve the product, the team and the working environment.

Efficacy - The ability to get the job done under ideal conditions. By making things clear, you can change it if things are bad.

Under ideal conditions, it doesn't work in the real world (so I have been told — I did say some of the negative aspects would be silly). Conditions are never ideal.

Because you have visibility - nothing is stopping you from changing things to make them ideal. Hence improvement!

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 Scrums success and usage.

Everything in Scrum serves a purpose — it is not put there just for the hell of it.

But we don't need all those things. It takes up too much time! We can live without it all.

The rules of Scrum bind together the roles, events and artifacts governing the relationship and interaction between them. The rules of Scrum are described throughout the body of this document.

The rules of Scrum dictate how the roles, events, artifacts - overall the components how they interact with one another.

Rules? Who needs rules? Can't you just get the 'gist' of it? Also, the Agile manifesto mentions Individuals and Interactions over Processes and Tools. If Scrum has rules, it must be a process. If it is a process, then it can't be Agile!

Specific tactics for using the Scrum framework vary and are described elsewhere.

Since Scrum is a framework to build upon, how to build upon it is covered outside this document. It also means that Scrum can be used outside of Software Development.

Since "how to follow Scrum" is not covered for every situation and you need to do more reading, it's no wonder a majority of Scrum-Agile implementations and transformations fail.

Uses Of Scrum

Scrum was initially developed for managing and developing products. Starting in the early 1990s, Scrum has been used extensively, worldwide to:

1. Research and identify viable markets, technologies, and product capabilities;
2. Develop products and enhancements;
3. Release products and enhancements, as frequently as many times per day;
4. Develop and sustain cloud (online, secure, on-demand) and other operations environments for product use; and,
5. Sustain and renew products.

Scrum/Agile has been used both inside and outside of Software Development. It has been used to train police forces (Ghana Police Force), legal teams (Lost Planet), the banking sector (ANZ), Education and many more.

Scrum has been used to develop software, hardware embedded software, networks of interacting function, autonomous vehicles, schools, government, marketing managing the operation of organisations and almost everything we use in our daily lives, as individuals and societies.

As technology, market and environment complexities and their interaction have rapidly increased, Scrum's utility in dealing with complexity is proven daily.

Scrum proved especially effective in interactive and incremental knowledge transfer. Scrum is no widely used for products, services and the management of the parent organisation.

The essence of Scrum is a small team of people. The individual team is highly flexible and adaptive. These strengths continue operating in single, several, many and network teams that develop, release, operate and sustain the work and work products of thousands of people. They collaborate and inter operate though sophisticated development architectures and target release environments.

I don't need to say more!

When the words "develop" and "development" are used in the Scrum Guide, they refer to complex work, such as those types defined above.

This is to detract from the roots of Scrum in Software Development where the term developer and development come from. The term is widened to incorporate anyone who works in complex work.

Scrum Theory

Scrum is founded on empirical processes control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.

• Make an assumption
• Test that assumption
• Evaluate that assumption
• Determine what to do with the assumption
• Repeat

Use a feedback loop to determine decisions. Base those decisions on evidence gathered, not speculation.

But I just want to know the one true way that will solve all my problems! Scrum does not give me that. It does not explain why it is better (or the best) process!

Three pillars uphold every implementation of empirical process control: transparency, inspection and adaptation.

Transparency

Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.

Stakeholders/Developers, basically everyone involved must have a common language and point of reference to understand what is being seen - the process itself and all aspects of the implementation.

For example:

• A common language referring to the process must be shared by all participants; and,
• Those performing the work and those inspecting the resulting increment must share a common definition of "Done"

You don't need a common language, just 'tell' the developers what to do. They are smart. They will figure it out.

Done is 'done' when I say it is 'done!' So what if it hasn't been tested. Then it will be 'done-done!'

Inspection

Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.

In other words, keep looking for problems (undesirable variances). Don't let the looking (and subsequent fixing) of the problems get in the way of doing the work. Use the work to find and fix the variances (variances taken from W. Edwards Deming?)
The best inspectors are the ones who both do the work, but also know what variances to look out for. Problems can also be defects!

But I don't have any variances/problems!

Not having variances/problems is a problem in itself, LOOK HARDER!

Adaptation

If an inspector determines that one of more aspects of a process deviates outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.

Here a feedback look is established based on quality. If there is a deviation in "quality," be it software quality or process quality then an "adjustment" is made to bring it back in line. Also, the adjustment must be made as soon as possible, not only in terms of time (which dictates the cycle time of the feedback loop) but also in terms of where the variance is happening. By this I mean fix the variance at the source, not after the inspection. i.e. after the fact.

We have tests, we'll raise a ticket so the "variances" are fixed at some point in the near or distant future (If at all).

Scrum prescribes four format events for inspection and adaptation, as described in the Scrum Events section of this document:

• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

Meetings, meetings, and more meetings!

Scrum Values

When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspections and adaptation come to life and build trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum roles, events and artifacts.

The Scrum House?

Successful use of Scrum depends on people becoming more proficient in living these five values. People personally commit to achieving the goals of the Scrum Team. The Scrum Team members have courage to do the right hing and work on tough problems.

The right thing is not to use Scrum!

Everyone focuses on the work of the sprint and the goals of the Scrum Team.

Do not focus too much on just the work, but also improving the work. Focus on only the work leads you into a rut where you don't get better, you just keep doing the same thing because it gets the work done. In this case, especially when things are most busiest, it takes courage to stop doing the work and focus on improving the work.

The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. Scrum Team members respect each other to be capable, independent people.

Here these values and pillars are used to help build trust in the team. Trust is when you trust the Scrum Master to have your best interests. Trust that the Product Owner will not waste your time on meaningless work. Trust that your fellow development team members have your back.

Without trust (5 Dysfunctions of a Team), you know your fellow team members will not have your back. Put you down on your weaknesses, discourage ideas that are different. This leads to lack of conflict. The ability to discuss the non-con-formative. In other words, absence of courage and openness. Since people no longer feel happy, they have no say, they switch off, they are no longer committed. They no longer have authority over how to do things. They are just told what to do, thus lack the sense of responsibility. Thus have no respect for their fellow team members.
Thus there is no focus on the goals. This is where Scrum fails.