What is the "scrum" approach to projects? We would define it as a simple productivity technique derived from software development modalities, such as extreme programming and agile software development. We found that a scrum implementation for line management led to an increase in the tempo of accomplishment, a decrease in steady state project lists, and improved communication.
Let's take a look at the basic requirements to implement a scrum approach:

• A team
• A facilitator for the team (called the "scrum master")
• A product backlog list (the list of all the things we need to do)
• A sprint backlog list (the list of all things we are going to do immediately)
• Constant customer or stakeholder communication and involvement
• Burn-down chart (showing how we consume the hours allotted to the tasks)
• Daily scrum meetings - short, and designed to answer three questions:
• What did you accomplish yesterday?
• What are you working on today?
• What obstacles confront you?

What we describe above may seem somewhat simplistic, and indeed it is. As we recommend in our new book, Scrum Project Management (CRC Press), the scrum user should begin by using the standard project management activities, such as defining scope, developing a statement of work and, most importantly, creating a work breakdown structure (WBS), which we discussed in detail in our last article. (By the way, this technique, which was developed for technical projects, works wonderfully for entrepreneurial endeavors as well. Read the book for details.)
The WBS is the heart of project management, and it is so important that it has a U.S. Department of Defense military handbook (MIL-HDBK-881x) associated with it. (See Table 1.)
With this approach, the voice of the customer is the driving mechanism for the scope of work, which, in turn, drives the requirements. We don't care if these requirements come from external sources or if they are internally derived. When requirements change, the WBS must change, because the WBS is precisely a functional decomposition of top-level deliverable elements. Once we have a visible structure, duration, as well as updating, re-planning, and re-estimating costs, becomes simpler, because all of the elements are visible.
The WBS is important to scrum project management because the cost centers are always derived from project deliverable elements. The WBS provides the product backlog for the subsequent sprints and distributes the work to cost centers or other sprint teams. The concept works because products are composed of systems, which in turn are composed of subsystems, and then components, and so on. If we start with a top-level assembly as the first or second level on the WBS, we can easily break the product down into "atomic" level tasks.
The same approach will apply if we are dealing with other deliverables, such as internal specifications, models, failure mode and effects analyses (FMEA), and the total round of documents that any formal quality system requires.
Modifying the WBS
Tracking updates to the project scope or changing deliverables to meet requirements is where many projects go astray, including scrum projects. Lack of change management or incompetent configuration control makes it difficult to compare what we have with our expectations and needs. With scrum, we derive the product backlog directly from the WBS, which is not simply an action item list. It is a formal document designed to support cost and schedule reporting (Earned Value Management) as part of a contract, and we can derive our action item lists, schedule, and budgets from it.
We will deconstruct the WBS as far as we need to go - such that we can put items into our product backlog planning document with minimal effort. This is another area in which projects go astray, with missing items and misunderstood or nonexistent dependencies between tasks. (A dependency occurs when one task is dependent on the completion of another task.) This is not the case with the scrum approach, because it allows us to focus on the immediate goal. If we have an especially short planning horizon, as is used in our scrum project management approach, then we must have tasks that can be accomplished during that period.
We call this highly detailed analysis "atomic" decomposition because we are decomposing the higher-level tasks until further decomposition no longer adds value. When we complete this task, we will have a list of "atoms" that become part of our other planning documents. We now take the atomic tasks and use them to populate the product backlog. If we have set up our breakdown correctly, we should not ever need to list the higher-order tasks: Completing the atomic tasks in appropriate order will automatically result in completion of the higher-order tasks.
Setting Up the Scrum Sprint
We select meaningful tasks from the product backlog to populate the sprint backlog. These tasks can be low-hanging fruit that we think we can do quickly or that can be accomplished in priority order so long as we remember our dependencies. A typical sprint will last from two weeks to four weeks.
The sprint list is quasi-sacred. (See Table 2.) The sprint team should only consider breaking the sprint if a dire emergency occurs and they have a higher-level champion who is willing to override the sprint. Otherwise, the goal is to complete our tasks while tracking them with a burn-down chart.
The burn-down chart will show us progress against plan and may reveal that we bit off too much to chew or that the team is the target of interruptions from other parts of the enterprise. (See Fig. 1.) In that event, portions of the sprint backlog may be eliminated from the present sprint and postponed to a subsequent sprint. Likewise, if the sprint is accomplishing more than expected, the opportunity will be seized with the addition of components from the product backlog.
The daily sprint meetings are where the status of the project is communicated. In this meeting we ask:

