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! http://dhondtsayitsagile.blogspot.com
Type: Tutorial
Author: Ravindar Gujral and Andre Dhondt
Duration: 4 hours
When: 13 of May at 9:00
Where: Conde meeting room