Scrum as Example

Table of Contents

The challenge with frameworks

Scrum is a framework.  While you are encouraged to add to the framework, certain practices of the framework are sacrosanct – and you are not supposed to change them.  As with all frameworks this is to enable a well-defined starting point. People are then encouraged to extend the framework as needed. This is sometimes called going from Shu (following) to Ha (breaking with). These are the first two steps of Shu Ha Ri, an adoption metaphor from the martial arts popular in the Agile community.

The challenge is that starting with a framework as a set of practices discourages ever breaking with them.  When and how do I do that is left unanswered by Scrum.  In fact, those that do are called “Scrum buts.” This lack of how to transcend is justified by the seemingly logical statement that we need a well defined set of practices and that giving options will complicate that.

But this ignores a common assumption. That it’s the giving of options that causes the confusion.  The reality is that it is when the options are given that causes the confusion.

The way out of the challenge with frameworks

The simple statement is don’t have frameworks. They inherently focus you on the framework and not real objective at hand. The alternative is to have an approach that provides a well-defined, simple starting point.  Since no one-size-fits all exists, this starting point must be somewhat customized.  However, that is not that difficult because most organizations follow well-defined patterns of improvement.

The key now, however, is to provide the alternatives only after people have tried the practices and met with challenge. This requires that the people adopting the practices have been given the objective of the practice.  Something that they should be given in any event.  At this point, the simple set of tools we gave people can be revealed to be only the top shelf of a much larger tool box.

When we understand of a practice we’re having challenges with, we can use the following questions to improve our methods:

  • Are we having challenges with the practice because we’re doing it poorly? If Yes, then inspect and adapt and see if you can do it better. If No, continue
  • Is there something else in the organization that is causing us this problem? If Yes, then see how to fix that or at least influence the fixing of it. If No, then continue.
  • What else can we do that meets the same objective of the practice? If there is something else you can do, then try that. If not stick with the practice until you learn more.

The key here is not to abandon practices, but to find better ways of doing what you are doing, getting to the root cause of the issue (which may not be where the problem is showing up) or take on a new practice.

Thinking of ‘Scrum as example’ to build off our current investment in Scrum

Thinking of Scrum as example is designed to help those doing Scrum to improve it and/or to transcend it. At Net Objectives we are neither pro-Scrum nor anti-Scrum, we are pro what works. Many people start with Scrum only to discover not all of the prescribed practices fit their situation. Unfortunately, they are told they must follow these until the understand them. But very often these are not truly the right practices for all of the teams. Many people forget that Scrum was designed for product development by a team. Now, however, it is mostly used in IT and maintenance areas.

When teams have trouble with following Scrum practices they are told to remove the impediments they are finding. Each Scrum practice, artifact, and role in Scrum has a purpose. There are often better ways to achieve that purpose than the practice Scrum provides.

The key when you have a challenge with following Scrum is to ask yourself, “What objective does this practice meet?”, “What decision have I made?”, and “Is there a better way to do this?” By taking what you are already doing and checking it against the list of decisions below you can do two things:

  1. See if you’re doing something that can be done in a better way.
  2. Make sure you’ve actually made a decision about all of the necessary parts of team Agile and haven’t left somethings out because the Scrum practices were difficult to do.

Scrum as Example is an extension of Scrum in that you can start with Scrum (the practices in the example are Scrum practices), but by realizing that these practices represent decisions that Scrum has made for you, it gives you the opportunity to make better decisions when your context warrants it.

Think of Scrum as Example as the top shelf of a large toolbox. Everything you need to start with is there. You only need to go into the larger part when one of the topmost tools is having a problem getting the job done.

What to attend to

The issues involved here are:

  1. People need a pragmatic, well-defined starting point.
  2. They need to understand that when a practice doesn’t work how to figure out another one.
  3. they need to be able to go beyond any starting point and continuously improve even if it takes them out of the named approach. This may need to happen on their own as many consultants won’t lead them to where they need to go if they are committed to Scrum.

How to define Scrum in a concrete way while allowing for self learning

This is surprisingly easy to do. It requires a shift in how to start with Scrum. Instead of just giving the practices, teams, product owners and ScrumMasters need to be given decisions and objectives along with an example of meeting them. These examples can be the Scrum practices. But then, if they don’t work, the practices can be changed in any manner as long as it meets the objectives.

