Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Transitioning to Agile: A Guide to Good Practices in Context

008d9a555e3c3d1962761425b0e65a1e?s=47 Mike Cohn
June 19, 2012

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.


Mike Cohn

June 19, 2012

More Decks by Mike Cohn

Other Decks in Business


  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 ?D89CSBCDD85>D81DD85>CE381>4C? 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>4D85>@ED213;D?75D85B G9D8?ED1>IC97>9S31>D<?CC*851CCE=@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=CD1BDC1>45F5BI?>55<C5C55CD8525>5SDC?6D85 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>48?GD5CD9>7G9<<SDG9D89>)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 C1D9CS54C@?>C?B9CI?EB25CD chance of doing it again L *8525CDG1ID?81F51C1D9CS54 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?6179<51B5496S3E<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<DD?9=@<5=5>D1<<D8581B4D89>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>55454D?S>9C81<<G?B;?61>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=25BC81F5CE6S395>D3B54929<9DID81DD85 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 9757?CS<<D85B??=<51F5<9DD<5C@1356?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@539S3B5C@?>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 =@81C9J525>5SDC?6D85381>75 L 5<@B5C9CD5BCS>4>5GB?<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<51>4T5H92<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(?<55S>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>75175>DC1B5>RDC1D9CS54G9D8D85CD1DECAE? 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 DD855>4?651389D5B1D9?>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>9C854C?6DG1B59>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