Some notes on Scrum

I'm finding I can't describing SAFe without describing Scrum. The two are so intertwined. I've ended up going back to basics and trying to understand what Scrum is.

These notes owe a lot to the online ScrumAlliance material. The Scrum Alliance provide a superb set of short videos as well as the latest version of the Scrum Guide. I would recommend anyone interested in knowing more takes a look at these.

The Scrum Guide is the definitive and regularly updated 'bible' produced by the creators of Scrum - Ken Schwaber and Jeff Sutherland. Both the guide and the e-learning materials open with a definition of Scrum as:

"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. It is a starting structure that teams can build on. The things it describes are however rigid. Absolute and prescriptive. The creators make it clear if you do not follow the guide then you are not doing Scrum.

Unpicking what is meant by 'complex adaptive problems'. Complex - there is not a simple formula or predictable series of steps to reach the solution. Adaptive - the goals are likely to change during the time the team is working on them.

In these situations, the advice offered is to follow an 'empirical process'. This is a fancy way of saying:

• (Plan) Make some predictions
• (Do) some work or experiments based on those predictions
• (Check) See if the results match what you expected. Get feedback from other stakeholders.
• (Adjust) what you are doing depending on what you find to get better results.

This requires a couple of key features:

• Transparency - Everyone knows what is happening and what the results are at each stage
• Inspection - There is a regular and honest checking of results against predictions.
• Adaption - The team is able to use the feedback provided by inspection to adjust what they are doing.

Scrum describes a set of rules and relationships between:

• A team composition with defined roles (the Scrum development team),
• A particular set of fixed key events.
• A set of artifacts used by the team to track and communicate their progress.

It makes an implicit claim. This framework (team roles, events, artifacts and rules) captures a valid empirical approach. Adopting Scrum frees the team to focus on the technical aspects of delivering a quality product.

The Scrum development team

A Scrum development team is a cross-functional group. It consists of between three and nine people with the skills required to deliver the product. The size is a pragmatic rather than a hard limit. Less than three people and the team may be missing some skills. More than nine people and self-organizing and keeping people informed becomes difficult.

The team is cross-functional in that there are no specific roles relating to skills or experience or business function. People may have particular areas of expertise or experience but can work on any task that needs to be done. It is the team which decides who works on which tasks. Indeed the team decides on almost all aspects of how they work to deliver the product.

In the Scrum training, the answer to any question not covered in the guide comes down to "ask the team!"

There are however two defined roles within the Scrum team.

The Product Owner whose main responsibility is "maximizing the value of the product and the work of the team". They represent the customer perspective in the decision making of the team.

The Product Owner determines the business value of each item the team could be working on. They make sure that this 'Product Backlog' is kept up to date. This means reviewing both the value of the individual items and the ordering or ranking of the backlog items by relative priority. Product Owners are free to involve the team as much as they want in this process. (The scrum materials suggest that this should take no more than 10% of the rest of the time of the team.) This order determines the most valuable items for the team to work on next.

Product Owners ensure that the backlog is visible and understood by other stakeholders. They also ensure the team fully understand each work item. They will clarify details as necessary as the team develops the product.

The Scrum Master acts as a mentor or coach for the team. They help the team to understand the scrum process and to ensure that the process is being followed. They help ensure that the team members are communicating and working together. The Scrum materials described this as a servant-leader role. Scrum Masters lead by example and influence. They work to remove impediments preventing the team from making progress. They may act as a point of contact between the team and the wider organization.

Scrum Events

The sprint (called an iteration in Scaled Agile)

The 'sprint' is a core concept in Scrum. Scaled Agile (SAFe) calls these 'iterations'. This is the short period during which the team works on a specific goal. The period is short because it allows for faster feedback for the team. It also means that the team can restrict changes of scope during the sprint. The team plans any new work or changes of priority at the start of the next sprint.

