Better Software - November 2007 - (Page 26)

provide “informational” metrics so that teams can evaluate their own performance and work on improving outputs. One of the simple metrics I use with teams during retrospectives is to ask the question “From both a performance (stories delivered) and a team-effectiveness perspective, are you doing the best you possibly can?” This is very different from measuring against a plan. I find most teams are honest in their evaluation of themselves and what they need to do to improve. A single article doesn’t provide space to examine the details of a quantitative output-measurement system, but there are approaches—schedule, productivity, cost, etc. (for example, Lawrence H. Putnam and Ware Myers’s Five Core Metrics: The Intelligence Behind Successful Software Management)—that allow a team to: • Compare its progress over time against itself—Are we getting better? • Compare performance against other internal teams—How do we compare with others in our organization? • Compare performance against an external measure of like industries or projects—How do we compare with other companies? One of the clear advantages of measuring relative team performance rather than how well a team performed against a plan is that there are no upper limits to improvement (target). Since everything is relative, good teams will strive to get bet26 ter, not just try to meet a target. Teams that only have to meet a fixed target tend to manipulate that target to their advantage and then slack off once the target is reached. Relative performance keeps constant internal pressure on teams to improve. Conclusion Measurement systems are crucial to creating an agile enterprise, particularly for those projects that implement new products, services, or processes that will create your future company. If you are creating the future, an extra month or a few extra dollars will be insignificant. If you don’t deliver value or you don’t deliver innovation, that will be significant. We cannot continue to ask teams to be innovative, flexible, and adapt to changing competitive conditions and then measure their performance by forcing them into narrow expectation alleys. We have to be as innovative with our measurement systems as we are with our methodologies. In conclusion, I want to return to one of the guidelines for APMS design: “Build the measurement system on a foundation of trust, honesty, and an intent to increase organizational value.” Those who have studied the agile movement understand that these agile, adaptive approaches are really social and management style movements. In my book Adaptive Software Development, I outline the differences between what is typically known as a command-and-control style of management and what I call a leadership-collaboration style. Extreme www.StickyMinds.com Programming (XP), Crystal, and Scrum all profess similar kinds of social changes—oriented toward improving the human dimensions of our workplaces and thus improving performance. If we want adaptive organizations, we have to think long and hard about what success and performance mean and align our measurements of success and performance to the values of the management style we choose. We have to build our measurement systems on the right intentions—to illuminate, not punish; to learn, not repeat; to adapt, not resist change. If we want to build adaptive organizations, then we must abandon fixed-performance contracts for a measurement system that aligns with these new intentions. Hopefully, APMS is a step in the right direction. {end} Jim Highsmith, considered a leader of the agile movement, consults with companies worldwide on agile practices. He is the author of Agile Project Management; Agile Software Development Ecosystems; and Adaptive Software Development, which won the Jolt Award. He is co-author of the Agile Manifesto and the Declaration of Interdependence. Sticky Notes For more on the following topic go to www.StickyMinds.com/bettersoftware. I References BETTER SOFTWARE NOVEMBER 2007 http://www.StickyMinds.com/bettersoftware 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.