Transitioning to Agile: A Guide to Good Practices in Context

Transitioning to an agile process from a traditional process is fraught with potential dangers. This class will cover a dozen practices that have proven effective in helping organizations transition to an agile development process. Learn how to overcome resistance, communicate progress, deal with nay-sayers, get the project off on the right foot and select an appropriate first project.

Transcript

1. © Mountain Goat Software, LLC Mike Cohn President Mountain Goat Software Lafayette, Colorado mike@mountaingoatsoftware.com Transitioning to Agile A Guide to Good Practices in Context 1
2. Founding member and director of Agile Alliance, Scrum Alliance, and Agile Project Leadership Network Founder of Mountain Goat Software Consultant, author, and speaker Mike Cohn - background © Mountain Goat Software, LLC 2
3. © Mountain Goat Software, LLC The twelve things you must do 1. Dispense with predictability 2. Treat the transition as a project 3. Use a congruent approach 4. Pick the right project 5. Get the right people on (and off) the project 6. Start development with a beachhead team 7. Overcome resistance 8. Have a customer 9. Engage the change agents 10.(5T53D 11.Don’t try it all at once 12.Follow a guide 3
4. © Mountain Goat Software, LLC L How we traditionally view our organizations L Behavior is highly predictable L Once set in motion, will continue in motion L Predictable L An organization change strategy can be mapped out: L ?
   D89C
   SBCD
   D85>
   D81D
   D85>
   CE38
   1>4
   C? L And we’ll end up right where I predict Dispense with predictability 1 4
5. © Mountain Goat Software, LLC “This machine imagery [Newtonian view] leads to the belief that studying the parts is the key to understanding the whole. Things are taken apart, dissected literally or S7EB1D9F5<I1>4
   D85>
   @ED
   213;
   D?75D85B
   
   G9D8?ED
   1>I
   C97>9S31>D
   <?CC
   *85
   1CCE=@D9?>
   is that the more we know about the workings of each piece, the more we will learn about the whole.” ~Margaret Wheatley in Leadership and the New Science 5
6. © Mountain Goat Software, LLC Is it top down or bottom up? L Two simplistic views of transitioning to agile: L Top down L Powerful leader shares a vision L Bottom-up L 
   D51=
   CD1BDC
   1>4
   5F5BI?>5
   5<C5
   C55C
   D85
   25>5SDC
   ?6
   D85
   new approach L But, transitioning to agile is neither top-down nor bottom-up L It’s everywhere, all together, all-at-once 6
7. © Mountain Goat Software, LLC What we do on projects L On projects we learn we cannot precisely anticipate: L our users’ requirements L how long it will take to develop a feature or entire system L which design will be best L the set of tasks necessary to develop a feature L So we devise alternative approaches L Rather than ask for upfront specs, we deliver partial solutions, solicit feedback, and repeat L Rather than design the whole system, we design incrementally and adjust based on what we learn L We need to do the same for the transition effort 7
8. © Mountain Goat Software, LLC Treat the transition as a project 2 L Establish an “Agile Transition Team” (“Agile Adoption Team,” etc.) L Who? L Sponsor—senior person responsible for success L Area managers or leads who can make it happen L Meet weekly L Run monthly iterations managing work from a Transition Backlog 8
9. © Mountain Goat Software, LLC Stocking the transition backlog L Brainstorm needed activities within these broad categories 1. Establish a sense of urgency 2. Create a vision 3. Communicate the vision 4. Empower others to act 5. Plan for, support and create short-term wins 6. Consolidate improvements 7. Inspect and adapt Ref: John Kotter, Leading Change, 1996. 9
10. © Mountain Goat Software, LLC An example transition backlog Decide how pervasive to go with Scrum—software development only or full company All Identify which issues Scrum can solve or help with. DF Set expectations that it will hurt. MC +>45BCD1>4
    8?G
    D5CD9>7
    G9<<
    SD
    G9D89>
    )3BE= TC Identify other groups/functions that will be affected. MC, DF Identify needed organizational changes—reporting, reviews, compensation, career paths, etc. Determine how we’ll communicate progress Are there agile project management tools we should use? 10