Scrum is a framework defined by roles, artifacts and meetings. This page is an attempt at defining Scrum as a set of objectives to meet and the decisions needed to make to achieve these objectives. These decisions are organized. as the artifacts documenting those decisions , the people responsible for making the decisions, the collaboration required to facilitate making those decisions and the agreements between the people doing this work. We’ve written the definition of this team method as a series of questions because the answers decided on provide the approach the team has agreed to follow. The way Scrum suggests is written in parenthesis.

The intention of this page is to illustrate that Scrum is a predetermined set of decisions. If you decide not to follow what Scrum suggests, you still have a decision as to how to fill the void left by not doing what Scrum prescribes.

  • Organization and working together
    • How will we organize our people?
    • Who decides how we work together?
    • How will we work together?
    • How will we treat each other?
    • What do we agree to do?
  • Deciding what to work on
    • How can we ensure we are working on the right thing and building it correctly?
    • How will the team know what’s most important to work on?
    • How will we define and store what we are trying to release?
    • How will we define and store what we are working on in the near term?
    • How small should the items we work on be?
  • Planning and estimation
    • How will we decide how long things will take?
    • How will we know how fast we are going?
    • Should, and if so, how, will we plan our work?
  • Collaboration and improvement
    • How should we keep everyone up to date on what’s going on?
    • How should we track our challenges?
    • Who should coach the team in improving their methods?
    • How can we steadily improve?

Organization and working together

  • At what pace should we go?
    • Objective: We want to go fast enough to make progress but not so fast that we overwhelm people.
    • Scrum says to fully implement Scrum right from the start.
    • Kanban suggests starting where you are.
    • Team Agility suggests looking to see where you are, make any obvious, agreed to changes, only change roles if people like the idea.
    • back to section top
  • How will we organize our people?
    • Objective: Achieve collaboration, high throughput of value, and learning.
    • Scrum says to organize into cross-functional teams, with a Product Owner and a Team Agility Master (ScrumMaster).
    • Kanban doesn’t require a particular organization.
    • Team Agility suggests achieving cross-functional teams to the extent possible. When not possible FLEX has tools to create organizations that lend themselves to better collaboration but can work in a model similar to Kanban when needed.
    • back to section top
  • Who decides how we work together?
    • Objective: Have an agreement on how the people doing the work should be working.
    • Scrum says to have teams self-organize.
    • back to section top
  • How will we work together?
    • Objective: Achieve collaboration, high throughput of value, and learning.
    • Scrum says to organize into cross-functional teams and use a common backlog for the team
    • Kanban suggests creating explicit workflow and manage work in process (WIP) so that work is delayed as little as possible
    • back to section top
  • How will we treat each other?
    • Objective: We want an agreed way of treating each other so that we can work well with each other.
    • Scrum says to manifest courage, commitment, focus, openness, and respect.
    • back to section top
  • What do we agree to do?
    • Objective: Make it clear for all team members what the team is attempting to accomplish.
    • Scrum says to follow Scrum’s practices in order to achieve value for the client. That any impediments uncovered in following the practices or to following the practices should be removed.
    • back to section top

Deciding what to work on

  • How can we ensure we are working on the right thing and building it correctly?
    • Objective: Ensure our work is always of value. If we get off track then we want to learn that quickly.
    • Scrum says to have a sprint demo so that the product owner can see what we did and make any corrections as necessary
  • How will the team know what’s most important to work on?
    • Objective: Have clarity of the team on what are the most important items to be working on. Also, provide clarity to those upstream and downstream of the team clarity on what the team is working and going to work on.
    • Scrum says to have a Product owner decide this.
  • How will we define and store what we are trying to release?
    • Objective: Have a way for everyone to see what we are working on to release for realizing business value. This provides the longer range view which creates the context for near term work.
    • Scrum says to use a product backlog that defines what will be released
  • How will we define and store what we are working on in the near term?
    • Objective: Have a way for everyone to see what we are going to build near term and what the relative importance of each of these items are to realizing value.
    • Scrum says to use a product backlog that defines what will be worked on and completed during the sprint.
  • How small should the items we work on be?
    • Objective: Working on small batches quicken feedback and improve things overall.  As Eli Godratt (creator of Theory of Constraints) said -“Often reducing batch size is all it takes to bring a system back into control.”

