This page provides a bit of context that communicate the reasoning, backgroud, and history behind this Guide. The Guide is intentionally both sparse and minimal, and here we open up discussions that reflect answers to obvious questions that will arise in its reading. Why is there no Scrum Master any more? Why is Swarming important?

The section "Scaffolding" contains similar analyses, told from the perspective of vestigal Scrum components.

Scrum is not a Framework

A framework is the structural essence of something, or structural support for something. If I were to build a framework for manufacturing cars, the main supporting structure would be the layout of the assembly line and of the manufacturing facilities. The process is there, too, but it's not part of the underlying structure. It may emerge from the structure or even drive the structure, but it itself is not the fundamental structure.

Scrum does have an (organizational) structure in its roles and its relationships. But even in the contemporary scrumguides.org standard, some roles have given way to responsibilities.

Framework is a nice, fancy word that gives people the feeling that they get something for investing in it, while it's hard to justify spending several hundred or thousand Euro to become certified on a "concept." But in its original form, it's difficult to argue that it was more than that. Even governance is a slightly glorified characterization, and one that the industry has probably avoided because of its tradition of being heavy-weight.

Scrum describes only a model: a description of an organizational configuration and some of its activities together with a few constraints on how they fit together. There is no template to copy and fill in. This is probably the largest distinction from existing Scrum guides. The Scrum guide of scrumguides.org is said to wrap existing constructs with a framework whose slots one fills in. This guide works the other way, starting with what exists and reshaping it as necessary to support one-piece continuous flow and ongoing improvement.

Roles and Responsibilities

The Constituency

The scrumguides.org standard formerly defined three roles, and those were the scope of Scrum. The scoope of the Scrum process in the past has been the Scrum Team, which was added to the Scrum Guide to comprise those three roles. Scrum at least feigns being silent about the interactions with any roles outside the Scrum team.

In this updated view on Scrum, we take a less business-enterprise-focused and more human-focused view of the network of communication behind development. The end user is an important part of that, so we pull the end-user into the scope of the guide. The main focus is on the developers, reflecting the focus on swarming

Pulling all of these roles together under the Scrum umbrella makes visible the opportunity to eliminate handoffs. There was a bit of a struggle to find a term to replace "Scrum team" as the designation of scope for the guide. The term ecosystem is certainly right but a bit ethereal and pretentious. The closure is not necessarily a community, so that word is not quite right. For now the term constituency suffices.

Scrum does not specify any mapping from roles or responsibilities to individuals. Perhaps, ideally, end users should develop their own products — the ultimate in eliminating handoffs. Most shops don't work that way for reasons you can learn about in economics class. However, Scrum operates at a deeper level of human behavior than arises from culturally imposed structures.

Three Roles

This guide nominally features three roles: the end-user, the developer, and the Product Owner. These exist largely for convenience in describing the process and for highlighting stakeholding relationships that may be worth focus as the X makes decisions.

We saw many problems that arose from the absence of the end user role in scrumguides.org Scrum, though it is certainly present in most product development contexts. The Scrum Guide recognizes their existence and necessity, though it characterizes customers as being an acceptible substitue. Customers are agents of business transaction; such considerations are outside Scrum. The considerations to understand need technically do not fall in the realm of being a customer.

The scrumguides.org Scrum Guide is selective in which of the roles (in the vernacular sense) it discusses surface to full first-class standing in the standard. End users are not optional in scrumguides.org Scrum but they aren't celebrated in its description, formalization, or certification. Yet they are somehow at the center of the development universe. They are the raison d'être for product, which is the raison d'être for everything here.

Product Owner and Specifications

1. We still have a Product Owner (PO) — for many reasons. The main reason is that understanding the end user population is a sometimes lengthy and even tedious task, and we want that work not to block developers' progress to deliver product increments.

I am frankly torn about whether the PO should be raised to the same level as the other two key concepts of swarming and kaizen mind, and welcome advice and suggestions.

2. Interactions between the PO and the developers are much less structured and more agile than in scrumguides.org Scrum. The developers are equal partners with the PO in designing the business and technical solution, though we can expect that in most cases the PO is likely to represent the end user, market and enterprise interests and the developers more likely to present technical opportunities and challenge. The ordering of product increments (the scrumguides.org Product Backlog is one implementation of such, though any number of alternative implementations are possible) is also a matter of negotation between all parties, including end users.

This integration means that the interface between the PO and developers isn't really a handoff, because developers are involved in building, refining, and ordering the backlog. I view the developers as equal partners with the PO in designing (a carefully chosen word) the business solution that the PO identifies. The team sacrifices the PO to spend time on end user gembas to sniff out opportunities for service 

