Slide 1

Slide 1 text

© Mountain Goat Software, LLC Mike Cohn President Mountain Goat Software Lafayette, Colorado [email protected] Transitioning to Agile A Guide to Good Practices in Context 1

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

© 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

Slide 4

Slide 4 text

© 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

Slide 5

Slide 5 text

© 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 S7EB1D9F54D85>@ED213;D?75D85B G9D8?ED1>IC97>9S31>D 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

Slide 6

Slide 6 text

© 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?>555SDC?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

Slide 7

Slide 7 text

© 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

Slide 8

Slide 8 text

© 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

Slide 9

Slide 9 text

© 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

Slide 10

Slide 10 text

© 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

Slide 11

Slide 11 text

© 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

Slide 12

Slide 12 text

© 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

Slide 13

Slide 13 text

© 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

Slide 14

Slide 14 text

© Mountain Goat Software, LLC Pick the right project Duration Size Importance A business sponsor Pick this project 4 14

Slide 15

Slide 15 text

© 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

Slide 16

Slide 16 text

© 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

Slide 17

Slide 17 text

© 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

Slide 18

Slide 18 text

© 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

Slide 19

Slide 19 text

© 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 496S3ED1<<D8581B4D89>7C [agile] will ask of you.” ~Jim Highsmith in Adaptive Software Development Ecosysmtems 19

Slide 20

Slide 20 text

© 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

Slide 21

Slide 21 text

© 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

Slide 22

Slide 22 text

© 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

Slide 23

Slide 23 text

© 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

Slide 24

Slide 24 text

© 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

Slide 25

Slide 25 text

© 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

Slide 26

Slide 26 text

© 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

Slide 27

Slide 27 text

© 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

Slide 28

Slide 28 text

© 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

Slide 29

Slide 29 text

© 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

Slide 30

Slide 30 text

© 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

Slide 31

Slide 31 text

© 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

Slide 32

Slide 32 text

© 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

Slide 33

Slide 33 text

© 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

Slide 34

Slide 34 text

© 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

Slide 35

Slide 35 text

© 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

Slide 36

Slide 36 text

© 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

Slide 37

Slide 37 text

© 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

Slide 38

Slide 38 text

© 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

Slide 39

Slide 39 text

© 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

Slide 40

Slide 40 text

© 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

Slide 41

Slide 41 text

© 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

Slide 42

Slide 42 text

© 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

Slide 43

Slide 43 text

© 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

Slide 44

Slide 44 text

© Mountain Goat Software, LLC Mike Cohn contact info [email protected] www.mountaingoatsoftware.com    ?6S35 (303) 810-2190 (mobile) 44