You Get What You Measure

Metrics, when they are used at all, serve organizations as a way to understand where project teams stand. When it comes to software development, however, these mechanisms can sometimes backfire. As adoption of lean/agile practices and methods becomes more prevalent, organizations struggle with finding the right measures to understand team adoption and progress. In this presentation we will show that what we measure (about teams or individuals) can cause sub-optimal behavior--by beginning the session with a paper-and-scissors snowflake manufacturing game. After comparing the results, and seeing in fact that we get what we measure, we'll move on to a discussion about software measurement. We will start by talking about why we measure and the fallacy of the "measure everything" mindset. Then we'll discuss the popular metrics used today and the pitfalls of using them. We will explain the powerful concept of challenging existing norms and empowering team members to define their own standard work. Finally, we'll close with a discussion on how to avoid the lean/agile treadmill by keeping things new and exciting. 

Part I: Why Measure? 45 minutes

Snowflake Manufacturing Teams break into groups of five, reserving one team to play the role of "client" alternating teams get rigid process rules or self-organizing team rules teams are given 5 minutes to produce as many snowflakes as possible now teams take their snowflakes to market, and see if the "clients" will buy ? group retrospective: we find out that only "beautiful" snowflakes sell, and we have a lot of waste! (beautiful is defined in the client instruction page) shuffle teams, then iterate again, with a new objective: produce the most snowflakes that are also beautiful enough to sell.

Part II: What Measurements are Useful? 45 minutes

Why We Measure Quantify where we are and what we need To share best practices Benchmarking to determine the effect of change  Popular metrics (and pitfalls) Size of code/LOC (Line of code) Code coverage Unplanned feature Change  Schedule and Budget Compliance  Cycle Time  Velocity (story points or story count per sprint)  Defect count (at various phases)  Return on investment  Innovations per sprint / slack time  Artifacts generated  Function points  Standard Work  Taiichi Ohno says standards should be challenged constantly  Let individuals/teams define standard work so that they feel ownership.  Supporting Kaizen Metrics are to be short-lived: set a goal, define a metric, make changes and gauge whether you're going in the right direction. Discard the metric once your goals are met. Like statistics, all metrics lie--they are a limited view of the whole story, so don't take them too seriously. Use them as indicators for further investigation. 

While metrics appeal to our logical/quantitative side, not all things can be measured--and some of the most important things are not measurable. Keep a view of the whole system, and value qualitative attributes of our work too!  Part III: Beyond Metrics: Get What You Really Want (90 minutes)  A Brief History of Management for Knowledge Workers As Peter Drucker says, the most difficult part of management is figuring out what our goals should be.  Along the same vein, Russell Ackoff says "it's better to do the right thing wronger than the wrong thing righter." XP has taught us to take baby steps, to move iteratively so we can get feedback before we go too far in the wrong direction. The Lean Startup community has pushed this to yet another extreme by finding ways to get feedback before even building a product.  How to Build What The Customer Wants Validated Learning > Working Software > Comprehensive Documentation  Baby Steps > Big Steps  End-to-end > optimizing subsystems  Self-organization > binding objectives Team Ownership of Product > Proxy Client / Product Owners  Soft-spokenness, modeling, and coaching > High-pressure management  Smaller teams > bigger teams  Simplicity > Complexity  Focus and effectiveness  Team synch points  Managing energy instead of time  Product Road Maps  The Lean/Agile Treadmill  Busy, busy, busy == never get anything important done  Slack creates disruptive change == creates value  Product success makes the product obsolete (c.f. Drucker: trains -> Ford's Model T -> GM) The most value comes from our links to people / ideas outside our context (c.f. Block: social capital)  Are we going to sprint all iteration long?  The Power of Positive Modeling Growing your influence: applying Weinberg's Law of Raspberry Jam -- small meetings! Idea farming: planting seeds and watch them grow Peer Feedback  Keeping it Light  Making Work Fun / Playful  All this gives you teams that go above and beyond!

Type: Tutorial

Author: Ravindar Gujral and Andre Dhondt

Duration: 4 hours

When: 13 of May at 9:00

Where: Conde meeting room