Assessing Your Agility

Are you curious how “agile” your organization is? Do you wonder how you compare with other organizations that have been using agile for a similar amount of time? Do you want an authoritative source of information to help guide your successful transition to agile?
Mike Cohn and Kenny Rubin present a framework for assessing organizational agility. Specifically, they examine the areas of teamwork, requirements, planning, technical practices, quality, culture, and knowledge creation. Mike and Kenny describe how to use the Comparative Agility framework to assess agility at various times during an organization's adoption of agile and how to derive actionable information from each assessment.

Transcript

1. ® Assessing Your 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 Object Technology / Smalltalk 0=?4J0/
   '.=@8
   (=,490= Mike Cohn Author of two popular books on agile development Co-founder of Agile Alliance and Scrum Alliance 0=?4J0/
   '.=@8
   (=,490= 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. ® ':80
   >;0.4J.
   <@0>?4:9> 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 F The Assessment Framework F Assessment Process F Preliminary Industry Results F Sample Company Results 6
7. ® Assessment framework Characteristics (3–6 per dimension) Dimensions (7 total) Questions (~125 total) 7
8. ® Seven assessment dimensions Teamwork &0<@4=0809?> 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; 1=0<@09?7D
   @;/,?0/
   created by team with full buy-in Planning (dimension) Planning levels Critical variables Progress tracking Source When Characteristics All upfront Spread throughout F We do the right amount of upfront planning; helpful without being excessive. F Effort spent on planning is spread approximately evenly throughout the project. Questions F True F More true than false F Neither true nor false F More false than true F False Responses An Example 9
10. ® (30
    &0<@4=0809?>
    Dimension Collected at different levels of detail; progressively =0J90/
    .:9A0=>,?4:9 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. ® &0<@4=0809?> Communication Focus Written requirements are augmented with discussion. (1.
    -.=*25<
    8/
    *
    /.*=>;.
    *;.
    J.<1.-
    8>=
    27
    just-in-time discussions. Our product owner is available to discuss features during the iteration. We acknowledge that not all details can be ,87?.B.-
    27
    @;2==.7
    <9.,2I,*=287< 11
12. ® &0<@4=0809?> Level of detail Teams are able to start projects with incomplete requirements. >;270
    *7
    2=.;*=287
    =1.
    <9.,2I,
    -.=*25<
    8/
    some features are negotiable. Requirements are represented at different levels of detail based on how soon we expect to implement them. 12
13. ® &0<@4=0809?> 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. ® &0<@4=0809?> 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 F Assessment Process F Preliminary Industry Results F Sample Company Results 15
16. ® Assessment approaches Consultative Administered to a team of people by a consultant :9>@7?,9?
    J77>
    49
    ?30
    <@0>?4:99,4=0
    -,>0/
    :9
    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 F Preliminary Industry Results F 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 1 Year 2 Years 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 &0<@4=0809?> 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 :=
    9:
    8,9@,7
    ?0>?492
    =0<@4=0/
    All types of testing (performance, integration, scalability, etc.) are performed in each iteration. Testers are productive right from the start of each iteration. 77
    -@2>
    ,=0
    JC0/
    /@=492
    ?30
    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 ,9>B0=
    B,>
    ?:
    ?30>0
    <@0>?4:9> 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 F 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 /0?,47
    ;=:2=0>>4A07D
    =0J90/
    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 /0?,47
    1=0<@09?7D
    @;/,?0/
    .=0,?0/
    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 ',?4>J0/
    B4?3
    >?,?@>
    <@:
    800?>
    deadlines through heroic effort; command-and-control Culture Trusting, collaborative, and adaptive 91=0<@09?
    :=
    490110.?4A0
    =0K0.?4:9
    ,9/
    ?0,8
    49?0=,.?4:9>
    inconsistent use of iterations Knowledge Creating All work performed in strictly ,/30=0/?:
    4?0=,?4:9>
    1=0<@09?
    =0K0.?4:9
    1:.@>
    :9
    ?0,8
    70,=9492 Code written by programmers working alone; little emphasis on testing; code becomes harder to 8,49?,49
    :A0=
    ?480
    491=0<@09?
    integration and system builds Technical Practices Code written in pairs using test- driven development; code not allowed to degrade over time; 1=0<@09?
    49?02=,?4:9
    >D>?08
    -@47?
    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 8,49?,49
    :A0=
    ?480
    491=0<@09?
    integration and system builds Technical Practices Code written in pairs using test- driven development; code not allowed to degrade over time; 1=0<@09?
    49?02=,?4:9
    >D>?08
    -@47?
    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. 0A07:;0=>
    ,9/
    ;=:/@.?
    :B90=>
    ;,=?4.4;,?0
    0<@,77D
    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 F Take the survey, its free! F Get a report summarizing your answers F We’re working on getting comparative reporting available F Timeline is somewhat dependent on how much more data we get and how fast F You can opt-in to a 9:?4J.,?4:9
    74>?
    ?:
    >?,D
    49
    touch with new reporting features F Visit the website for details: F 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