11. © Mountain Goat Software, LLC Use a congruent approach 3 Part of the move to agile is a move to self-organizing teams Moving to self- organization requires self-organization “You will self-organize!” 11
12. © Mountain Goat Software, LLC Pre-requisites of self-organization L A boundary within which self-organization occurs L Company, project, team, city, role, nationality Container L There must be differences among the “agents” acting in our system L Technical knowledge, domain knowledge, education, experience, power, gender Differences Transforming Exchanges L Agents in the system interact and exchange resources L Information, money, energy (vision) Glenda Eoyang: Conditions for Self-Organizing in Human Systems 12
13. © Mountain Goat Software, LLC Using the CDE model L When stuck thinking about how to nudge the organization think of the: L Containers L formal teams, informal teams, clarify (or not) expectations L Differences L Dampen or amplify them within or between containers L Exchanges L Insert new exchanges, new people, new techniques or tools 13
14. © Mountain Goat Software, LLC Pick the right project Duration Size Importance A business sponsor Pick this project 4 14
15. © Mountain Goat Software, LLC Size L Something that can be started with one team L Scale up the team using the principles shown later L Probably no more than 1-5 teams on initial project L Probably can’t scale any higher during a medium length project anyway 15
16. © Mountain Goat Software, LLC Duration L Pick a project with a medium duration L Probably 2-4 months L Medium for your organization will be different from mine L Don’t want too short L Won’t prove as much L “It only works on small projects” L Don’t want too long L Want to see value quickly 16
17. © Mountain Goat Software, LLC A business sponsor L Pick a project that has a business sponsor who will engage because: L You’ll need a business-side ally L 
    C1D9CS54
    C@?>C?B
    9C
    I?EB
    25CD
    chance of doing it again L *85
    25CD
    G1I
    D?
    81F5
    1
    C1D9CS54
    business sponsor is to start with one willing to be involved L Pick one who embraces agile 17
18. © Mountain Goat Software, LLC Importance L Pick an important project because: L People don’t change behavior unless they need to L )?=5
    @1BDC
    ?6
    179<5
    1B5
    496S3E<D L It will be hard to stick with it unless the project is important L Don’t pick one that is too risky L But if you pick a trivial project the results will be dismissed You can start in the middle of a project 18
19. © Mountain Goat Software, LLC “Don’t start with an initial ‘learning project’ that is of marginal importance. Start on a project that is absolutely critical to your company; otherwise it will be too 496S3E<D
    D?
    9=@<5=5>D
    1<<
    D85
    81B4
    D89>7C
    [agile] will ask of you.” ~Jim Highsmith in Adaptive Software Development Ecosysmtems 19
20. © Mountain Goat Software, LLC The ideal project L Has an active, engaged business sponsor L Is critical to your organization L Would likely or possibly fail if done in the status quo manner L Can start with 1 team L Will grow to no more than 5 teams L Lasts “a handful of months” 20
21. © Mountain Goat Software, LLC Get the right people on (and off) the project L Be aware that there are typically two teams 5 The project team The transition team 21
22. © Mountain Goat Software, LLC The project team L The project team should L Be cross-functional / multi-disciplinary L 5F5BI?>5
    >55454
    D?
    S>9C8
    1<<
    G?B;
    ?6
    1>
    9D5B1D9?> L Include opinion leaders L Both favorably disposed toward and opposed to agile L Include evangelists L Include those who’ve done it before (elsewhere) L Include a range of perspectives 22
23. © Mountain Goat Software, LLC The transition team L Responsible for guiding a transition to agile L Sometimes this is implicitly the same team as the project team L “if you do well, we’ll all switch” L Think about L Who has the power to make or break the transition to agile? L Who controls critical resources or expertise? L How will each be affected? L How will each react? 23
24. © Mountain Goat Software, LLC L Who will gain or lose something by the transition to agile? L Are there blocs likely to mobilize against or in support of the transition? L ?
    D51=
    =5=25BC
    81F5
    CE6S395>D
    3B54929<9DI
    D81D
    D85
    teams’ opinions and results are taken seriously? L Can team members put their personal interests aside in favor of the organizational goal? Additional transition team considerations 24
25. © Mountain Goat Software, LLC Who should not be on these teams L People with big egos L 97
    57?C
    S<<
    D85
    B??=
    <51F5
    <9DD<5
    C@135
    6?B
    ?D85BC L Don’t understand their own limitations L Snakes L Someone who poisons relationships among team members L Reluctant participants L Lack time or enthusiasm L But may have needed expertise or political clout 25
26. © Mountain Goat Software, LLC Start development with a beachhead team 6 L Cannot start effectively if focus is spread too thin L Give them the early infrastructural tasks L Their goal is to build enough of and the right parts of the system so that other teams can be added 26
27. © Mountain Goat Software, LLC Two approaches to expanding L Start with 1-3 teams and get them successful L Split those teams up and use members to seed new teams L Repeat Split and seed 1 L Start with 1-3 teams and get them successful L Keep teams together L Select 1-2 coaches from those teams L Use them to advise new teams L CC97>
    C@539S3
    B5C@?>C929<9D95C L Attend planning meeting L Attend 2 daily scrums per week L Spend 4 hours with the team per sprint Internal coaching 2 27
28. © Mountain Goat Software, LLC Overcome resistance 7 L Sell the problem, not the solution L No one wants a solution to a problem they don’t (think they) have L Be open to hearing better solutions than you have L Communicate why the change and why now L Put team members in touch with customers L Let them hear the problems you are hearing L =@81C9J5
    25>5SDC
    ?6
    D85
    381>75 L 5<@
    B5C9CD5BC
    S>4
    >5G
    B?<5C 28
