Scrum

Basics

Definition: Scrum is an agile project management method that allots team rolls in a way that enables teams to work in parallel, make quick decisions, and remove impediments to rapidly develop software & products. Though it is typically used with software, Joe Justice of Team Wikispeed applied it to radical acceleration of hardware development - and OSE is currrently applying some of the techniques the development of hardware in the context of the GVCS.

Why would a development team use Scrum?

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” Jeff Sutherland, one of the creators of Scrum, refers to these as “activated” teams.

Following Lean development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

What is Scrum?

It is a variants of agile software development methodologies. name derived from rugby.

The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:

• Product Backlog– Estimate for each feature wanted in product.
• Release Backlog
• plan 4-12 Sprints – a substantive back log to a ship-ready state
• Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

According to Doctor Justice, "Stakeholder starts. May become Product Owner. May become Team, in extreme case. If we have help, stakeholder will get a team. Stakeholder Sets goal or value (Definition of Ready and Definition of Done). Stakeholder starts by defining a story.

Sprint ZERO

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

Here are some further questions to be taken up during Sprint Zero:

• Do we have the right people with the right skills? Is there a need for consultants, etc.?

• Given the Epic User Stories, the values, and the efinitions of done, what sort of work place, tools and technology set up are indicated?

• What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:

        Determine the length of sprints
        Identify business value (the criteria to prioritize Stories)
        Create epics. Prioritize epics (consider relative business value)
        For the highest priority epic, turn the epic into stories
        Prioritize the stories (consider relative business value)
        For each story, create a definition of done
        Create a team(s) workspace(s), and provide appropriate technology
        Configure the team(s)

The following sections explain the Scrum terms needed to understand Sprint Zero work.

User Stories

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

• As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

To review the key ideas of the video:

Independent – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed. Negotiable – the Product Owner and the Team co-create the value and attributes of features (Stories) Valuable – all Stories are connected directly to business value. Estimable – the Team estimates the size of the Stories relative to each other. Small – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below). Testable – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

Epic User Stories

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:

• As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

Definition of Done

NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

OSE GVCS Scrum

OSE already has many of the pieces necessary to Scrum. There has been a lot of thought put into how to maximize the value of the project, the resulting list of GVCS machines, and the step-by-step process needed to make them. All the work that has already been done would be used as the ground work for a Sprint ZERO.

The main question seems to be, who would do the work of Sprint Zero for OSE. It seems that Marcin needs to be centrally involved in the first three steps of Sprint Zero. In addition to Marcin for those first three steps, at minimum a Scrum Master would be needed. This is when the input Marcin brought back from TED in March (redistributing economic justice?) will be integrated into the current vision.

For the next two steps, turning the highest priority Epic into Stories, and prioritizing the Stories, another person(s) could step in for Marcin, if that seems best for OSE.

The need for Subject Matter Experts arises in the next step, creating the initial Definition of Done for each Story. An example of this would be creating standards for instructional videos, and ways to objectively measure if the instructional video for a certain machine meets those standards.

The real creative work needed to get ready for OSE Scrum involves understanding the incremental Releases, in other words, getting a vision of the order in which OSE "products" (the plans and documentation for each machine) will appear in the Product Backlog. The current list of 31 steps needs to be reconfigured into Stories, and understood in terms of interim products that can be brought to the state of Done. The dependencies among the steps need to be charted out. This process will be used over and over, so getting it well understood, with really clear Definitions of Done, will help tremendously. The order in which the Stories from the 31 Steps appear will be a combination of the chronological dependencies of the steps, and the relative value of the Stories.

Adapting Scrum to Hardware Technologies

(Dear Reader: the ideas from the Maccherone blog are incompletely represented here. See the link in Notes for a valuable perspective.)

Although there are likely more dependencies among Stories in hardware development, in Scrum you plan around these when planning a Release, and the Sprints within the Release.

In contrast to software development teams, hardware development teams may find that they need to consult technical specialists regularly to complete their work. The Scrum approach to this would involve seeing the specialists as outside suppliers. In general, however, the cross-functional training that occurs within the team, as people work in pairs, and as team members reach outside their comfort zone by selecting the Story with the highest priority, strengthens the team.

Internal Links

• Daily Scrum
• Extreme Enterprise
• OSE Collaboration Protocol

External Links

• Scrum Alliance website
• Scrum for Hardware Product Development Bringing Scrum to the Hardware Product Development Community
• Top 10 questions when using Agile on hardware projects
• How to Scale a Development Team