• The sprint starts with a sprint planning meeting.
• Each day during the sprint the team has a daily scrum meeting to track progress and refocus.
• The sprint finishes with two events a Sprint Review and a Sprint Retrospective

The Scrum documentation makes the point that there is no gap between sprints. These events happen during the sprint. All events also have a timebox. The thinking behind this timebox is that it helps to focus the discussion on the most critical or relevant items.

The Sprint / Iteration Planning Meeting

Who: The development team (including the Product Owner)
Timebox: 4hrs (2hrs per week) (experienced teams need less)

Aim:

• The team understand what they are planning to deliver.
• They can explain how they plan to deliver a working product increment.
• They can describe how this increment meets the Sprint Goal and delivers the capabilities of the Product Backlog items in scope.

Inputs:

• What have we delivered so far? - the latest product increment.
• What is still to be done? - the current product backlog.
• Who is available to do it? - the projected capacity for the team allowing for holidays etc.
• How fast can we deliver? - Past performance of the team.

Outputs:

• A goal for the next sprint (Sprint or Iteration Goal)
• A Sprint Backlog of the items the team is planning on delivering

This meeting is for the team to plan the work of the sprint. The scrum process splits this into two parts. what the team is capable of delivering and how the team can deliver it.

The first two inputs help the team decide what the most important things are to work on next. Based on this the team drafts a 'Sprint Goal' that describes the aim of the next sprint.

Based on the sprint goal and who is available to deliver it the team can then decide how much to take on. This involves pulling items from the product backlog into a backlog for the sprint. The team discuss each item and decompose it into smaller tasks. The team validates any time estimates. Sprint backlog items are typical of 1-2 days duration.

Backlog items can turn out to be more complex or have other dependencies. The Product Owner is there to answer any new questions the team may have. They will help the team prioritize and scope or descope work from the sprint.

The Daily Scrum

Who: The development team
Timebox: 15 mins
Aim: Inspect and adapt the ongoing work of the sprint
Inputs/Outputs: The sprint backlog (adjusted during the meeting)

This is a short daily meeting. Setting it up for the same time and place each day makes it as easy as possible for everyone in the team to plan to attend. The main purpose is as a regular heartbeat for the team. It gives the whole team a chance to communicate, to consider their progress, and to adapt what they are doing.

Fifteen minutes focuses attention on the most important details. The scrum videos call this the transparency and inspection parts of the conversation - or:

• What happened yesterday?
• What is the plan for today?
• Are there any blockers?

These are the parts it is most important for the whole team to attend. The adjusting part is something that the relevant smaller sub-groups can discuss after the scrum meeting.

Several commentators make the point that this meeting is about the work items and not the individuals. They suggest 'walking the board' rather than having individuals report progress.

Focusing on the items re-enforces that the team owns all the items. It also makes sure the team considers all the items. Collaboration and support should be a strength of a motivated team. Focusing on the result by the whole team gives this an appropriate importance and value.

One interesting thing the Scrum documentation makes clear is that the Scrum owner does not run the Scrum.

The Scrum Master has three responsibilities:

• They make sure the meeting happens.
• They make sure that no-one who is not part of the team attends.
• They help the team learn to keep the discussion to the 15 minutes.

Once the team is doing those three things the Scrum Master, if they attend, they do so to help the discussions to happen.

The second one puzzled me slightly. Thinking further, the main point is that the time is so tight and the meeting so focused it needs constraining to only the people doing the work. Any other reason for attendance comes down to communication outside the team. Under Scrum, the Product Owner is already responsible for making sure this happens.

The Sprint Review

The Sprint Review happens at the end of a Sprint

Who: The development team (stakeholders invited by the Product Owner)
Timebox: 2 hrs for a 2 wk sprint. (more experienced teams may take less)

Aims:

• Demonstrate the new increment to stakeholders and get their feedback. The team can highlight any new features and show how they relate to the product backlog items.
• Stakeholders can share the current business context and any changes over the sprint.
• Stakeholders and the development team review and update the product backlog. This revised backlog becomes the starting point for planning the next sprint.