Planning and estimation

  • How will we decide how long things will take?
    • Objectives: Enable management to have some sense of when things will be done. Also, ensure team members agree on the general size of things. If these things don’t need to happen then this step does not need to be done.
    • Scrum doesn’t require estimation, but it is a common action in Scrum and some form of general estimation is needed to ensure the Sprint backlog is no more than two weeks.
  • How will we know how fast we are going?
    • Objective: This will allow for planning the coordination of releases and working with other teams. If this isn’t needed then it doesn’t need to be done.
    • Scrum doesn’t require this but most Scrum trainers suggest estimating stories in story points and seeing how many story points get completed in a sprint. This is known as the team’s velocity.
  • Should, and if so, how will we plan our work?
    • Objective: Ensure we are working on the most important items in the proper order. Maintain focus on what we are to do. Enable others to see what we are working on.
    • Scrum tells us to do plan sprints so that we can focus on getting the most important items done

Collaboration and improvement

  • How should we keep everyone up to date on what’s going on?
    • Objective: Keep everyone on the same page and focused on what we are trying to achieve. Without this awareness we will not be effective together. Note: We don’t list this as meetings required because this collaboration may be done other ways besides meetings.
    • Scrum says to have Daily Stand-ups.
  • How should we track our challenges?
    • Objective: We want to consciously fix our challenges or decide not to fix them. Everyone should understand these – especially management.
    • Scrum trainers suggest having an impediments backlog.
  • Who should coach the team in improving their methods?
    • Objective: Ensure that we are continuously improving.
    • Scrum says to have a ScrumMaster (Team Agility Master) fulfill this role.
  • How can we steadily improve?
    • Objective: We want to get better and better at what we do both for the satisfaction it gives us as individuals and the value we can provide to the organization.
    • Scrum says to have retrospectives at the end of every sprint.

Scrum as defined by the decisions it makes for us

The following tables describe the way Scrum defines decisions in various topic areas.

Philosophy of Scrum

What Scrum says to do Decision being made for us
Start with all of Scrum and do it completely At what pace should we go?
Have self-organizing teams Who decides how we work together?
Values of Scrum: Courage, Commitment, Focus, Openness and Respect How will we treat each other?
Remove impediments to delivering value, including impediments to following Scrum as defined What do we agree to do?

Roles

What Scrum says to do Decision being made for us
The Product Owner How will the team know what’s most important to work on?
How will we organize our people?
Development team is cross-functional How will we organize our people? How will we work together
Team Agility Master (ScrumMaster) How will we organize our people?
Who should coach the team in improving their methods?

Activities and Meetings

What Scrum says to do Decision being made for us
Use Sprints How can we ensure we are working on the right thing and building it correctly? Sprints provide focus and discipline and encourage small things to be built and tested.

How small should the items we work on be? Having 2 week sprints implies having small stories to be able to fit into them.

Sprint Planning How will we define and store what we are trying to release?

Should, and if so, how will we plan our work?

The Daily Stand-up How should we keep everyone up to date on what’s going on?
Sprint Demo How can we ensure we are working on the right thing and building it correctly?
Sprint Retrospective How can we steadily improve?

Artifacts

What Scrum says to do Decision being made for us
Product Backlog How will we define and store what we are trying to release?
Sprint Backlog How will we define and store what we are working on in the near term?

How will we decide how long things will take? (Scrum implies the answer here by forcing things to fit into a 2-week sprint)

How will we know how fast we are going? (Scrum doesn’t demand this but measuring velocity is a straightforward thing to do in Scrum, and virtually all Scrum trainers suggest it.

Increment Delivered How can we ensure we are working on the right thing and building it correctly?
Impediment List How should we keep everyone up to date on what’s going on?

How should we track our challenges?

Burn-down Chart How should we keep everyone up to date on what’s going on?

The value of using Scrum as Example

Scrum as Example provides just as explicit a starting point as Scrum is defined now. One can even use these decisions to define Scrum. However, it also provides a way for people to adopt different approaches without losing the intent of what is needed. Teams focus on their objectives not following a mandated solution. As they learn, they can make up their own solutions if they better achieve the objective.

If you want to learn more about why Scrum as Example is so important, see this linked in post Going Beyond Scrum to Scrum as Example.