Succeeding with Agile: A Guide to Transitioning

by Mike Cohn

Slide 1

Slide 1 text

Succeeding With Agile: A Guide to Transitioning Mike Cohn 1

Slide 2

Slide 2 text

Founding member and director of Agile Alliance and Scrum Alliance Founder of Mountain Goat Software Ran my first Scrum project in 1995 Typical programmer to manager etc. progression Agile coach and trainer Mike Cohn - background ® © 2003–2008 Mountain Goat Software® 2

Slide 3

Slide 3 text

® © 2003–2008 Mountain Goat Software® 1. Why transitioning to agile is hard 2. ADAPTing to agile development 3. A framework for transitioning 4. The role of leaders 5. Patterns of agile adoption Topics today... 3

Slide 4

Slide 4 text

Slide 5

Slide 5 text

® © 2003–2008 Mountain Goat Software® 1 Change is not top-down or bottom-up; it’s both G Two simplistic views of change: G Top down G Powerful leader shares a vision G Bottom-up G ?0,8>?,=?>,9/0A0=D:9007>0>00>?30-090P?>:1?30 new approach G But, transitioning to agile is neither top-down nor bottom-up G It’s everywhere, all together, all-at-once 5

Slide 6

Slide 6 text

® © 2003–2008 Mountain Goat Software® < It is tempting to codify things that work in a given context into best practices < '34>70,/>?:49Q0C4-70;=:.0>>0>† < Once we know what’s “best” we stop adapting < Or even thinking about what we’re doing < Once we’ve stopped inspecting and adapting we’re not agile, or won’t be for long 2 Best practices are tempting †Source: Anderson, P. “Seven Layers for Guiding the Evolving Enterprise” in The Biology of Business. 6

Slide 7

Slide 7 text

® © 2003–2008 Mountain Goat Software® 3 The transition process must be congruent with the development process Part of the move to agile is a move to self- organizing teams Moving to self- organization requires self-organization Write Feature 1 Write Feature 2 Self-organize 7

Slide 8

Slide 8 text

® © 2003–2008 Mountain Goat Software® 4 We cannot predict how an organization will respond to change < How we traditionally view our organizations: < Behavior is highly predictable < Once set in motion, will continue in motion < An organization change strategy can be mapped out: < :?34>P=>??309?3,??309>@.3,9/>: < And we’ll end up right where I predict 8

Slide 9

Slide 9 text

® © 2003–2008 Mountain Goat Software® “From a very early age, we are taught to break apart problems, to fragment the world. This apparently makes complex tasks and subjects more manageable, but we pay a hidden, enormous price. We can no longer see the consequences of our actions; we lose our intrinsic sense of connection to a larger whole. When we try to ‘see the big picture,’ we try to reassemble the fragments in our minds, to list and organize all the pieces. But, as physicist David Bohm says, the task is futile—similar to trying to reassemble ?30;40.0>:1,-=:60984==:=?:>00,?=@0=0Q0.?4:9 Thus, after awhile we give up trying to see the whole altogether.” Peter Senge, The Fifth Discipline 9

Slide 10

Slide 10 text

® © 2003–2008 Mountain Goat Software® “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 @'52!4)6%,9!.$4(%.054"!#+4/'%4(%2 7)4(/54!.93)'.)@#!.4,/33(%!335-04)/. 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 10

Slide 11

Slide 11 text

Slide 12

Slide 12 text

® © 2003–2008 Mountain Goat Software® We need a different mental model < The organization as a Complex Adaptive System (CAS) John Holland in Complexity: The Emerging Science at the Edge of Order and Chaos by Mitchell Waldrop < A dynamic network of many agents G acting in parallel G acting and reacting to what other agents are doing < Control is highly dispersed and decentralized < Overall system behavior is the result of a huge number of decisions made constantly by many agents 12

Slide 13

Slide 13 text

Slide 14

Slide 14 text

® © 2003–2008 Mountain Goat Software® Local goals and gaps < Local agents (individuals, project teams, discipline coworkers) identify local gaps based on their local goals Vision Current State Local actions Inspect Desired State Current State Local actions Inspect Desired State Current State Local actions Inspect Desired State 14

Slide 15

Slide 15 text

® © 2003–2008 Mountain Goat Software® Traditional model of change Complex, adaptive model of change Behavior is predictable and controllable Behavior is unpredictable and uncontrollable Direction is determined by a few leaders. Direction is determined through emergence and by many people Every effect has a cause Every effect is also a cause Relationships are directive Relationships are empowering 1P.409.D,9/=074,-474?D,=0 measures of value Responsiveness to the environment is the measure of value Decisions are based on facts and data. Decisions are based on patterns and tensions. Leaders are experts and authorities. Leaders are facilitators and supporters. Adapted from Olson and Eoyang, Facilitating Organization Change. 15