29. © Mountain Goat Software, LLC Disposition to Change Continuum L Generally deliberate, disciplined and organized L Prefer change that maintains current structure L Enjoy predictability L May appear cautious L Focus on details and routine Conservers L May appear unorganized, undisciplined, unconventional L Prefer change that challenges the current structure L Will challenge assumptions L Enjoy risk and uncertainty L Little regard for policies Originators L $1@
    1@@51B
    @B13D931<
    17B5512<5
    1>4
    T5H92<5 L Prefer changes that emphasizes workable outcomes L More focused on results than structure L Open to both sides of an argument L Operate as mediators L Appear more team oriented Pragmatists From: Harvard Business Essentials: Managing Change and Transition 29
30. © Mountain Goat Software, LLC Balkan Peninsula Apple Computer Companies with lots of contractors Microsoft in 1995 Extent to which people agree on cause and effect No consensus Broad consensus Extent to which people agree on what they want No consensus Broad consensus “Tools of Cooperation and Change,” Christensen et al., Oct. 2006. 30
31. © Mountain Goat Software, LLC Power Tools Culture Tools Management Tools Leadership Tools Extent to which people agree on cause and effect No consensus Broad consensus No consensus Broad consensus Extent to which people agree on what they want 31
32. © Mountain Goat Software, LLC Power Tools Culture Tools Management Tools Leadership Tools Extent to which people agree on cause and effect No consensus Broad consensus No consensus Broad consensus L Charisma L Salesmanship L Role modeling L Vision L Negotiation LFiat LCoercion LThreats L(?<5
    5S>9D9?> LFolklore LRitual LTradition LReligion LDemocracy LApprenticeship LStrategic planning LFinancial incentives LHiring & promotion LTraining LStandards LMetrics programs Extent to which people agree on what they want 32
33. © Mountain Goat Software, LLC Have a customer 8 L To succeed you need a L Customer L Product Owner L Customer Team L Whatever you want to call it, you need one L Doesn’t have to “sit with the team” L But set your targets around the level of involvement you’ll get 33
34. © Mountain Goat Software, LLC Customer Involvement Time Customer Involvement Time Agile processes don’t require more customer involvement than a successful project with another process BUT the involvement is spread throughout the project. Customer involvement Traditional Agile 34
35. © Mountain Goat Software, LLC Engage the change agents 9 Change agents... L help others see problems and address them L articulate the need for a change L are accepted as trustworthy and competent L can see and diagnose problems L motivate people to change L work through others to translate intent into action 35
36. © Mountain Goat Software, LLC Identifying change agents L Find out who people listen to L These may not be people with formal authority L Look for people who think differently L 81>75
    175>DC
    1B5>RD
    C1D9CS54
    G9D8
    D85
    CD1DEC
    AE? L Consider new employees or others who may not be infected with a common mindset yet L Consider people with different backgrounds L The programmer with the art history degree 36
37. © Mountain Goat Software, LLC (5T53D 10 L The three most important words in agile: L D
    D85
    5>4
    ?6
    5138
    9D5B1D9?>
    B5T53D L Whole team gathers and discusses what they’d like to: Inspect and Adapt Continue doing Stop doing Start doing 37
38. © Mountain Goat Software, LLC A start, stop, continue list Start Stop Continue
    Showing the software to customers early
    Specifying acceptance tests early and with customers
    Doing code inspections
    Getting FitNesse into the nightly builds
    Trying to finish one story before moving to the next
    Being disrespectful of QA
    Making progress with the canonical database
    Emphasizing test automation 38
39. © Mountain Goat Software, LLC Don’t try it all at once 11 L Don’t try to do everything all at once L Start with the agile practices that seem most valuable in your context L Put other practices on your Transition Backlog L Prioritize them in as you go L Use Start/Stop/Continue meetings as a guide 39
40. © Mountain Goat Software, LLC My preferred sequence Requirements as user stories Foundational skills (testing and OOD/P) Estimate and create release plan Nightly or continuous build with tests 40
41. © Mountain Goat Software, LLC Follow a guide 12 L Follow the advice of someone who has been there, done that L An employee L A contractor L Outside mentor / coach L Train L Better design skills, unit testing and test automation, agile project management, estimating and planning L Can save you from many mistakes 41
42. © Mountain Goat Software, LLC Common sense? So try one-week iterations until you’ve mastered that. Two weeks will then be a breeze. “We’re having trouble delivering S>9C854
    C?6DG1B5
    9>
    DG?
    G55;CP So use smaller cards. “There’s not enough room to write requirements on cards.” So do it more often until you become so good at it that’s it not painful. “Integrating is painful.” 42
43. © Mountain Goat Software, LLC The role of consultants and employees in change programs Consultant Involvement Employee Involvement Diagnosis Capabilities Assessment Strategy Development Implementation From: Harvard Business Essentials: Managing Change and Transition 43
44. © Mountain Goat Software, LLC Mike Cohn contact info mike@mountaingoatsoftware.com www.mountaingoatsoftware.com  
     
    ?6S35 (303) 810-2190 (mobile) 44