top of page
  • Toby Sinclair

Book Summary: A Scrum Book by Jeff Sutherland | The Big Ideas and Actions

Updated: Aug 23, 2020


The Book Cover of A Scrum Book by Jeff Sutherland
A Book Summary of A Scrum Book by Jeff Sutherland

3 Big Ideas


1. Scrum Guide defines the rules of Scrum but gives no indication of “how” to implement. Patterns provide a guide “how” to implement scrum and possible sequences of implementation. Patterns can be adopted piecemeal and the language guides which patterns should be considered first.


2. There are two “pattern languages” to consider when implementing scrum

Product Organization Pattern Language from A Scrum Book by Jeff Sutherland
Product Organization Pattern Language from A Scrum Book by Jeff Sutherland
Value Stream Pattern Language from A Scrum Book by Jeff Sutherland
Value Stream Pattern Language from A Scrum Book by Jeff Sutherland

3. When adopting scrum, focus on the “high order” system before a lower level pattern. For example, focus on establishing a stable team before you focus on other things - “Think globally, act locally.”


2 Quotes

Patterns are a roadmap to introduce Scrum into organizations, one pattern at a time.
There are almost countless ways to sequence patterns, each sequence giving rise to a Scrum organization with a slightly different character.

1 Action


Use this pattern language to describe and visualise possible adoption pathways for organisations

 

A longer book summary if you have more time… 

 

Introduction

  • While The Scrum Guide describes the basic rules of Scrum, the patterns amplify the guide by showing teams how to solve problems in a specific context.

  • What is a pattern? One simple definition is that a pattern is a repeatably applicable solution to a problem that arises in a specific context.

  • Working in small steps reduces risk and helps teams move forward with confidence in “process improvement.”

  • A carefully chosen sequence of such patterns can resolve product development issues and, importantly, help the organization understand Scrum more in depth.

  • Patterns explore the forces at play in the complex contexts of organizational development and workflow.

  • Patterns help with sequencing:

  • Build a Cross Functional Team BEFORE an Autonomous Team

  • Sometimes you will need to apply several patterns—maybe over several months—to solve a complex problem in the organization.

  • Patterns are a roadmap to introduce Scrum into organizations, one pattern at a time.

The Scrum Core as Patterns

  • Think of Scrum as a game we play. As with most games, it can be a wonderful form of engagement if its players appreciate both the discipline and freedom that help them create value.

  • Spirit of the game = Scrum requires a spirit of interaction between people, and that spirit can be difficult to define. This spirit is part of the culture of the organization and may be indiscernible for the people within the culture. Though it may be difficult to define, the spirit is easy to recognize when it is broken.

  • People often equate “doing Scrum” with the use of a Scrum Board. There is much more to Scrum than any set of tools can capture.

  • Kicking a soccer ball around in the park can look a lot like playing soccer, but it is not soccer.

  • Core Scrum in Pattern

The Core Scrum Pattern from A Scrum Book by Jeff Sutherland
The Core Scrum Pattern from A Scrum Book by Jeff Sutherland
  1. Description:

  • 3 “systems” which should be focused on in order

    • Assemble the team

    • Define the Product

    • Agree norms (ways of working)

    • Establish the Sprint


  • Jeff Sutherland suggested scrum adoption sequence (10 steps)

    1. Start with ​¶15 Stable Teams​.

    2. Decide how you are going to size your releases every ​¶46 Sprint​.

    3. Establish a velocity (see Notes on Velocity) and bring it into statistical control: use ​¶66 Yesterday’s Weather​.

    4. Focus on Done (see ​¶82 Definition of Done​) instead of foundering in rework. It takes teamwork to do that.

    5. Use ​¶25 Swarming: One-Piece Continuous Flow​.

    6. Know how to deal with interruptions during the Sprint.

    7. Align the organization to deal with emergencies using the disciplined replanning of ​¶32 Emergency Procedure​.

    8.  Get into a rhythm of improving your process every Sprint with ​¶92 Scrumming the Scrum​. Par

    9. Drive forward with the ​¶91 Happiness Metric​.

    10. Revisit how you are sizing your Sprints. Give yourself room to improve.

