Scrum
Definition: Scrum is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of agile software development methodologies.
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.
The adoption of Scrum by Western development teams is part of a grand mimicking of Japanese manufacturing techniques, which has been going on, with patterns of waxing and waning, for many decades. Software development has become a big enough industry that its leading edge is penetrating many other industries. Its leading edge is the family of development management processes called Agile, one of which, the most popular, is Scrum.
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?
. .
. .
. . The video above is a great introduction to Scrum!
He covers core concepts: Backlogs, Roles, Release Planning, Burndown Chart, Daily Scrum
Backlogs:
- Product Backlog
- Release Backlog
- Sprint Backlog
Additional related ideas useful for GVCS:
Stories. Most people working with Scrum refer to each entry in the Product Backlog, called features in the video, as a Story. The formula for a Story is: As ______, I want ________, so that ________.
Epic backlog. This is a collection of the top level Stories OSE is creating. Epics are too large to finish in one release, and so they are not placed in the Product Backlog. Instead, the Product Owner needs to break each Epic up into Stories that can be placed on the Product Backlog. An example of an Epic:
- 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.
Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)
Additional related ideas useful for GVCS:
Product Owner -- the role of the Product Owner is so key that an additional video (below) is needed to begin to understand their role.
Scrum Master -- the video mentions keeping the project progressing smoothly, and making sure that team members have the tools they need. In fact, probably the most important role of the Scrum Master is to REMOVE IMPEDIMENTS! See the discussion below on the Daily Scrum.
Release Planning: Estimate, Sprint, Assign Stories to Sprints
Additional related ideas useful for GVCS:
In addition to Estimating the Stories, the Team needs to carefully uncover any dependencies between or among Stories. Ideally, Stories could be rewritten, sliced or otherwise modified to eliminate dependencies among Stories. If not, the dependencies should be clearly indicated on the chart showing which Stories are to be done in each Iteration. It's important that dependencies are easy to see at a glance.
Following each Sprint, there will be demonstrations, a retrospective, and then the backlog for the next iteration will be estimated, and the definitions of done reviewed with the Product Owner.
To be ready for the first Iteration, there needs to be an "Iteration Zero" (see video below, and discussion of a trial run-through by Simon and Mia).
Burndown Chart
During the first several Sprints, OSE will be sorting out what it means to be doing Scrum, and how it all works. It won't be until a few Sprints after that that the rate of work will be a useful measure. So it will be bit before we have a reliable burndown chart. This concept obviously interacts with the deadline Marcin has described for GVCS.
Daily Scrum
It could be that we want volunteers to participate in a "Daily Scrum" after they've worked about 8 hours. Which, if a volunteer is giving 15 hours a week, could be just twice a week, say. This is another piece to consider as we design our own unique Scrum. (Btw, his calling Daily Scrums into question is the main part of this video that has drawn fire from other Scrum coaches.)
The structure of a Daily Scrum is just each team member answering three questions: 1) what did I do yesterday? 2) what will I do today? (make adjustments in the chart of "In Process" Stories) 3) what are the impediments to either finishing at all, or meeting the estimated time?
The Scrum Master is responsible for eliminating any impediments. However, that could mean placing a Story about the solution to the impediment in the Product Backlog. Often, the Product Owner has to contribute to eliminating impediments, and for this reason the Product Owner attends all Daily Scrums (although they don't speak during the Daily Scrum). For Team Members, seeing impediments removed is key to creating the accelerated velocity that Scrum is famous for.
More thoughts on the Product Owner Do we want part of this role to be distributed and collaborative? Because of the nature of OSE, it is likely that a number of people would form a Product Owner Scrum, whose Product Backlog would be all the responsibilities of an individual Product Owner in a more typical Scrum. It seems very useful to have just one person being the Product Owner for any given release. However, if we move to multiple simultaneous teams, or as we cycle through Releases, the role could be rotated.
.
.
. .
. .
This video explains a good way to evaluate and improve Stories, which are the list of features that make up the Product Backlog.
. .
. .
. . NOTE -- this video is LOUD!
Definition of Done: In the video, he refers to "blockers" which are impediments. 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 are crucial for us to understand what is needed in Iteration Zero. See discussion of a trial run-through by Simon and Mia below for more on this.
Sprint ZERO
To get ready for the first Sprint, the Product Owner and the Scrum Master need to meet with the team and do some initial preparation. The amount of time spent on this should be "time-boxed" like a normal Sprint. For example, team members could commit a certain amount of time over the course of two weeks to do as much as possible in that time period. Unfinished preparation can be listed as a Story on the Product Backlog when Sprint Zero is finished.
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 ranked (see run through by Simon and Mia for an exploration of this). During Sprint Zero, the list of Epics is given careful consideration. It doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories in the video above.
Another important outcome of Sprint Zero is to get SOME of the requirements, or tests that products will be subjected to, which in Scrum terms make up the 'definition of done.' In Scrum, you cannot exhaustively list all the requirements for 'done.' Part of the philosophy is that the Product Owner's needs will change throughout the entire process, so their definition of done will necessarily change as well.
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 Epics, the values, and the definitions of done, what sort of work place, tools and technology set up is 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 three releases, so that the broad outlines of the technology and personnel needed can be understood. At the start of all Releases, Impediments and Technology Spikes need to be prioritized within the complete list of Stories. (Technology Spikes are plans to use Team members time to create necessary Team infrastructure.)
As the first Release progresses, the Product Owner and the Scrum Master will continue to develop the Product Backlog in preparation for the next Release. By the start of the second Release, there will need to be enough prioritized Stories (including Impediment Resolutions and Technology Spikes) for that Release.
Here's a possible outline for Sprint Zero:
Describe final product
Create a team(s) workspace(s)
Determine the length of sprints
Identify business value (the criteria to measure the value of work as it's done)
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
Describing final product
The vision of the final outcome will continually change, and this adaptability is what Scrum is designed for. To minimize too much front-loading of visioning work, focus your vision on the next product version, and envision a product with minimum functionality that addresses a narrow set of customer needs. Quickly release a first product increment, or demo it to customers and users to validate the vision. Listen to the responses to see if you are shooting for the right goal. Then adapt.
Selectively describes the product at a coarse-grained level, capturing the product’s essence. Answer the following questions: • Who are the product's target users? • Which needs will the product address? What value does the product add? • Which product attributes are critical for meeting the needs selected and therefore for the success of the product? What will the product roughly look like and do? In which areas is the product going to excel? • What are the sources of revenue and what is the business model?
To what extent should a few of these processes be pulled into the normal Sprints?
OSE GVCS Scrum
First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and Babington burner with biomass Pelletizer for fueling modern Steam Engines. The burner is already present in the form of the Gasifier Icon
- CEB press - Full Product Release achieved.
- LifeTrac - on Prototype II
- Soil Pulverizer -
See Also
- Scrum for Hardware Product Development Bringing Scrum to the Hardware Product Development Community
- Top 10 questions when using Agile on hardware projects