Slide 16

Slide 16 text

Slide 17

Slide 17 text

® © 2003–2008 Mountain Goat Software® that the current approach isn’t working to change to work in an agile manner early successes to build momentum and get others to follow the impact of agile throughout the organization so that it sticks Desire Ability Awareness Transfer Awareness Desire Ability Promote Promote Transfer A D A P T 17

Slide 18

Slide 18 text

® © 2003–2008 Mountain Goat Software® ...the developers are not meeting expectations for code quality. One of our challenges is that we’re still hacking our way through lots of legacy code that isn’t unit- testable or automated yet, but is mission critical and the person who has been working mostly on that area of code consistently leaves holes in the design and implementation of new pieces of that code. We also have the issue with at least one other developer as well. I’m the ScrumMaster and... 1.Is this a problem of Awareness, Desire or Ability? 2.Thinking about ADAPT, what might you try? 18

Slide 19

Slide 19 text

® © 2003–2008 Mountain Goat Software® Awareness G Communicate G Establish a vision G Narrow the focus G Metrics G Run a pilot Desire G A clear vision (again) G Share examples of success G Public praise for the right behavior G Align incentives G Turn the transition over to individuals G Build momentum Tools for building... 19

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

® © 2003–2008 Mountain Goat Software® < On projects we learn we cannot precisely anticipate: < our users’ requirements < how long it will take to develop a feature or entire system < which design will be best < the set of tasks necessary to develop a feature < So we devise alternative approaches: < Rather than ask for upfront specs, we deliver partial solutions, solicit feedback, and repeat < Rather than design the whole system, we design incrementally and adjust based on what we learn We need to do the same for the transition effort 24

Slide 25

Slide 25 text

® © 2003–2008 Mountain Goat Software® An agile process Cancel Gift wrap Return Iteration 2-4 weeks Return Iteration goal Iteration backlog Potentially shippable product increment Product backlog Gift wrap Coupons Cancel Daily ... ... ... Transition backlog ... Iteration monthly Weekly Altered organization An agile transition process 25

Slide 26

Slide 26 text

® © 2003–2008 Mountain Goat Software® Activities to support the goals Quarterly Monthly 3-4 goals Decide how pervasive to go with agile—development only or full company All Identify which issues agile can solve or help with. DF Transition backlog Weekly Discuss progress Remove impediments Meet weekly to execute, monthly to plan, quarterly to strategize Equivalent to daily standups Equivalent to iterations Equivalent to releases 26

Slide 27

Slide 27 text

Slide 28

Slide 28 text

® © 2003–2008 Mountain Goat Software® Who should not be on the guiding coalition < People with big egos < 4202:>P77?30=::870,A074??70>;,.01:=:?30=> < Don’t understand their own limitations < Snakes < Someone who poisons relationships among team members < Reluctant participants < Lack time or enthusiasm < But may have needed expertise or political clout 28

Slide 29

Slide 29 text

® © 2003–2008 Mountain Goat Software® Action teams G Usually more than one at any time G Each focused on a different goal G "=2,94E0/,=:@9/,.340A492>;0.4P.:=2,94E,?4:9,72:,7> G e.g., test automation or user experience design G Some teams in an organization will be organic G Individuals notice something needs to be achieved G Others will be formally-sponsored G Guiding coalition puts someone in charge of achieving a goal that hasn’t been picked up G Usually best only if an organic team doesn’t form 29

Slide 30

Slide 30 text

® © 2003–2008 Mountain Goat Software® Quarterly 3-4 goals 1 each Guiding coalition Action teams Monthly iterations G Iteration planning to identify tasks the action teams (and members of their delivery teams) can make progress on G Like the daily standup G A chance to synchronize work Weekly cycle 30

Slide 31

Slide 31 text

® © 2003–2008 Mountain Goat Software® Action team members < Try to form these teams organically < Possible with a point person to start the team < True product owner for the team is the guiding coalition < But this starting person acts as a combination day- to-day product owner and ScrumMaster < Initial membership < Start with 1-3 members who “get it” < Ask each of those members to pick 1-2 more 31

Slide 32

Slide 32 text