Product Organization Pattern Language

  • The Product Organization is one major Whole to which you must attend when introducing Scrum

  • Organizational values are the bedrock of the processes, structure, and atmosphere of the workplace

  • Good values are intrinsic and come from within.

Development Team

  • To build a product of the ​¶93 Greatest Value​ requires that producers work in a way that allows the team to recognize such value when they achieve it, and to support decisions that carry the team in that direction.

  • Scrum is optimised for:

    • Effective communication and feedback are at the heart of effective complex system development

    • The organization structure should be optimized for the most crucial paths of communication (Conways Law)

  • Heart of Agile:

    • Communication

    • Regular feedback

    • Self-organization

  • Focus on Value – our focus and concern are on the end user, market, and customers rather than on the tools and technologies we use to do our work.

  • Small Teams – Organize the workforce into Small Teams of more or less five people, partitioned according to the most important concerns for the creation of value by the enterprise. Supplement this structure with a small number of cross-cutting structures for secondary but important concerns

  • Scrum discourages local optimisation:

    • A Development Team structure where each team owns one part of the product, or just a product subassembly.

Involve the Managers

  1. Dilemma – the extent of management control, or whether there should be management at all.

  • Managers help in these cases:

    1. Managers have the station and power to restructure the organization while Product Owners do not.

    2. Contractual responsibility for a relationship with an external vendor that supplies multiple product developments

    3. Strategic issues related to the lifetime or very existence of a team or product.

    4. Product Owners are unlikely to have an adequately objective view to defund their own product when business sense dictates that they should.

    5. Sometimes a product or even an enterprise must go through discontinuous changes to survive.

    6. Deal with impediments that may be too weighty for the ​¶19 ScrumMaster​ or Product Owner

    7. Intervene to resolve conflicts between Product Owners of different products.

    8. Escalation step for impediments

    9. Help access to corporate resources,

    10.  ¶114 Firewall – run interference against stakeholders who would interfere with the team.

    11. Personnel development and administration.

    12. Raise the risk appetite for action where scope is broader than a single product. For example, remove product direction decisions from a sales and marketing to the Product Owner.

  • Product Owner, and not a manager, heads each product, with a very thin and narrow veneer of management at the next level up.

  • Managers must respect:

  • the Product Owner’s authority over product content and release

  • the Development Team’s self-direction as to the how, the who, and sometimes the when of feature development.

  • the scrum master raises the issue when these boundaries are not respected

  • The strongest foundation of management power is the reluctance to use it, and using it sparingly.

  • Celebrate Failure

  • “acknowledge failures with positive comments. Congratulate everyone on their efforts and remind them of the strengths and wisdom they gained from the experience. Put in perspective, a failure can do as much to motivate a team as a win”

Product Owner Team

  • Create a Product Owner Team, led by the Chief Product Owner, whose members together carry out product ownership.

  • Chief Product Owner (CPO) has final authority over the ordering of the Product Backlog.

  • The CPO plus the other people that support the CPO is what we call the Product Owner Team.

  • Do not label Product Owner Team members as ’Product Owners’— they do not own anything.

  • The CPO clearly communicates the strategy and the Product Backlog Items. The CPO works with the Product Owner Team members to select and order backlog items for the teams.

  • The Product Owner Team members can help the CPO work with the Development Teams to break the backlog into small Product Backlog Items for execution.

Manage Development Team Distractions

  • Create an Oyatsu Jinja (Snack Shrine) near the team area, with some candies, snacks, and drinks (coffee or tea).

  • Avoid Tragedy of the Commons:

  • multiple individuals, acting independently and rationally consulting their own self-interest, will ultimately deplete a shared limited resource (the dev team) even when it is clear that it is not in anyone’s long-term interest for this to happen.

  • Legacy management can cause confusion about the locus of control over product content and direction.

  • The locus of control should be the scrum team

