July 28, 2005Copyright Jon Spence All Rights Reserved 1 There Has to Be a Better Way! Jon W. Spence Sr. Principal Software Engineer & Technical Fellow Medtronic, Inc.

July 28, 2005Copyright Jon Spence All Rights Reserved 2 Our Struggle Many theories about the problem: –Process problem. –Architecture problem. –Tools problem. Specific problems we encountered: –Long planning horizons. –Rigidity in financial plans. –Over specifying how to do things.

July 28, 2005Copyright Jon Spence All Rights Reserved 3 Enter Agile Started studying “Agile Software Development” in Invited speakers. Attended conferences. Participated in local Agile groups. Studied XP, Scrum, and Lean.

July 28, 2005Copyright Jon Spence All Rights Reserved 4 High Potential Practices Daily meetings Small teams Test-driven development Pair programming Iterative & incremental development Simple design Refactoring Co-location Customer Coach Reflection

July 28, 2005Copyright Jon Spence All Rights Reserved 5 Defined vs. Empirical Defined process management: –can be used to control processes with well-defined inputs, accurate controls, and reliable results. These processes are stable, predictable, and require little intervention. Empirical process management: –must be used to control processes with unreliable inputs, imperfect controls, and unexpected results. These processes are at the edge of chaos, hard to predict, and require frequent inspection and adaptation.

July 28, 2005Copyright Jon Spence All Rights Reserved 6 My Organization & Agile We are highly driven by product quality. Guard our legacy and culture fiercely. Agile can appear intolerable in our environment. Our study suggested Agile fundamentally sound and compatible with regulated and even safety critical environments. We recognized the need to fit within our constraints, culture, and legacy.

July 28, 2005Copyright Jon Spence All Rights Reserved 7 Who’s Responsible for Change? Where should the drive come from? –Above, below, middle? Product development, not software shop. Decision XP/Agile Universe One person’s influence not enough.

July 28, 2005Copyright Jon Spence All Rights Reserved 8 Friends & Allies Many and varied: –Department’s senior director. –Mainline product software project manager. –Department’s process architect. –Key members of software development team. Influence tools: –Conferences. –Discussions. –Technical Forum.

July 28, 2005Copyright Jon Spence All Rights Reserved 9 Manage Up Seek out friends and allies in immediate and upper management. Address their concerns, fears, myths, and misunderstandings. –Quality, schedule, milestones, productivity. Manifesto key to Agile’s solid foundation & source of managers’ allergic reactions. Emphasize Agile’s values, principles, & practices rationally & reasonably.

July 28, 2005Copyright Jon Spence All Rights Reserved 10 Our Initial Proposal Process ownership. Process discipline. Small teams. Customer. Coach. Planning game. Daily meetings. Incremental & iterative. Periodic reflection. Simple design. Test-first development. Refactoring. Pair programming. Co-located teams. Continuous integration. Collective code ownership.

July 28, 2005Copyright Jon Spence All Rights Reserved 11 Empirical Process at Work Inspect & Adapt constantly: –Daily meetings. –Reflect each iteration. –Pair develop, test-first. –Customer feedback. –Small investments of time and effort.

July 28, 2005Copyright Jon Spence All Rights Reserved 12 What We Pay Attention To Rework Velocity Point Growth

July 28, 2005Copyright Jon Spence All Rights Reserved 13 What Have We Changed/Learned? Labs –Crucial and worth fighting for! Team Size –4-6 (plus coach) is our sweet spot. Customer –Team of customer proxies. Planning Game –Combined large group/small team activity. Product Backlog –Make it visible to everyone.

July 28, 2005Copyright Jon Spence All Rights Reserved 14 Survey Metrics Our Agile implementation (slightly to strongly agree): –Makes work more enjoyable (100%). –Helps us work well together (100%). –Helps us find bugs earlier (100%). –Helps us learn and cross-train (100%). –Helps us work well with SW QA (100%). –Helps us estimate better (100%). –Makes project progress more visible (96%). –Is empowering (96%). –Helps us achieve higher quality (92%). –Is helping us develop faster (88%). –Helps us see our impacts on project (88%). –Helps us produce better requirements (85%). –Helps us work well with other functional teams (68%).

July 28, 2005Copyright Jon Spence All Rights Reserved 15

July 28, 2005Copyright Jon Spence All Rights Reserved 16 Anecdotes “bugs found much, much earlier” “logistically can be difficult” “interpersonal drain” “makes things visible that were previously hidden” “like the sprint tracking so that we can better predict whether we can make commitments and make adjustments as needed” “we in QA do not do as many practices as Development, but it helps us that Development practices Agile” “partnering on feature definition enabled quick resolution of issues” “it gives a big organization a chance to be small again” “generating excitement” “Why are Agile people so loud?”

July 28, 2005Copyright Jon Spence All Rights Reserved 17 Conclusion Evidence tells us Agile Software Development is making a positive difference in our world. Interest in & respect for Agile practices growing. More work to do, especially on: –test-first, –pairing, –refactoring, –simple design, –our labs, –points and velocity, –customer demos, and –coaching. No recipe, no silver bullet – sorry!

July 28, 2005Copyright Jon Spence All Rights Reserved 18 A Better Way? Applying Agile Software Development’s values, principles, and common sense to your world while respecting your local constraints and culture will let you benefit from empirical process management’s power to improve your ability to deliver high value software to your business and customers.

July 28, 2005Copyright Jon Spence All Rights Reserved 19 Thanks! Questions?