® © 2003–2008 Mountain Goat Software® Action team member considerations < Think about < Who has the power to make or break the transition to agile? < Who controls critical resources or expertise? < How will each be affected? < How will each react? 32

Slide 33

Slide 33 text

® © 2003–2008 Mountain Goat Software® Additional considerations < Who will gain or lose something by the transition to agile? < Are there blocs likely to mobilize against or in support of the transition? < :?0,8808-0=>3,A0>@1P.409?.=0/4-474?D?3,??30 teams’ opinions and results are taken seriously? < Can team members put their personal interests aside in favor of the organizational goal? 33

Slide 34

Slide 34 text

Slide 35

Slide 35 text

® © 2003–2008 Mountain Goat Software® Leading an agile transition < Action team and other formal leaders must lead the transition < but cannot do so in the usual ways < Self-organizing groups still require leadership < Lead through example, questions, and focus < “Nudge” the organization; Poke and prod; < See how the organization responds 35

Slide 36

Slide 36 text

® © 2003–2008 Mountain Goat Software® Pre-requisites of self-organization G A boundary within which self-organization occurs G Company, project, team, city, role, nationality Container G There must be differences among the agents acting in our system G Technical knowledge, domain knowledge, education, experience, power, gender Differences Transforming Exchanges G Agents in the system interact and exchange resources G Information, money, energy (vision) Glenda Eoyang: Conditions for Self-Organizing in Human Systems 36

Slide 37

Slide 37 text

® © 2003–2008 Mountain Goat Software® Using the CDE model < When stuck thinking about how to nudge the organization think of the: < Containers < formal teams, informal teams, clarify (or not) expectations < Differences < Dampen or amplify them within or between containers < Exchanges < Insert new exchanges, new people, new techniques or tools 37

Slide 38

Slide 38 text

® © 2003–2008 Mountain Goat Software® The team consists of four developers, two testers, a database engineer and you. The developers and testers are not working well together. Developers work in isolation until two days are left in the iteration. They then throw the code “over the wall” to the testers. ? Would you change a Container, Difference or Exchange to address this issue? 38

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

® © 2003–2008 Mountain Goat Software® GThe most pressing issues facing the project are ones that can be solved with technical practices. GYou aren’t starting a huge number of teams at once GTeam members have solid technical backgrounds GThere is a desperate need to improve Useful when Technical Practices First GVery rapid improvements are possible GThe transition can be quick Advantages GTechnical practices support each other in subtle ways GThere is likely to be strong resistance to some practices GOutside coaching will likely be needed Disadvantages 41

Slide 42

Slide 42 text

® © 2003–2008 Mountain Goat Software® GYou want to transition more than a handful of teams concurrently GYou are starting with a stalled project GLots of different technologies are in use by various teams Useful when Iterative First GIt’s easy to start GIt’s hard to argue against Advantages GThe team may not choose to add the technical practices Disadvantages 42

Slide 43

Slide 43 text

® © 2003–2008 Mountain Goat Software® GThere is reluctance to commit fully to agile GThe risks of failing an all-at- once transition outweigh the advantages GYou can afford the time it takes Useful when Start Small GCost of mistakes is minimized GYou can almost guarantee success Advantages GConclusions may not be compelling GIt takes a lot of time GAgile teams will need to work with non-agile teams Disadvantages 43

Slide 44

Slide 44 text

® © 2003–2008 Mountain Goat Software® GYou want to send a clear message GTime is critical GYour team isn’t too small or too big Useful when All In GIt’s over quickly GThere’s no organizational dissonance from using two processes at once GIt can reduce some resistance Advantages GIt’s risky GIt’s costly GIt will likely require a reorganization Disadvantages 44

Slide 45

Slide 45 text

® © 2003–2008 Mountain Goat Software® GYou want to experiment GYou don’t have any organizational support GYou expect strong resistance Useful when Stealth Mode GThere’s no additional pressure GNo one knows about it until you tell them GNo one can tell you not to do it Advantages GYou won’t have any organizational support GSkeptics will only hear about success, they won’t witness it Disadvantages 45

Slide 46

Slide 46 text

® © 2003–2008 Mountain Goat Software® G+:@,=0.:9P/09?49?30 approach and committed to achieving it GYou are likely to face stiff resistance and want to face it all at once Useful when Public Display of Agility (PDA) G Everyone knows you’re doing it so you’re more likely to stick with it G It establishes a vision to work toward G ,60>,P=8>?,?0809??3,?D:@ are committed to transitioning Advantages G Announcing something before you do it can make you look foolish G Resistors will come out of the woodwork Disadvantages 46