We use the term scaffolding to describe those things that can help an organization move into a Scrum journey, that can compensate for blocked paths on that journey, and that can clarify the journey along the way.

We can investigate several kinds of scaffolding. One kind comprises those elements of scrumguides.org Scrum that are part of the standard, but which in fact are either just reminders of things you'll certainly get around to eventually, or are things that are just nice-to-have for which empirical evidence of value is elusive. The last kind comprises those that help you see your constituency from a new perspective which might add insight when seeking opportunites for improvement or potential solutions to problems in the process or organization.

Scaffolding in the Current Scrum Guide

Someone raised on scrumguides.org Scrum, or who has come through a Scrum Alliance or Scrum.Org certification program, might find this description of Scrum to be sparse. This site strives to reach back beyond Scrum's formalization to its nascent philosophy, constructs, and structures.

Many of the more recent additions can indeed be good starting points for new teams. They are like training wheels. However, like training wheels, they should be shed more and more as the team achieves balance and properly directed speed.

1. Sprints. A Sprint is a unit of development towards a goal. The term has come to mean much more than that, however: a Sprint Backlog (a collection of work items proposed to achieve the goal); a Daily Scrum (to formalize the inspect-and-adapt or plan-do-inspect-act cycle).

Some teams will benefit greatly from having Sprints. Others, such as those that are working on financial trading algorithms that vary from hour to hour, are less likely to benefit. Our friend Kyon Mm-san runs one-hour Sprints. These are nice in the sense that they have steps that remind one to pause and reflect on kaizen, for example.

2. Scrum Master. As described in the Notes of Rationale, the formally outdated notion of Scrum Master as a person, or even as a role, has been replaced by a responsibility that just as well can be distributed across the team. And even in the hypothetical ideal, a Scrum Master might be able to put themselves out of a job. Though there are good arguments against that ever happening, there aren't many good arguments for cetralizing those responsibilities in an individual. But sometimes, it makes sense. [More to come]

3. Definition of Done. This Guide stipulates ongoing kaizen and attentiveness to quality. Definition of Done is often used to attend to those aspects of internal quality that are often sacrificed to schedule pressure. Mature teams don't need a conscience crutch but it may be useful to have a reminder and checklist that the team consults with the supposed completion of work on each increment.

4. The Product Owner... ? Here, we present the Product Owner almost part and parcel of the configuration to support swarming, and so it will remain for the time being. But there is no Product Owner in the foundational texts such as those from Takeuchi and Nonaka, or from Stahl and .DeGrace. It is possible that the PO, too, should be relegated to status as a scaffold rather than as a vade mecum of Scrum.

The PO is analogous to Schwaber's "planning phase" in his publication on Scrum in 1997. So it meets the test of not being a shiny object of novelty but rather has roots in the pre-industrialization of Scrum, albeit more than five years into its publication as a software development approach.

Patterns

We use patterns as one example of the kind of scaffolding that can open new understanding and possibilities for a development effort. Patterns can be used as temporary scaffolding to strengthen the organization or process, likr putting  new coat of paint on a building, or can become permanet fixtures that remould the structure and refine the processes.

 [1]  Schwaber, Ken. SCRUM Development Process. 1997. DOI:10.1007/978-1-4471-0947-1_11.