Assessing Your Agility: Introducing the Comparative Agility Assessment
5 likes3,828 views
This document introduces the Comparative Agility Assessment, a framework and survey developed by Kenny Rubin and Mike Cohn to evaluate organizations' adoption of agile practices. The assessment measures seven dimensions of agility through 125 questions. It provides individual and comparative results to identify strengths, weaknesses, and areas for improvement. The document outlines the assessment framework, process, preliminary industry findings, and an example of using results to prioritize an organization's agile transformation goals.
Assessing Your Agility: Introducing the Comparative Agility Assessment
- 1. ® AssessingYour Agility: Introducing the Comparative Agility Assessment Kenny Rubin and Mike Cohn Agile Development Practices November 13, 2008 1
- 2. ® Who We Are Kenny Rubin Former managing director of Scrum Alliance Early-market thought leader in ObjectTechnology / Smalltalk Mike Cohn Author of two popular books on agile development Co-founder of Agile Alliance and Scrum Alliance 2
- 3. ® Scenario Our company has decided to use agile We get training and maybe some coaching After six months, management wants to know: “How are we doing at adopting agile?” 3
- 4. ® Are we where we should be? In which areas do we need to improve? In which areas are we excelling? How are we doing relative to others? How are we doing relative to our competitors? 4
- 5. ® We need an assessment framework An instrument for “measuring” agility Desirable attributes Must evaluate multiple dimensions of agility Must lead to actionable recommendations 5
- 6. ® Agenda The Assessment Framework Assessment Process Preliminary Industry Results Sample Company Results 6
- 7. ® Assessment framework Characteristics (3–6 per dimension) Dimensions (7 total) Questions (~125 total) 7
- 8. ® Seven assessment dimensions Teamwork Planning Technical practices Quality Culture Knowledge creation 8
- 9. ® All-encompassing, task-oriented plans created upfront; reluctance to update plans; little buy-in to dates from team Created at multiple levels of detail; created by team with full buy-in Planning (dimension) Planning levels Critical variables Progress tracking Source When Characteristics All upfront Spread throughout We do the right amount of upfront planning; helpful without being excessive. Effort spent on planning is spread approximately evenly throughout the project. Questions True More true than false Neither true nor false More false than true False Responses An Example 9
- 10. ® Dimension Collected at different levels of detail; progressively focused, augmented with documentation Requirements Document-centric; collected upfront; little acknowledgement of emergence Four characteristics Communication focus Level of detail Emergence Technical design 10
- 11. ® Communication Focus Written requirements are augmented with discussion. just-in-time discussions. Our product owner is available to discuss features during the iteration. We acknowledge that not all details can be 11
- 12. ® Level of detail Teams are able to start projects with incomplete requirements. some features are negotiable. Requirements are represented at different levels of detail based on how soon we expect to implement them. 12
- 13. ® Emergence Change is a natural part of our business; we accept it and embrace it at reasonable times. Product owners can change requirements without a lot of fuss. Development teams can request and negotiate requirements changes with product owners. Product owners acknowledge that sometimes features turn out to be bigger than anyone thought. 13
- 14. ® Technical design Projects begin with a big, distinct technical design phase. Technical design occurs iteratively throughout a project. Technical design is a team activity rather than something performed by individuals working alone. 14
- 15. ® Agenda ✓ The Assessment Framework Assessment Process Preliminary Industry Results Sample Company Results 15
- 16. ® Assessment approaches Consultative Administered to a team of people by a consultant responses collected during interviews Self-administered Individuals working on projects complete either paper or online version of the survey Online version is at www.ComparativeAgility.com 16
- 17. ® Assessment philosophy Not trying to determine maturity levels Organizations do not need to be perfect Only better than their competitors Lead to the idea of a Comparative Agility Assessment “How am I doing compared to my competition?” 17
- 18. ® Sample from online survey 18
- 19. ® Agenda ✓ The Assessment Framework ✓ Assessment Process Preliminary Industry Results Sample Company Results 19
- 20. ® 17% 4% 16% 63% Team Department Division Organization As you respond to this survey, will you be thinking mostly about your: 7% 11% 15% 13% 54% 0-6 Months 7-12 Months 1Year 2Years Longer How long had this group been doing agile development prior to starting this project? 20
- 21. ® 3% 14% 25% 26% 33% Commercial Software Web Development Internal Software Contract Development Other Which best characterizes this project? 9% 11% 12% 31% 38% 1-10 11-25 26-50 51-100 > 100 About how many people were or are on the project being assessed? 21
- 22. ® 0 1 2 3 4 5 Seven Dimensions All data -2 Std Devs -1 Std Dev +1 Std Dev +2 Std Devs Knowledge Creation Culture Quality Technical Practices Planning Teamwork 22
- 23. ® 0 1 2 3 4 5 Technical Practices All data -2 Std Devs -1 Std Dev +1 Std Dev +2 Std Devs Continuous Integration Refactoring Test-driven development Pair programming Coding Standard Collective Ownership 23
- 24. ® 0 1 2 3 4 5 Quality.Timing -2 Std Devs -1 Std Dev +1 Std Dev +2 Std Devs There is no big handoff between programmers and testers either during or at the end of an iteration. At the end of each iteration there is little All types of testing (performance, integration, scalability, etc.) are performed in each iteration. Testers are productive right from the start of each iteration. iteration in which they are found. 24
- 25. ® Interesting results: Length of agile experience 0 +1-1 2+ years ≤ 6 months Knowledge creation Culture Quality Technical practices Planning Requirements Teamwork x x x x 25
- 26. ® Agile web development Compared to the overall sample, web projects: Are more likely to contain duplicated code, less likely to have a coding standard, and do less refactoring Are these things less important on web projects? Are less likely to be built automatically once a day Are more likely to have collocated product owners And more likely to have product owners who respond in a timely manner Are more likely to be done in mini-waterfalls 26
- 27. ® What do you think the average Teams know their velocity True (5) False (1) Product owners provide acceptance criteria for each feature We don't cancel training, holiday, and vacation time when behind schedule Testers are productive right from the start of each iteration x x x x 27
- 28. ® Agenda ✓ The Assessment Framework ✓ Assessment Process ✓ Preliminary Industry Results Sample Company Results 28
- 29. ® How does a company use this data? Stock their improvement backlog with items for teams (including non-delivery teams) to work on Identify Big Hairy Audacious Goals (BHAGs) to ask teams to meet Identify leading and lagging indicators of success to gauge and measure progress 29
- 30. ® Dimensions of an example company Directed; individuals work in silos; multiple locations; multiple projects Teamwork Self-organizing, cross-functional teams; dedicated team members; collocated Document-centric; collected upfront; little acknowledgement of emergence Requirements Collected at different levels of conversation-focused, augmented with documentation All-encompassing, task-oriented plans created upfront; reluctance to update plans; little buy-in to dates from team Planning Created at multiple levels of by team with full buy-in x x 0 +1-1 30
- 31. ® Quality is tested in after development; little emphasis on or effective use of automation Quality Quality is built into the product during each iteration; automated unit and acceptance tests deadlines through heroic effort; command-and-control Culture Trusting, collaborative, and adaptive inconsistent use of iterations Knowledge Creating All work performed in strictly Code written by programmers working alone; little emphasis on testing; code becomes harder to integration and system builds Technical Practices Code written in pairs using test- driven development; code not allowed to degrade over time; and tested at least once per day x 0 +1-1 31
- 32. ® “Hmm, those Technical Practices and Quality scores look low compared to other companies. Let’s dig deeper.” Code written by programmers working alone; little emphasis on testing; code becomes harder to integration and system builds Technical Practices Code written in pairs using test- driven development; code not allowed to degrade over time; and tested at least once per day 0 +1-1 32
- 33. ® Test-driven development Pair programming Refactoring Continuous integration Technical Practices characteristics Coding standards Collective ownership 0 +1-1 33
- 34. ® Quality characteristics Automated unit testing Timing Customer acceptance testing 0 +1-1 34
- 35. ® Teams feel an appropriate amount of pressure to meet deadlines. Product owners are willing to consider delivering less than 100% of a solution. in release planning Management Style: If your company just received this assessment, what might you do? Product owners understand that sometimes solving 20% of the problem delivers 80% of the value. We don’t cancel training, holiday, and vacation time when behind schedule. We maintain a high rate of productivity without being overworked. Management allows team members to make the decisions that should be theirs to make. 0 +1-1 35
- 36. ® How you can participate Take the survey, its free! Get a report summarizing your answers We’re working on getting comparative reporting available Timeline is somewhat dependent on how much more data we get and how fast You can opt-in to a touch with new reporting features Visit the website for details: www.ComparativeAgility.com 36
- 37. ® Contact information Kenny Rubin krubin@innolution.com (303) 827-3333 Mike Cohn mike@mountaingoatsoftware.com (720) 890-6110 www.ComparativeAgility.com 37