Understand Agile's Scrum technique for embedded software dev't

Transcription

1 Understand Agile's Scrum technique for embedded software dev't Learn how Scrum can keep team focused and organized when working on embedded systems project. By Kim H. Pries Manager of the Electrical and Electronics Verification and Test Group Volvo 3P and Jon M. Quigley Senior Member The American Society for Quality In modern Agile software development, teams employ a simple productivity technique called Scrum to organize the work flow and address problems during development. Scrum implementation for line management in IT projects increases the pace of accomplishment, decreases steady-state project lists, and improves team communication. We think it can do the same for embedded systems software development. Having literally written the book on Scrum, we present a short primer here for embedded systems developers. 1 You'll find the simplified basics in this article but we give you references at the end to further your knowledge. Scrum is a way to manage projects that focuses on the immediate objectives and deliverables of the people involved, helping to keep them focused and undistracted by other projects and activities. The method employs techniques similar to conventional project management, such as defining scope, developing a statement of work, creating a work breakdown structure, and managing the stakeholder expectations. The team developing the software consists of team members and a facilitator, called the Scrum master. The team members use a series of lists and meetings to keep on track, including: A work breakdown structure (a general, large-focus list of to-do items that feeds the product backlog list). A product backlog list (the list of all things that need to be done). A sprint backlog list (the list of all things to be done immediately). A burndown chart (showing how the team will consume the hours allotted to the tasks). A daily Scrum meeting (short meetings to answer three questions): 1. What did you accomplish yesterday? 2. What are you working on today? 3. What obstacles confront you? A sprint retrospective meeting (short meetings after each sprint is complete to review how the sprint went and what could be improved). The team also constantly communicates and involves the customer or stakeholder during the process. All the actual coding work is done in sprints. WBS and the product backlog In Scrum, the product backlog list outlines the deliveries and expectations from the customer along with something called a work breakdown structure (WBS), a hierarchical list of topics and to-do items that must be addressed during the project. The WBS is the heart of project management. We recommend the team base their product backlog list on the WBS defined in U.S. Department of Defense military handbook (MIL-HDBK-881x). 2 The handbook's list is not completely relevant to software development, but the team can modify or delete items before populating their Scrum product backlog list. Table 1 shows an excerpt from MIL-HDBK-881x; see the full sample list online in an article we wrote last year. 3 The purpose of the WBS, and hence the product backlog, is to ensure that the intent of the customer drives the scope of work which, in turn, drives the requirements and subsequent actions taken by the project team. It doesn't matter if the requirements come from external or internal sources. The requirements will be broken down for what is called the sprint a short period of time during which the team will be focused upon a specific subset of the product features. EE Times-Asia eetasia.com Copyright 2011 emedia Asia Ltd. Page 1 of 5

2 Table 1: Excerpt from a work breakdown structure recommended by DoD. When requirements change, the team changes the WBS (which feeds the product backlog) because WBS is a functional decomposition of top-level deliverable elements. Once the team has a detailed and visible structure, updating, re-planning, re-estimating cost, and duration become simplified because all elements are itemized and visible. The WBS is also important because the cost centers are always derived from elements of the project deliverables. The WBS is the source of the product backlog, which in turn is broken down to the sprint backlog, providing input for the sprints and distributing the work to cost centers or other sprint teams. The WBS assures that the necessary actions are taken to produce the product or service that the customer demands. 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 team uses this approach for all deliverables, including more internal-facing deliverables, such as internal specifications, models, failure mode and effects analyzes (FMEA), and the total round of documents that any formal quality system requires. As in any project management methodology, tracking updates to the project scope or changing deliverables to meet requirements is where many projects go astray. In Scrum, the WBS is not simply an action item list, but a formal document designed to support cost and schedule reporting, or earned value management (EVM), a project management technique for objectively measuring project performance and progress. We can derive our action item lists, schedule, and budgets from the WBS. How deep should WBS go? We can deconstruct the WBS as far as we need to in order to put items into our product backlog planning document with minimal effort. This is another area where conventional product management projects go astray with missing items and misunderstood or nonexistent dependencies between tasks. The Scrum approach avoids these pitfalls because the focus stays on the immediate goal of the sprint, which is a very short defined period of time. This short planning horizon requires that we break down and understand the interactions for that specific sprint 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. Once we have these atoms, we're ready to go. We now take the atomic tasks and use these to populate the product backlog. If we have set up our breakdown correctly, we should not need to ever list the higher-order tasks. Completing the atomic tasks in appropriate order will automatically result in completion of the higher-order task. EE Times-Asia eetasia.com Copyright 2011 emedia Asia Ltd. Page 2 of 5

