so you guys are we are we're Facebookliveing this this is kind of a newexperiment for us so that's what thecamera rig is back there so yeah yeah Idon't worry about it everybody just seethe back of your hair it's not a bigdealso what is that boss knows you're hereyeah for sure yeahokay it looks like the lunchroom isletting out so we'll give everybody afew minutes to join before we getstartedsomething kind of sick for the last weekso a big sign of success is going to beas if I can manage to talk for an hourwithout losing my voice so everybodykeep your fingers crossed have to turnup the volume on the microphone if it ifit gets too out of hand okay so it lookslike we got our little pop here andwe're good so we'll go ahead and getstartedso appreciate everybody come into thetalk so my talk is roughly called theexecutives I think sometimes I put stepby step guide to leading large scaleagile transformation and where this talkcomes from is that I run a companycalled leading agile we're based out ofAtlanta Georgia and what we do is thatwe go in and largely try to getexecutives to let us come in and helpthem transform their organization andyou know just really candidly fromselling this work and doing this workwe've learned a lot about whatexecutives care about in terms of how tomeasure and manage and track progress onan agile transformation okay and so whatthis talk really is about is if you'rean executive how do you hold yourorganization accountable for measurableprogress through the transformation andif you're not an executive then this isbasically a talk about what executivescare about and what you should betelling them and how you should beorganizing the transformation to makesure that you're giving them what theyneed so that they can continue to fundit okay so like I said my name is MikeCobb Meyer and I I run leading agilewe're about a sixty person boutique outof Atlanta Georgia I have a what I thinkis a kind of unique point of view aroundleading agile transformations because Inever I never operated in an agileenvironment in the small I was workingfor a company when I got introduced toagile about 10 or 12 years ago calledcheck free that was doing large-scalefinancial services kinds of thingsonline banking and bill payment thereFiserv now they've since been acquiredbythose guys a while ago now and when wewere doing agile it was multi team agilewe were figuring out program andportfolio management kinds of thingslong before any of that was really invogue to talk about we were taking DavidAnderson's early work on the applicationof Theory of Constraints creatingprogram and portfolio managementstructures using you know what was ineffect proto Kanban and and so theissues that we're dealing with at scaleand the issues that large companies faceas they're trying to figure out how toadopt agile it was kind of like right inour in our sweet spot a little bit andso what this talk is is going to beabout it's going to what I'm going tostart to do is I want to talk a littlebit about how to think and understandtransformation what is the in effect theunit of value of a transformation andthat's going to go into the executiveconversation in terms of what is it whatdoes it look like the track and plan aadult rants formation how to organizetransformation work and how to planmanage and track progress against thetransformation but there's going to besome introductory material in herebecause if you if we don't get on thesame page about what the unit of valueand a transformation is and how toapproach a transformation all the stuffaround the tracking and planning andsuch won't make a whole lot of senseokay so we're gonna try to build anargument in about 50 minutes to helpunderstand this okay so why do I thinkthis is important I think the game haslargely changed five or six years agoone of the main questions that I wouldget asked from people that that wouldwould you know they would be basicallylike how do I get my executive to beinterested in an agile transformationand now I find most executives arecoming to you guys and saying hey weneed to do an agile transformationthere's very few companies now that atleast aren't entertaining this in someform or fashion but what the executiveswant the executives need is they needsome sort of kind of planning andcontrol they want to know how to adoptagile or they want to adopt agile butthey don't know exactly how to go aboutthey need line-of-sight and how thetransformation is going to unfold andthey have to be able to continuouslyjustify the economics of it okayand that's something that sometimes aspractitioners that we don't fullyunderstand whether they're giving youguys training dollars whether they'reletting you hire internal staff whetheryou guys are going external and andhiring coaches there's an actualfiduciary responsibility to being ableto show measurable progress on thetransformation okayand that's largely what we want tofigure out how to package up and talkabout so again executives this is mytake is that executives that want to dothis what it's up to us to figure outhow to do is how to give them safety andground cover and be able to demonstratemeasurable progress along the way okaythat's our responsibility here and thisis the point that I want to kind of makebefore we get started in agile a lot oftimes we want to believe in emergence wewant to believe in things like I'm goingto empower the team and let the teamdecide okay and I value that as wellokay but to some degree I think we'regonna have to get over this notion oflike let's just put energy into it andlet it let it figure out I think we haveto get a little bit more comfortablewith figuring out how to structure andplan these transformations because evenif we don't believe it as individualsyou know the executives and theorganizations that we're going into theyhaven't really transformed yet theyhaven't totally bought in they want thebenefits of going agile but that mindsetisn't necessarily there right out of thegate and so what I'm asking maybe ifthat's kind of your belief is like wellwe just need to just let people just goand figure it out I'm suggesting thatyour executives probably want it to be alittle bit more structured a little bitmore plan driven and so again rightwe're going to talk about what I thinkby that what that means so why doexecutives care I'd love to do this in aQ&A format but we're gonna run out oftime if I if I try to engage you guysand back-and-forth too much most of theexecutives that we talk to that aretrying to do an agile transformationare trying to solve a business problemas a result of doing the transformationwe as practitioners a lot of times careabout the environment collaboration andcommunication and all those differentthings because we believe that they willlead the better business outcomes butwhen you're talking to an exec about atransformation the the kinds of thingsthat they typically care about arereally dollars and cents related can wesave money can we be more predictablecan we get things and market fastercan we start charging money for forproducts before they're fully done arewe building the right things are we ableto be innovative okay so the drivers thedrivers for an executive doing atransformation are absolutely dollarsand cents related okay now when you yousay well agile is going to solve thatfor me what we need to do is we need tohave a hypothesis around how agile isactually going to do that what are wegoing to do to the system of delivery sothat we get these better businessoutcomes okay so I did a version of thistalk at version one a couple weeks agoat an end Lana's scrum meeting and I waschallenging the room to say you know ifyou were given a pile of money and wewere king for a day in your company whatwould you go do to lead thetransformation knowing that in three tosix months you had to demonstrate insome measurable tangible way that itactually made the company's performancebetter okaythat's the level of bar that we'retalking about right so if you havebudget to hire people you have budget tohire consultants budget descend totraining what is your working hypothesisabout how that training is going toproduce a better measurable businessoutcome in three to six months okay youneed to have that really really thoughtthrough as a is a is a community we tendto think about agile is a cultural thingokay well I'm we use the word mindset alot and the ideas if Ican get everybody to kind of changetheir mind and to be more adaptive right- to be able to you know get this agilething that we're talking about the ideaI think that everybody believes is isthat the system of delivery will beginto emerge okay if we could just geteverybody to think and kind of feeldifferently then everything would workand one of the pieces that I'm gonna tryto do here is I'm going to try to showyou guys that while that would beawesome if we could get everybody on thesame page at the same time I thinkthat's a pretty dicey game I think it'sreally hard to change everybody'sthoughts and minds at the same time andthe other thing that I'm gonna make thecase for is that in most organizationsthat you go into there are legitimatesystemic and technological barriers tobeing able to do agile now granted if weall could flip our mindset then thosethings would be easier to fix but let'sget real some of the problems on ourcompanies are going to take three fiveten years to fix right certain aspectsof the technology stack are not going toflip overnight continuous integrationand deployment and DevOps is not goingto turn on overnight okay and so thisculture thing that we get kind ofobsessed with is it's it's important butin in the face of like real barriersthat take real dollars in real time tofix right if we're gonna lead with thatwe need to really understand what ourhypothesis is about how that culturaltransformation is going to make thatbusiness benefit difference in 36 monthsright chances are it's gonna be a longerplay okay the other thing that we seeI'm kind of trusting that my slides areflipping behind me and I'm trying not tolook at them right so if I get too faroff Devon like way that here somethingokay because I hate reading slides topeople so the next thing that you thatyou tend to see a lot is a verypractices driven kind of approach totransformation and I got a really funnyresponse I do some volunteer work downat the University of Florida and I wastalking to a team of computer sciencepeople and it's like you say you guyshave heard the scrum right they're likeoh yeah daily stand-up rightlike yeah okay cool yeah so grown-upsthink that too rightand and it's like the idea behind likeokay if I teach you how to do a dailystand-up right each other at a userstory I teach how to do a review andretrospective and all those things rightthose are the enabling practices of ofbeing agile right they don't necessarilydrive the mindset and they don'tnecessarily create the system they don'tthey don't improve the systemnecessarily right so one of the failuremodes that we see in people approachingagile transformation is if I treat itlike it was just another process rightoverlaid on top of the existingorganization that somehow the process orthe the exposing of impediments is goingto magically resolve all this stuff andwhat the net effect of that thinking isis that you see a lot of folks that arereally going through the motions ofscrum and trying to figure out why it'snot working okaybecause sure scrum is going to show usour impediments but if we're notcommitted to fixing them right becauseone of your impediments might be torefactor the fifty-year-old cobolplatform okay that's like not somethingthat the scrum master like runs off andgets taken care of by the deck sprintplanning meeting right so I mean there'slike real legit things going on that weneed to be very real about okay so whatI'm going to try to make the case forhere is that is that what we want to dois we want to look at the underlyingsystems of delivery the businessarchitecture of the organization thetechnology architecture of theorganization how teams are formed thenhow teams are structured what are theenabling entities within the enterpriseokay because I believe that if we canget that kind of stuff worked out firstor at least have a plan to figure outhow to work those kinds of things outthen we give a home base to great scrumpractices great XP practices great TDDand all those kinds of things we give ahome base to DevOps and continuousintegration and continuous deploymentand we create a context within theenterprise we're agile behaviors canbegin to emergeokay it's really difficult to ask peopleto think and behave differently whentheir environment is incongruent withthose behaviors okay so kind of thepoint of this little slide sequences isthat executives care about real businessvalue if we're gonna lead with cultureor we're gonna lead with practices wereally need to have a pretty clearhypothesis for how that culturaltraining and how those practices areactually going to create improvements inthe system okayhow are those impediments actually goingto get resolved okay we need to have aplan for it and my suggestion is is thatthere's a lot of brokenness going on inmost companies that we know before westart I don't need scrum to show me twoweeks at a time I know that we're notforming teams the right way I know thatwe can't build backlogs I know that ourDevOps infrastructure sucks I know thatwe can't do a build I know that releasemanagement takes a long time right so weneed to be really real about those beingthe kinds of things that we're gonna gofix okay so what I want to pivot intonow is I'm gonna pivot into a discussionabout what do I specifically mean bythis kind of systems first environmentfirst approach okay so for the lastcouple years I've been doing variants ofthis kind of a talk and one of the earlyvariants I talked about was this thisthing I call the three things and and Ibelieve that these three things are theabsolute most fundamental preconditionfor being able to do agile well even tothe point I would say if you're notdoing these three things there's noamount of scrum that's going to fix itfor you okay I would suggest thatthere's nothing in scrum that worksactually works if you're not doing thesethree things okay and these three thingsfor me our backlogs teams and workingtests is software so what does that meanso I'm going to get really specific bywhat I mean by backlogs teams andworking tested software so a backlog inagile we all like thematically know whatthat is and you're like you know okayMike you know I came to your talk andyou're telling me about a backlog butwhen you really go back right you lookat like Alistair Coburn's work and usecases and his user story stuff my coneswork right all the stuff like RomanPickler's done right all these guysright Bob Galen right he's here he'swritten a lot of stuff on that a backlogis a very specific thing right it's userstories they're written in a certainformat they're like a day or two orthree big we can do a handful of them ina sprint they have this canonical formthey have this way that we collaboratearound them most organizations that Iwalk into are not building backlog tothat level of specificity okay I like togo back to Bill wakes thing the investmodel right popularized by Mike ownindependent negotiable valuable estimatea little small and testable write thatformula is there for a reason mostbacklogs that you see with teams tryingto adopt scrum are not like that wecan't estimate them we can't interchangethem we can't pull one out put anotherin write that kind of a thing so one ofthe first preconditions that we need tolook for when we're thinking aboutbringing a part of the organization intoagile is we want a hypothesis for how isthat team whatever team you're going toget pulled together are they going to beable to get a backlog in the in the kindof the mechanism that we need to havethat backlog okay absolute preconditionsprint planning sprint reviewsretrospectives daily stand-ups rightevery single thing breaks down if thatteam does not have clarity in thebacklog right every single thing breaksdown the next thing that I want to pointout is the notion of teams we use theword team very very loosely right it'sjust the named group of people that arekind of assigned to something a team andagile is different right a team in agileis a group of six to 80 people that worktogether side-by-side they swarm aroundit they're t-shaped rate they'respecializing generalists like whateverlike metaphor you want to use okay butthe idea is an agile that a team has aeverything and everyone necessary todeliver the thing that is in the backlogokay most organizations have at leastone if not 50 dependencies they havepart-time people they have all kinds ofdifferent thingsthe problem with malformed teams is thatwhen you have teams that don't staytogether and can't get to a definitionof done they stop believing that theycan okayand they won't establish a stablevelocity because really the magicformula of agile right that kind ofseparates agile from total chaos is if Iknow the size of my backlog and I knowthe velocity of the team then I canstart to determine at least at a highlevel how much scope I'm going to getthrough how many Sprint's is going totake me to get done what does that thatis off-topic but I'll be happy to I willbe happy to talk with you about thatafterwards okay yeah I mean there'sgoing to be all kinds of differentmanagement dysfunction we're gonna cutalong the way right but what I'msuggesting is that we know how this issupposed to work right we know the sizeof the backlog we know the velocity ofthe team or at least we're supposed toso we can start to derive scope durationcost things like that okay and so if Idon't have a team that stays together Iwill never stabilize velocity and if Ican't stabilize the velocity I'm nevergoing to have any idea of what I'm goingto be done and you're absolutely foolingyourself if you think otherwise rightand so so it's just a problem right butthese kinds of teams are reallydifficult to form in most large legacyorganizations okay the third piece wehave to be able to again and make a surefollow my slides binding the third pieceis we have to make sure that we can getto a reasonable definition of done atthe end of the Sprint so we need to knowwhat done looks like we need to be ableto test we need to be able to validateI'm not saying we have to go as far inevery case to be able to deploy intoproduction but we have to be able to saylook this is done and we don't have togo back and rework it any more I cameout of project management the joke wasalways were 90% done we have80% left to do right and the reason whyis because writing the code is you knowno disrespect it's the easy part rightmaking sure that it's right and thatit's defect-free and that it didn'tintroduce a bunch of technical debtright that kind of stuff is hardalright so sometimes we have to slowdown the apparent throughput of lines ofcode and to get tested working donefeatures in most environments that isnon-trivial okay so what I'm suggestinghere is that these three things aredifficult but they are an absoluteprecondition to it okay so let's seewhich slides I put in here next okay sowhen we start to scale these ideas wetalked about the idea of governancestructure and metricsokay so governance is kind of a bad wordnatural sometimes but it's basicallyjust the way that we make economictrade-offs and the face of scarceresources so the product owner in a pureplay scrum team is a governancemechanism to the team they get to decidethey get to prioritize they get to setbusiness value right they get to do allthose things that's just governance okayso there's a lot of different ways it'sscale to start thinking about lean agilegovernance right safe introduces somelean agile governance techniqueslarge-scale scrum introduces somegovernance techniques right lots ofdifferent ways to do governance notnecessarily in the way we're doing ittoday but there's healthy ways of doinglean agile governance okay structurewhat does it look like to createcross-functional teams are networks ofcross-functional teams that worktogether across the entire stack okaywhat has done look like when it's amulti team deployment in eight or nineor ten or a hundred teams have to cometogether what are the metrics they'regonna use to control that how we'regonna throttle work across it right howare we going to make trade-off decisionsand all those kinds of things okay soteams backlogs working testing softwareat the at the lowest level becomestructure governance and metrics at thehighest level okay and understandingthat if we can't get these kinds ofthings installed at some point thenthere's not a whole lot that's going onin our transformation that is of muchother valueokay now if you're who I wasn't yeahthere we gookay so what gets in the way one one ofmy favorite meetings I did it was inAtlanta and there was a group of CIOsthat I was like doing like a Lunch andLearn kind of with and one of the CIA'sraises his hand he goes but yeah likethat that stuff's really hard like wellhow do I go about doing and I put thisnext slide up and I was talking aboutall the different things that get in theway and he said but that's what myenvironment is I've got technical debtI've got defects I've got a matrixorganization I've got this and that theother I got dependencies all over theplace okay and I said yep it's your jobto fix them okay and part of thechallenge that I think that we're notbeing incredibly transparent about as anagile community is the fact that we knowthe the brokenness right we know thefailure modes in the organization okayand what we're doing often is we'resaying let's train people on agile andget them doing scrum and then all of theimpediments will show themselves andit'll be up to us to fix them but it'skind of like what I said earlier whenyour impediment is a 50 year oldmainframe platform that's actuallyrunning server many billions of revenueit's really tough right it's reallytough but to get to the point wherewe're really doing agile where we'rereally doing an agile transformationwhere we can get the culture change andwe can get the behavior change we canget all the different kinds of changesthis is the kind of stuff that has to befixed okayso here's kind of like my theory oftransformation adopting agile is aboutforming teams building backlogs andregularly producing increments ofworking testing software adopting agileit scales about the finding structureestablishing governance in creatingmetrics and tooling strategy thatsupports agility anything that gets inthe way is an impediment totransformation the stuff that gets inthe way of doing that is actually thework of the transformation okay trainingpeople is like is like it's a necessaryactivity but it's an activitythe outcome is a better performingorganization in order to get a betterperforming organization you actuallyhave to improve in the organizationwhat's broken that work is the work of atransformation so make sense I'm gonnapause for a second and rest my vocalcords any questions I can take aquestionno guys drinking from the fire hose justcrazy talk I thought I could just go toscrum school and everything would begreat yesyeah yeah so so what I suspect is thatwhen people come to me and they go wellhey you know I did a transformation thisway or I did a transformation that wayI think most successful transformationswere predicated on this kind of apattern if whether that was explicit ornot you know maybe they didn't reallyrealize what was going on but if yousuccessfully transform something thenyou probably implemented these patternsone of the patterns we see that's reallyinteresting quite a bit is an executivethat goes to from one organization tothe other and in the previousorganization they were really successfuljust introducing agile practices and andyou know cultural stuff and everythingchances are if that worked it wasbecause they had a really natural teambased organization and there was a lotof decoupling between them and thereweren't a ton of dependencies andeverything in the practices and theculture and the mindset it became anenable or a force multiplier on top ofwhatever they had which I would totallyagree with right but then they do thesame thing in the next organization andthey've got that 50-year legacy platformthey got all this technical debt defectsdependencies misalignment all that kindof stuff in the same technique doesn'twork because the underlying patternsthat enabled it over here weren'tavailable and they didn't have to fix itover here now they've got to fix it intheir new organization it's make senseyeah yeah yeah so I'm gonna talk alittle bit about how we recommend astructure and plan these things so goodtiming so what you know this this kindof notion of structure first or systemsfirst is predicated on the idea that weare going to look for patternsorganizationally for how we want to formand ultimately encapsulate teams okayand by encapsulate I mean allow them tooperate with autonomy with minimaldependencies between them okay so mostorganizations there's a kind of a hiddenunderlying pattern that you can discoverand it generally means that we've gotsome sort of services teams thinkmicro-services right that are that areproviding core capabilities across theplatformyou've got feature teams that areconsuming those services you might dosome kind of program coordination teamyou might do some sort of systems teamif you're doing safe you might end updoing some sort of portfolio teaming butone of the things that we really believein is this idea that you can begin tothink about how to form teams at scalewe know that we want encapsulation weknow that we want to create dedicatedcross-functional teams we might not didit right out of the gate but we want tohave a pretty good idea of what we'regoing for right out of the gate so mostorganizations in some form or fashiontend to look something like thisthere's a set of shared services there'sa set of services that get coordinatedby a program team they get coordinatedby some sort of subordinate to some sortof portfolio team okay almost alwayswhen we're in the presence ofdependencies do we need coordinatingentities so here's kind of a rule ofthumb right we want things to be veryloosely coupled right we wantencapsulation we want no dependenciesbut here's the thing where sometimes wego wrongcommunity we want to pretenddependencies don't exist because theyshouldn't exist when they actually doexist okay and the challenge is is thatmost large complicated organizations arenot going to self organize dependenciesokay and so when you have dependencieswhen you don't have the right level ofencapsulation you have to have moreorchestration as you begin toencapsulate break dependencies you candeprecated some of the orchestration sothe challenges is in the presence ofdependencies dependencies have to bemanaged somehow okay we can assume thatthey'll be self-managed I don't see thatthat generally works in most cases andthen we have to figure out how muchcoordination then we're going to needokay but most organizations at some formof scale start to look like a pyramid ofteams okay you guys will recognize thisthis is you know very much the kind ofpattern that Saif has deployed typicallyscrum is a great enabling set ofprocesses to govern the performance ofexecution oriented teams right when youstart putting in orchestration layersand you start putting in coordination wetypically will tend to run those in moreof a Kanban based system okay when we'retalking about a portfolio a portfolio ofgovernance in portfolio was basicallyjust a Kanban system of projectshopefully small projects small batchsize right but it's basically a Kanbansystem of projects okay so you start tothink about what does the in-statevision of an organization that lookthat's going to agile look like whenthey've got dependencies right whenthere's stuff to manage and it lookssomething like this then we startthinking about what metrics that we wantto use right so this is a handful oflike starter metrics that you can use atdifferent levels right so a big part ofwhat we're trying to do is we're tryingto think about what is the work of thetransformation the work of thetransformation is forming teams gettingteams backlogs getting teams the abilityto produce working tested software andthen ultimately starting tosystematically break the dependencies inthe systemso that we can improve the localautonomy and start to deprecate some ofthe control and actually let these teamsbegin to operate in a more emergent wayso now we're going to start playing someconcepts together the work of an agiletransformation right the unit of valueis a transformed organization okay nowwhat we have to figure out how to do ishow to take that transformedorganization and break it into smallerpieces okay so we use some words in ourpractice we've talked about expeditionsand base camps but basically what we'rereally saying is that the process ofgoing through a transformation isincremental and iterative okay do youguys remember Jeff Patton's Mona Lisapicture I should probably inserted inhere cuz I keep talking about it at thisstage of this talk but Jeff Patton'sMona Lisa picture describes it's reallykind of cool right it talks aboutincremental as like doing the quadrantsright imagine the Mona Lisa and forright so an incremental painting wouldbe doodle upper leftupper right lower left lower right rightthat's painting it in incrementspainting it in iterations is like doinga sketch and then doing a watercolor andthen putting oil on it and thenfine-tuning the oil okay so you canthink about transforming an organizationin the same fundamental way you canthink about breaking it into chunksincrements and you can think aboutiterating it and helping it get betterover time okay sometimes we tend tothink about well I just need to gostraight to where I want to be realizingthat there's all these barriers rightthat are going to get in the way okay soif you think about the backlog of atransformation the epic feature and userstory decomposition is a subset of theorganization basically moving throughprogressive levels of maturity rightforming teams building backlogsproducing working tests and softwareright breaking impediments over timeokay the I need to get somebody trainedI need to get a scrum master hired Ineed to run a workshop those areactivities those are not the value thatyou provide okay so when we're goingback to our executives what we want tobe able to say is I took slice oforganization one and I got it to thislevel of performance and then I madesome improvements and I got it to thislevel of performance and I made someimprovements and I got it to this levelof performance you guys with me on thatokay it's not I got them trained it'sthat they are performing better okay andthe hard part right what makes thisdifficult is that the impediments in theorganization initially prevent it fromgetting better it makes it difficult forit to get better okay so what you've gotto do is you've got to build the caseyou're like this is how good I can getit while it's got impediments then I getthe impediments broken and I can saythis is how much better it can be thisis how much better it can be after thatokay so incremental transformation isbasically taking like an entire slice ofthe organization and implementing it inagile which would mean forming theteam's putting together theorchestration layers the program in theportfolio layer getting whatever toolingyou're using if whether it be JIRA orwhiteboards or sticky notes or versionone or rally or whatever right gettingyour tooling installed getting metricsbaselines going getting the systemdelivering and performing okay figuringout what slice you want to start with inimplementing the entire stack ofdelivery because what the executivesgoing to care about is how is this partof the organization performing better asa result of you having been here to doit right so that's what I mean byincremental it's about figuring outwhich slice of the organization andgetting the whole value stream if youwant to call it that deliveringokay but we recognize again right sothen he'd pick up the next ones right sowhat we would recognize then is that thetransformation process because we haveimpediments because we don't haveperfectly form teams because we have allthese things in the way also has to beincremental okay we can't just gotrained everybody in scrum everybody'sdoing daily stand-up meetings we're doneright we have to have the systematicremoving of the dependencies and so wecall these things base camps OOP I'mlost Devon what happened man maybe Ilost focus hold on a second oh yeahthing okay coolso what the iterative side oftransformation is is how are we going tocommunicate progressive maturity andperformance of the slices that we'reinteracting with and so what we roughlyoutline is kind of like a five-step apotentially a five-step kind oftransformation sequence the first thingthat you can do generally is help theorganization get stable and predictableokay help it get to the point where it'sable to make and meet commitments it'snot really are we building the rightthing are we operating with agility orwe figure you know it's like gotdependencies I've got all this legacystuff I've got all this stuff so we'regonna do is we're gonna form teams we'regonna get them really clear backlogswe're gonna get them stabilizingvelocity we're gonna get them to wherethey can do like a rolling three-monthplan they should be able to operateagainst some sort of roadmap probablynot super super agile at this pointbecause but dependencies make agile hardright but what we want to do is we wantto stabilize the system in place then wewant to start to think about how do weget things in the market fastersometimes that next phase is aboutreducing the size of the projects in theportfolio getting smaller things itcould be about taking the waste out ofthe release release management processit could be about introducing somebetter testing practices braking testingand integrating it in with the deliverystream a little bit more effectléa right but the idea is is stabilizeand then start to improve right so thenwe start to reduce batch size then atthat stage you're gonna hit a wallbecause more than likely you can't goany further without some technologyrefactoring you've got to ultimatelyreally start to encapsulate thetechnology components move from you knowto a micro-services architecture orsomething like that start to go to thecloud start to put DevOps continuousintegration and deployment kinds ofthings in okay but that's not usuallystep one because in step one you don'treally know what your architecture lookslike you don't know what you want it tobe you don't know how you're gonnaorganize and plan around it so stabilizea system in place then reduce your batchsize then start to really refactor andwhat's cool is that once you get some ofthese components things refactoringyou've got actually dedicated teamsaround encapsulated technology then youcan start to say okay I'm going to giveyou a bucket of money go solve thisreally cool problem because now you'renot necessarily dependent upon anythingelse in the organization you've actuallylegitimately broken the dependencies andwhat that starts to look like it's scaleis let's say for example you have aplatform strategy and a and ago-to-market customer-facing strategyone of the things that we do isoftentimes we let the front-end driverequirements into the back-end servicesyou know not every company operates thatway some say this is how we're gonnaevolve our platform the sales guys canonly go out and sell the stuff it'sactually going to be in the platform orin the platform's roadmap right theycan't inject dependencies down into thebackend that's kind of like a step fourlevel of maturity but you have to havedecoupled teams in order before you canreally start to think about doing thatright and then Step five is more like aradical like innovation kind of thinglike okay here's a bucket of money gosolve this problem kind of a deal okayso when we think about incrementaltransformation right we're talking abouttaking the organization and breaking itinto slices when we think aboutiterative transformation we're thinkingabout what does the continuousimprovement plan look like to get theorganization from where it is today towhere we need it to be in the futureokay how am i doing on timethey come almost oh my where am Isupposed to wrap up about 140 130 130okay cool let me scoot you over hereright so then these things work togetherright so now what you can start to thinkabout is your moving your transformationby taking slices and moving them throughthis progression so what you'll end upwith is you'll end up with slices thatare further ahead than other slices inthe organization right and it becomes areally cool way of being able tocommunicate progress so when I put thistalk together it was for agile 2016 lastyear and I was trying to think like likewhat would it be like if I were going totry to articulate steps to doing atransformation right what would itactually look like and this is a lot ofwhat we're doing kind of in our internalpractice to communicate with our clientsabout how we're making progress you knowone of my big impetus is just to totalcandor is that as an external consultingagency when we go in and we sell atransformation we are accountable to ourexecutives in this way right we have tobe able to communicate progress or wedon't get hired right is what it boilsdown to and so you guys as internalcoaches and consultants I think can takethe same kind of ideas recognize that toget the funding that you need to evensustain your internal practices that youguys have to be fiduciary responsible toyour executives as well okay so kind ofwhat the the high level process that weput together is is you know first of allbuild a leadership coalition rightengage the executives make sure thatthey're on board and that theyunderstand what it is that you'regetting ready to do a big part of thatis set their expectations let them knowhow you're going to to advocate for thearchitecture how you're going to breakthings up into slices the kinds ofimpediments that they're gonna see thekinds of investments that they're goingto make get their buy-in get you knowget a form together for you guys to beable to hold yourselves accountable nextstep define an in-state visionI don't think and this is kind of thefirst point that I made is that it'sresponsible to say that we're just goingto train people and hope for the bestright that kind of train and praisestrategy right it's not really effectiveI think it's reasonable I think we knowthe patterns of how to form teams atscale okay so when we talk about anin-state vision with relatively littleeffort right we understand the patternswe understand where we need to formteams where we need to createorchestration layers what we're gonna doand say four versus what we're gonna doin something else where are thedependencies that we have to break rightso an in-state vision basically paints apicture of where it is that we're goingand then once you have the picture rightthen we can lay out a road map what arethe different chunks what are thedifferent expeditions we call them rightthe increments and then how do we intendto progress them through differentlevels of maturity okay and you can takean entire organization seven eighthundred people break it into a hundredand fifty person slices understand whatteams are going to be formed how they'regonna form what we're going to do tothem and then lay that out kind of overtime okay call that building a road mapnext step this is where it starts to getreally like agile if we reallyunderstand the nature of the backlogright so you think about a release planusually about 90 days right programincrement if you want to use safe okayyou can create a rolling 90-day plan ofall of the different elements in theorganization that you're going to impactyou know over the next 90 days we'regoing to work with these eight teams andwe're going to create these two programteams we're going to operate within thisportfolio we're gonna install this setof tools and get these metrics baselineright and at some point we have to showup and we have to do the work right butwe know that that's gonna be verydynamic right the work the 90-day planthe release plan is like when we knowthe most about what it is we're going todo right so think of it as like arelease backlog okay what are the teamswe're going to form what are theentities we're going to interact withwhat's the level of performanceto get to write that kind of a thing soyou've got the in-state vision you'vegot the transformation roadmap now weput together a detailed 90-day planthat's kind of like our release plan forbuilding a product okay but it'ssubordinate up to that roadmap then westart to get into the habit of doinglike a 30-day sprint kind of a thing oryou could do this this could be atwo-week checkpoint our 30-daycheckpoint where now we're basicallywe're engaging our team members we'redoing the work of the transformation weare where basically we're running theworkshops we're doing the training we'reforming the teams right we're gettingthem performant we're coaching with themwere working with them in the team roomright all that kind of stuff okay buthere's the interesting thing right whenwe're doing this now we're doing thework right we're doing the same workthat we were doing before but now we'redoing it in the context of a 90 day planwe're doing in the context of a road mapwe're doing it in the context of anin-state vision now we can go to ourexecutives and we can say okay we spentthis much of the funding over the lastquarter this was the organization weimpacted this organization went fromhaving no predictability to this greatmeasureable predictability and we canpull this all out of the tools we canshow like what the next steps going tobe what the next step after that's goingto be okay we don't know all of theactivities we're going to do but we canstart to get good at sequencing theoutcomes that we're trying to achieveright and getting really real about thenature of the work that's necessary togo into that connect activity andoutcomes I just kind of talked aboutthat connect outcomes to businessobjectives one of the conversations wehave internally quite a bit is is thatgoals and objectives and outcomes arekind of recursive you know we know thatwe want to make more money as a companyright but to do that we have to breakdown some of these barriers in order tobreak down some of these barriers weneed to break the organization intosmall chunks once we break theorganization into small chunks then wehave to get it to certain levels ofperformance to get it to certain levelsof performance we have to achieve theseintermediate outcomes qi of these andrated outcomes we have to basically dothis work right but what we wanted is wewant to roll all that up right andconnect the dots for the execubecause the Holy Grail right of internalconsultancies and external consultanciesis to be able to say these are thedollars that I spent and here's themeasurable outcomes that we achieved andto be able to link those two togetherright that's how you self fund an agiletransformation okay so incorporatefeedback manage communication createsafety for everyone involved that's whywe doing these names and boxes andgetting some of this plan it's like itdoesn't have to be a figure it out as wego and when people understand where theyfit in the overall process that createsa lot of safety for people theyunderstand where they're at in thesequence they understand what their jobsgoing to look like in the front they canmentally prepare right they can they canyou know lay it out so I guess reallywhat this talk is about right it'sprobably a couple things it's like it'slike understand the nature oftransformation work the unit oftransformation is an organization thatis getting better right then we canstart to talk about what does it looklike to do iterative and incrementaltransformation at scale then once we'vegot that right and we understand thatthat is our fundamental framework teamsbacklogs working Casso software breakdependencies do this in the city of anincremental way then we can start kindof laying out a road map and theserelease plans and these 90-day plans towhere we can be held accountable to makesure that the executives understand thedollars that are being spent to theactual outcomes achieved okay but yougot to like think about the workfundamentally different that's why thatfirst part of the talk was so importantonce you anchor on that and youunderstand how how it's supposed tofunction and what the work of atransformation is then it becomes reallyfun right it becomes like an agileproject to actually do it you know andyou know a long time I'd always heardpeople say use agile to implement agilebut what they really meant was gettogether every two weeks and plan and doa daily stand-up meeting right but butthe art is in what's in the backlogright and if we get the right stuff inthe backlog and then we enable it withagile practices right then we've got ashot it actuallyyou know I think effective with ourexecutive teams I think we got a coupleminutes anybody I don't ask a questionyes sir yeah yes so anytime you makesomething like come across as sequentialright I mean it's like all of this stuffis like you've got to get to an in-stateas fast as you can you've got to get tothis right you got to get names andboxes inevitably people start to talkwhenever consultants show up right it'sall red staplers and stuff like thatright people are concerned right so yeahright so you want to get to that rightso you try to do lunch and learns andyou try to educate and you there's a lotof things that you can do on the sidewhile you're building out this kind ofplan you have a question you look likeyour raise your hand nobody else goodokay guys thanks for coming appreciateit
This talk explores a safe, pragmatic, and repeatable formula for leading Agile Transformation in large organizations. The Holy Grail for an executive is to tie dollars spent and activities performed, to internal improvement metrics and ultimately improved business performance. We’ll start by discussing the elements of an agile transformation business case and how to identify a meaningful value proposition for transformation. Next we’ll consider how to assess the organization and build an agile transformation strategy and roadmap that encourages an iterative and incremental approach to change. Finally we’ll explore the metrics and controls that help you know if you’re on the right track.
Throughout the presentation, we’ll explore the change management and engagement techniques necessary to make sure you are building meaningful organizational support as you lead the enterprise. We’ll discuss how to build and execute a change management strategy to keep everyone safe and informed throughout the transformation. We’ll show how to sustain and improve the changes over time, ultimately creating an organizational ecosystem where business agility is part of the fundamental DNA of the company. The goal of this talk is to take the magic out of agile transformation and show you how to systematically and planfully introduce agile into your organization.