• What did we do yesterday?
• What are we doing today?
• What are the bottlenecks and road blocks?

The scrum master will facilitate the meeting. The burn-down chart will be reviewed, and the areas of risk and constraint will be openly discussed. Where questions on the product arise (performance and functions), these are discussed and understood in these meetings.
At the end of the sprint, we take time to review what we have done, to see:

• What we did well
• What we could do better

This meeting should be brief but thorough. We expect a two-week retrospective to be about half an hour and a four-week retrospective to scale up to an hour. At the end of the retrospective, we plan for the next sprint as a team.
Since scrum is a high-intensity technique with accelerated tempo, we do not want our meeting schedules to violate this ideal. The meetings should be organized well enough that we are not wasting the time of our team or teams. We will know that we have achieved this goal when the complaints about the meetings largely disappear.
Scaling Scrum
We can scale our scrum approach to larger development processes by creating the scrum of scrums. Basically, the scrum master (leader) from a scrum team at some level becomes a team member at the next higher level, if this approach makes sense. If this choice does not make sense, then we either elect a team member to represent the team at the higher level, or use some kind of round-robin approach, so that every team member receives a chance to represent the group. The Pomodoro Technique is a personal productivity implementation of scrum that encourages more efficient use of time. ("Pomodoro" is the Italian word for "tomato," and many aficionados like to use a particular kitchen timer that looks like a tomato.) We do the following:
1. Get a small clock or a kitchen timer.
2. Make a list of all things to do (product backlog).
3. Select a list for today (sprint backlog).
4. Prioritize the tasks.
5. Set the clock for 25 minutes.
6. Work on a top-priority task without break for 25 minutes (sprint).
7. Take a three- to five-minute break at end of pomodoro.
8. Continue same task, if not done, on next 25-minute pomodoro.
9. Record each pomodoro with an "X" on today's list (a variation on a burn-down chart)
Experience with the scrum technique shows that it increases tempo, allowing for focused achievement and a counterattack on the myth of multiprocessing. (Download more comprehensive instructions for pomodoro at www.pomodorotechnique.com.)
We have used the scrum approach in a line management setting. We found no difficulties scaling the process to meet our needs. Some areas that were less than satisfactory were the burn-down charts (which were a bit complicated) and the full-fledged WBS. On the other hand, the team enjoyed the improvement in the steady-state list of projects they were working on, and the daily scrum meetings improved communication to the point where different departments were achieving some level of cross-fertilization of capabilities.

Main Topics of Military Handbook MIL-HDBK-881x Integration, assembly, test, and checkout efforts Systems engineering and program management Training Equipment Services Facilities Data Technical publications Engineering data Management data Support data Data depository System test and evaluation Development test and evaluation Operational test and evaluation Mock-ups Test and evaluation support Test facilities Peculiar support equipment (items not currently in inventory and must be developed) Test and measurement equipment Support and handling equipment Common support equipment (items currently in inventory) Test and measurement equipment Support and handling equipment Operational and site activation System assembly, installation, and activation Checkout on site Contractor technical support Site construction Site/ship/vehicle conversion (obviously military and defined as what must be done to accommodate the product; on the civilian side, we would look for opportunities for reuse) Industrial facilities Construction/conversion/expansion Equipment acquisition or modernization Maintenance (industrial facilities) Initial spares and repair parts Table 1 Source: Department of Defense

Kim Pries and Jon Quigley are principals with Value Transformation, LLC. They have written two books for Taylor & Francis's CRC Press (www.taylorandfrancis.com). Contact them at kim.pries@valuetransform.com and jon.quigley@valuetransform.com, respectively.