Why no Scrum Master?

Scrum Master in scrumguides.org Scrum has develoved from an individual to a rather ill-defined role that vaguely has responsibility for the development process. As is allowed by scrumguides.org Scrum we spread the responsibilities for this function across the entire team, including the Product Owner and end users. Even if there is a Scrum Master, such engagement is in any case necessary for success. If the organization finds need for a point person or coordnator (see Scaffolding) one is likely to arise as needed.

Why "Development Team" instead of "Developers"?

If Scrum is fundamentally about one-by-one construction (which is more or less where the name comes from) then the proper unit of organization we discuss should be the team, rather than the individual. The team should be thinking as one mind and acting as a collective coordnated within itself, rather than individuals coordinated by an external person or process.

On a day-to-day basis, of course, it is individuals. Each brings their own insights and talents to the fore. Takeuchi-san and Nonaka-sensei emphasize that the selection of individuals is crucial. You need individuals who together can work as a team. You need individuals who are willing to take risks and fly in the face of convention. You need to change out individuals who want overly radical change or who are otherwise disruptive. Japanese, American and European cultures, just to name three, have different ways of dealing with staffing. Each team may evolve its way to its own Norms of Conduct, suitable to dealing with such problems in a given culture and development environment.

In his paper, "Programming as Theory Building," Peter Naur talks of teams as having a theory of development and of their product. By "theory" he means the ability to explain why they do things the way they do and why things are the way they are. Why is this line of code there? The theory can explain it. The lack of any explanation will likely be the course of gross inefficiences at best and a faulty product at worst.

Naur notes that the product should just be an articulation of that theory. He also notes that, when the team dissolves, the theory vanishes.

This doesn't mean that individuals are cast out of a team mould. Diversity is a powerful force in innovation, and countless studies have shown the value of diversty on a team. It is still crucial that the team have all talent necessary to build an increment, and that the team should strive to acquire that talent upon discovering its absence — growing their theory.

The Centrality of Swarming

Swarming is historically the essence of Scrum, and is the one thing that distinguishes Scrum from other project management approaches. Yet swarming appears in the scrumguides.org Guide in a form that is apparent only if you know it is there (about disallowing subteams within a Scrum Team), and is completely absent from A Simple Guide to Scrum. Why has contemporary practice lost swarming?

Even as Takechi and Nonaka describe in their paper, projects with swarming are difficult to manage and track. As such, swarming strikes fear into the hearts of managers who feel responsible for delivery. Most Scrum transitions retain the manager role, and an ugly compromise emerges. One way it can appear is as kanban — not in the sense that Toyota uses it in their assembly line, but in the sense of an American methodology. There is no kanban in Scrum.

Another is that teams simply fail to make the paradigm shift. Many Scrum teams that we see have team leads or managers, or have a Scrum Master who is a manager all but in name. Such structures are usually carry-overs from before the teams "Scrum conversion" and as such are a result of inertia and of either ignorance or a lack of will to change.

Why one Kaizen at a time?

Improvement follows a PDIA (Plan, Do, Inspect, Adjust) cycle. "Inspect" often means evaluating whether a change made things better or worse as a basis for the "Adjust" step. If multiple kaizens are in play at once, a measurement will likely have difficulty isolating the contributins from each effort. Some of the kaizens may actually be making things worse while others overshadow the damage they do. So to the degree possible, the team makes one improvement at a time.

Why does development of an increment focus on solving a problem rather than achieving a goal?

A problem is the difference between the current state and the desired state. A goal in a design activity is almost always to achieve some desired state, so at that level the two formalisms are the same. However, setting a goal may constrain the team from exploring alternative solutions, whereas starting with knowledge of the existing suboptimum state and a potential higher state can be a good starting point. In design, the desired state should be left open, though a placeholder end state or outcome can be proposed by the Product Owner. What is crucial is to make clear the nature of the existing suboptimum state.

Why not Sprint Backlog?

A Sprint Backlog in Scrum is the team's work plan. It is a collection of work plans for as many PBIs as the team has reduced to tasks or artifacts to guide the work.

If there are tasks, then the work of "design" and of implementation are separated. This interferes with flow..

Second, and more important, if an incrmenent can be designed beforehand then the process isn't moving forrward based on emergent insight. Much of swarming is about surfacing emergent information. Having a work plan of tasks may at best prejudice the direction against exploring design alternatives, and at worst may be just an inappropriate guess about what work needs to be done.

What do the two circles of the logo signify?

Probably not what you think they do.