Value Stream Pattern Language

  • The development process and the path from conception to market are as important to product success as the product idea itself.

  • The process to deliver ongoing and evolving streams of product increments to stakeholders

  • The organizational structures and processes that provide cradle-to-cradle support for the product.

  • Any given product can support multiple Value Streams, so a given Scrum Team may manage several Value Streams. Any given Scrum Team usually creates value for several stakeholders, and this implies that there are often several Value Streams at play.

  • Rhythm and time-boxing are two sides of the same coin. Sprints might start every two weeks; that means that a Sprint’s duration is no longer than two weeks.

  • Scrum does not presume that one size fits all, and it is up to each team to find its place within the recommended range (or sometimes, outside that range) that works best.

  • Good kaizen (see Kaizen and Kaikaku) often has roots in sustaining a good rhythm.

  • The Product Owner orders PBIs in a way that generates the largest long-term ROI.

  • Roadmap, it too can guide the Product Backlog contents. A good initial Product Backlog is a list of ​¶71 Sprint Goal​s that takes the product in the direction of the Vision, where each Sprint Goal becomes the core of the corresponding Regular Product Increment.

  • Historically, Jeff Sutherland split Toyota’s Chief Engineer into the Product Owner and ​¶19 ScrumMaster​ roles, reflecting business and development concerns respectively.

Product Backlog Increments

  • A PBI can describe anything that has potential value to a stakeholder.

  • No PBI within the top two or three Sprints should take more than 10 percent of the total PBI effort for that Sprint, and keeping them below 5 percent of the total effort is even better.

  • In most cases, the number of ​¶60 Estimation Points​ completed in the last Sprint is a reliable predictor of how many Estimation Points of work the team will complete in the next Sprint.

  • Break down Product Backlog Items into work items and assemble them into a plan called a ​¶72 Sprint Backlog​. Each work item is a Sprint Backlog Item (SBI). No Sprint Backlog Item typically should be any larger than a single Development Team member can complete in a single work day.

Product Definition

  • It is crucial to optimize the design for economies of scope.

  • Use Value Areas  – Example at energy company:

  • I-Join, I-Pay, and We-Support.

  • Value Areas address an area of customer value and requires specific detailed knowledge.

  • Each Value Area consists of four to six Development Teams

  • Broad vs Narrow

  • Too broad, the product lacks focus and direction, and users may have difficulty identifying with it.

  • Narrow –  Great products grow from small products that work.

  • Uniformly marketing all of a large product’s features to a single market is likely to confuse the consumer.

  • What you sell/market to the customer might be different to how you internally organise.

  • There may be legal forces for splitting a “application” into multiple “applications”, Microsoft to unbundle Internet Explorer from Windows®. We become limited in our ability to tailor existing products to add market differentiation.

Pattern Tips

  • Patterns characteristics:

    • Must be built upon multiple known examples

    • rule of thumb – must be three independently discovered prior examples

    • Has a moral grounding, it is is morally profound

    • Solves a problem.

    • Describes the how

    • Describes why it is essential

    • Takes into account context

  • Pattern Ratings:

    • ** = you will need this solution to resolve the forces to move forward in Scrum.

    • * =  the pattern is the core of a good solution; however, we cannot argue that it is the only way.

    • 0 =  works as a solution and that it is the best solution much of the time—though other good solutions exist as well.

  • Each node of the graph is a pattern, and the lines between patterns depict ordering dependencies between them. The graph therefore shows, for each pattern, the patterns above it, which you should already have considered before applying any given pattern—and the ones below it, which are candidates for next steps once you have put the current one in place.

  • There are almost countless ways to sequence patterns, each sequence giving rise to a Scrum organization with a slightly different character.

  • A pattern language is the set of rules for combining the patterns in meaningful orders; as a “language” it has a grammar that can generate all sequences that are meaningful “sentences.”

  • It is useful to think of the patterns as building the spaces, or the identities, for groups of people who gather occasionally or periodically to exchange ideas, build things, solve problems, and to grow together.

Other stuff

  • In the land of the blind, the one-eyed man is king. Anyone in the organization can assert their authority by claiming they can see what others don’t.

  • Toyota Quote:

  • “build people, not just cars”

  • The soil is tended and prepared, the seeds are watered, and when the seeds grow, the soil is maintained, weeded, and watered again until finally the fruit is ready

  • Make all non-trivial issues visible with an Impediment List; raise them up to the right people in the organization for resolution.

  • we define value as something of worth to some person or set of people whom we wish to serve.

bottom of page