3 This deconstruction also allows us to estimate the amount of work we can fit into the sprint. The sprint is "time boxed" so the amount of work taken on should not exceed the amount of time allotted. This is important when constructing the sprint backlog and during subsequent execution. A typical sprint will last from two to four weeks. The Scrum sprint A sprint backlog is the immediate list of the tasks to achieve the prioritized product backlog; it breaks down specific elements from the product backlog derived from the WBS into smaller ones (called a decomposition). The team selects meaningful tasks from the product backlog to populate the sprint backlog. These tasks are prioritized by the customer and by the team according to technical aspects and dependencies. The customer identifies which features have the highest priority and what they want first. These tasks can be those the team thinks it can do quickly or, more importantly, can accomplish in priority order so long as the team remembers the dependencies that is, when one task is dependent on the completion of another task. The sprint list is quasi-sacred. That means the sprint team should only consider breaking the sprint if a dire emergency occurs and a higher-level champion is willing to override the sprint. Otherwise, the goal is to complete the tasks while tracking them with a burndown chart. The burndown chart will show us progress against plan. In fact, the burndown chart is to Scrum project management as the EVM chart is to conventional project management. Follow up may reveal that the team bit off too much to chew or that the team is subject to interruptions from other parts of the enterprise. The real benefit over the EVM technique is that you see the performance almost immediately, the duration is only two to four weeks, and the burndown chart is updated daily. If the team can't execute to plan, 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, components from the product backlog can be added. Table 2 represents a first-pass sprint list. The boxes to the right can be used as a crude estimate of progress. Figure 1 shows an EVM chart and figure 2 shows a burndown chart. Table 2: A first pass sprint list. EE Times-Asia eetasia.com Copyright 2011 emedia Asia Ltd. Page 3 of 5

4 Figure 1: An earned value management chart. Figure 2: A burndown chart. Daily sprint meetings The sprint itself will last somewhere between fourteen days to a month. The team members discuss the status of the project and obstacles to success during the daily sprint meetings, by telling what did they did yesterday, what they're doing today, and where the bottlenecks and road blocks are. The Scrum master, who is the equivalent of the project manager, facilitates the meeting. The burndown chart is reviewed and the areas of expected progress and newly discovered risks are openly discussed. This open discourse identifies areas of interference for making the progress defined by the sprint backlog and the burndown chart. The Scrum master and the project stakeholder then work to expediently resolve these areas. Sprint retrospective At the end of the sprint, the team members review what they have done, what they did well, and what they could do better. This meeting and activity is analogous to the "white book" exercises of conventional project management. The benefit of the sprint retrospective is that the team doesn't wait until the end of the project or end of a project phase before critiquing. A critique at the end of each two-to-four week sprint makes it possible to learn something while delivering the product and integrate that learning into the subsequent sprints. The retrospective need not be led by the Scrum master and this meeting should be brief but thorough. At the end of the retrospective, the team plans for the next sprint. Since Scrum is a technique with intensified focus and accelerated tempo, the meeting schedules should not get in the way. The meetings should be organized well enough that the team is not wasting the time. You know you've achieved this goal when the complaints about the meetings lessen or disappear. EE Times-Asia eetasia.com Copyright 2011 emedia Asia Ltd. Page 4 of 5

5 Scaling up We can scale our Scrum approach to larger development processes by creating the Scrum of Scrums. Either the Scrum master from a Scrum team at one level becomes a team member at the next higher level if this approach makes sense, the team elects a team member to represent them, or rotating representative from the team goes, giving every team member a chance to represent the group. Not just for rugby In our personal experience, we have used the Scrum approach in a line management setting. We employed the Scrum philosophy years ago in a way we refer to as proto-scrum. In either event, we found no difficulties scaling the process to meet our needs. Some areas that were less than satisfactory were the burndown charts (because they were complicated) and the full-fledged WBS. On the other hand, the team enjoyed the improvement in the steadystate list of projects they were working on, and the daily Scrum meetings improved communication to the point where different departments were achieving cross-fertilization of capabilities. In addition, following Scrum enhanced the team's "buy-in" and camaraderie. About the authors Jon M. Quigley, PMP CTFL, is the manager of the Electrical and Electronics Verification and Test Group at Volvo 3P in Greensboro, North Carolina. He is also a principal of Value Transformation, LLC, a product-development training and cost-improvement organization. He has more than 20 years of product-development experience, ranging from embedded hardware and software through verification and project management. Kim H. Pries, APICS CPIM, is a senior member of the American Society for Quality with the following certifications: CQA, CQE, CSSBB, CRE, CSQE, and CMQ/OE. She is a principal with Value Transformation, LLC. Endnotes and references 1. Pries, Kim H. and Jon M. Quigley. Scrum Project Management. (Taylor and Francis's CRC Press) 2. U.S. Department of Defense military handbook (MIL-HDBK-881x). 3. Pries, Kim and Jon Quigley. "Taking a Scrum Approach to Product Development," Digital Software Magazine, July Pries, Kim and Jon Quigley. "Defining a Work Breakdown Structure," Digital Software Magazine, April EE Times-Asia eetasia.com Copyright 2011 emedia Asia Ltd. Page 5 of 5