Better Software - November 2007 - (Page 25)

Figure 1: Parking lot report showing project progress feature value, whether qualitative or quantitative, gets teams closer to outcomes than scope and schedule. The second question is then focused on constraints: “Did the project community deliver within acceptable cost, schedule, and defect constraints (not estimates)?” Outcome metrics are intended to guide decision making—to define the desired outcomes and then trust people to find the best way to produce those outcomes. Plans are used to guide project teams but not to encase them in straitjackets. Teams will strive to deliver to the plan, but delivering the desired outcomes will take precedence. Constraints Outcomes are some measure of business value. But businesses require more than outcomes themselves; they require that outcomes be generated within certain constraints in order to make them financially viable. At a high level, we need to understand constraints in three areas: scope, schedule, and cost. The measurement-design guidelines give us as few narrow constraints as possible (to encourage adaptation); therefore, only one of these three characteristics should be a must constraint, and the others should be want constraints. For example, if the project’s objective relates to a governmental requirement that must be met by some date, then the must constraint is that schedule. My definition of a constraint is “a measured characteristic of a project that if projected to exceed its target would subject the project to immediate cancellation or major revision requiring sponsor approval.” Constraints should be broad in order to encourage flexibility and experimental design—and thereby innovation. When looking at performance metrics in this way, we should not forget that value (outcome) is not independent of cost and schedule. For example, a project’s viability (ROI) might depend on delivering six high-level capabilities, constrained by a June delivery date (must) and a $250,000 cost (want). 3. Has the project community adapted its plans, activities, and strategies to deliver within the project’s constraints? Project status historically has been shown in Gantt charts that emphasize activities and schedule. Agile projects need new types of status reports, like the “parking lot” diagram in figure 1 that emphasizes value first (each box represents features or stories that have been completely implemented and acceptance tested) and schedule second. While the real outcome is value, the assignment of cost to stories can be difficult and time consuming. If teams are dedicated to linking relative value to stories during the project, then parking lot diagrams (or similar story burn-up charts) reflect outcomes much more directly than Gantt charts. If we want managers and others to think differently about performance reporting, then we need to change the reporting mechanisms to reflect the most important characteristic—the outcomes. Output Performance Metrics Managing people is a key ingredient of project management that includes coordination, motivation, conflict management, collaboration, and more. We want teams to increase their productivity. We want teams to deliver faster. We want teams to deliver low-defect products. However, we won’t achieve these goals by measuring conformance to plan; we will achieve them by measuring these characteristics directly and comparing progress against external and internal benchmarks. Measuring team performance against plan often leads to poor results. If a team is assigned to a project where the plan is heavily padded or buffered and it succeeds, is it then a high-performance team? If a team is assigned to a project whose plan is completely and utterly unreasonable and it fails to achieve the plan, is it then a low-performance team? Wouldn’t comparing team performance against realistic internal and external benchmarks be better? We want teams to improve their performance, and, in an agile environment, we encourage teams to work on improving their own performance. Management’s job is to 25 Measuring Outcomes and Constraints The three key questions to be answered by outcome metrics are: 1. Are we consistently delivering chunks of functionality that are useful to the customer team? 2. Have we delivered that functionality within the constraints set by the customer team and sponsor? www.StickyMinds.com NOVEMBER 2007 BETTER SOFTWARE http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - November 2007

Better Software - November 2007 Contents MarkYour Calendar Technically Speaking What’s Happening @StickyMinds.com Code Craft Test Connection Management Chronicles The Measure of a Management System Behind the Scenes A Story About User Stories and Test-Driven Development Product Announcements The Last Word Ad Index

Better Software - November 2007

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.