Inputs:

• The new product increment
• The product backlog

Output:

• Feedback from stakeholders
• A revised product backlog.

The meeting splits naturally into three parts. One for each of the aims above. The important point is that the demo is only one part of this meeting. The discussion with stakeholders and the chance to adapt the product backlog is a vital a part of the review.

The Sprint Retrospective

The very last event In a sprint.

Who: The development team
Timebox: 1-2 hrs for a 2 wk sprint. (more experienced teams may take less)
Aims: Allows the team to make continuous improvements to the way they work.

Inputs:

• Previous improvement actions
• The product backlog
• The sprint backlog
• Any tracking metrics or notes gathered during the sprint

Output:

• An improvement plan

The team considers how they completed the work over the last sprint. Possible topics might be people relationships processes and tools. The team then considers what went well and where there are areas for improvement.

Based on this the team creates a plan for how they are going to improve things for the next plan. The actions the team focuses on should be the ones with the biggest potential return.

The key point here is that the team need to follow up on the actions identified. Reviewing and holding the team accountable for making the changes identified matters. The other point the Scrum documentation makes clear is that over time the team the high-value improvements change. At the start teams will identify a lot of internal areas for change that they can control. Over time they will start to identify more areas in other parts of the organization. The positive side of this is the potential benefit to the whole organization. The practical side is that someone, possibly the Scrum Master will spend more time persuading other teams or areas of the merits of the change.

The Scrum artifacts.

It was a surprise to see that there are so few artifacts in Scrum.

• The Product Backlog is an ordered list. It lists all the possible things the team might work on, related to the product under development. It provides a single transparent source of truth. It shows what the 'work' is that the team is doing on that product.

It has a single responsible owner - the Product Owner. The Product Owner, in collaboration with the team, refines the backlog on a continual basis. This promotes a shared understanding of the progress and priorities of the team. The work needed to do this should take no more than about 10% of the effort of the team.

• The Sprint Backlog is the plan for how the team will deliver their Sprint Goal. It is a list of items that the team has committed to working on and delivering during the Sprint. The team updates this every day so it offers a transparent real-time view progress.

• The Sprint Goal is the description of what the team aims to achieve during the sprint

• The Product Increment is the 'working software' at the end of the increment. It represents the sum of all the product backlog items delivered by the team. In a non-software environment, this can be whatever product the team is working on.

A bt about the Scrum values

Scrum values do not seem to be particularly unique to Scrum. They seem to be the sort of things that make for effective teams in any environment. A lot of it comes down to be being a decent sort of person and working constructively with others.

• Commitment - people commit to the goals of the team and follow through on their actions.
• Courage - people act in alignment with their beliefs even when that is hard
• Focus - everyone works together on a clear goal
• Openness - which relates both to honesty and transparency
• Respect - for other members of the team as capable unique individuals and appreciating their capabilities and talents.

Conclusions

That as far as I can tell encapsulates what the scrum materials say. Other sources talk about slightly different variants and agile environments.

I said at the start I set out to write a brief summary of Scrum. It has ended up not so brief as I would have liked, but it is certainly far from definitive. Anyone interested in Scrum I'd suggest follows the links to the source materials listed.

My reason for writing this was to summarize my understanding based on what I have read. I've never worked in a team doing a pure implementation of Scrum so I'm curious what it is like. Please comment below if there is anything I've missed, or if you have any feedback or advice on being a solid contributor in this sort of environment.

References used

• The Scrum Guide by Ken Schwaber and Jeff Sutherland
  https://www.scrumalliance.org/learn-about-scrum/the-scrum-guide

• The Scrum Alliance e-learning series
  https://www.scrumalliance.org/learn-about-scrum/scrum-elearning-series

For the justification of why an empirical approach works best for complex adaptive problems, the video training references "Process Dynamics Modelling and Control" by Bobatuande Ogunnaike and W Harmon Ray.