How to Lead Agile Transformation: Safe, pragmatic organization wide agile adoption

so you guys are we are we're Facebook liveing this this is kind of a new experiment for us so that's what the camera rig is back there so yeah yeah I don't worry about it everybody just see the back of your hair it's not a big deal so what is that boss knows you're here yeah for sure yeah okay it looks like the lunchroom is letting out so we'll give everybody a few minutes to join before we get started something kind of sick for the last week so a big sign of success is going to be as if I can manage to talk for an hour without losing my voice so everybody keep your fingers crossed have to turn up the volume on the microphone if it if it gets too out of hand okay so it looks like we got our little pop here and we're good so we'll go ahead and get started so appreciate everybody come into the talk so my talk is roughly called the executives I think sometimes I put step by step guide to leading large scale agile transformation and where this talk comes from is that I run a company called leading agile we're based out of Atlanta Georgia and what we do is that we go in and largely try to get executives to let us come in and help them transform their organization and you know just really candidly from selling this work and doing this work we've learned a lot about what executives care about in terms of how to measure and manage and track progress on an agile transformation okay and so what this talk really is about is if you're an executive how do you hold your organization accountable for measurable progress through the transformation and if you're not an executive then this is basically a talk about what executives care about and what you should be telling them and how you should be organizing the transformation to make sure that you're giving them what they need so that they can continue to fund it okay so like I said my name is Mike Cobb Meyer and I I run leading agile we're about a sixty person boutique out of Atlanta Georgia I have a what I think is a kind of unique point of view around leading agile transformations because I never I never operated in an agile environment in the small I was working for a company when I got introduced to agile about 10 or 12 years ago called check free that was doing large-scale financial services kinds of things online banking and bill payment there Fiserv now they've since been acquired by those guys a while ago now and when we were doing agile it was multi team agile we were figuring out program and portfolio management kinds of things long before any of that was really in vogue to talk about we were taking David Anderson's early work on the application of Theory of Constraints creating program and portfolio management structures using you know what was in effect proto Kanban and and so the issues that we're dealing with at scale and the issues that large companies face as they're trying to figure out how to adopt agile it was kind of like right in our in our sweet spot a little bit and so what this talk is is going to be about it's going to what I'm going to start to do is I want to talk a little bit about how to think and understand transformation what is the in effect the unit of value of a transformation and that's going to go into the executive conversation in terms of what is it what does it look like the track and plan a adult rants formation how to organize transformation work and how to plan manage and track progress against the transformation but there's going to be some introductory material in here because if you if we don't get on the same page about what the unit of value and a transformation is and how to approach a transformation all the stuff around the tracking and planning and such won't make a whole lot of sense okay so we're gonna try to build an argument in about 50 minutes to help understand this okay so why do I think this is important I think the game has largely changed five or six years ago one of the main questions that I would get asked from people that that would would you know they would be basically like how do I get my executive to be interested in an agile transformation and now I find most executives are coming to you guys and saying hey we need to do an agile transformation there's very few companies now that at least aren't entertaining this in some form or fashion but what the executives want the executives need is they need some sort of kind of planning and control they want to know how to adopt agile or they want to adopt agile but they don't know exactly how to go about they need line-of-sight and how the transformation is going to unfold and they have to be able to continuously justify the economics of it okay and that's something that sometimes as practitioners that we don't fully understand whether they're giving you guys training dollars whether they're letting you hire internal staff whether you guys are going external and and hiring coaches there's an actual fiduciary responsibility to being able to show measurable progress on the transformation okay and that's largely what we want to figure out how to package up and talk about so again executives this is my take is that executives that want to do this what it's up to us to figure out how to do is how to give them safety and ground cover and be able to demonstrate measurable progress along the way okay that's our responsibility here and this is the point that I want to kind of make before we get started in agile a lot of times we want to believe in emergence we want to believe in things like I'm going to empower the team and let the team decide okay and I value that as well okay but to some degree I think we're gonna have to get over this notion of like let's just put energy into it and let it let it figure out I think we have to get a little bit more comfortable with figuring out how to structure and plan these transformations because even if we don't believe it as individuals you know the executives and the organizations that we're going into they haven't really transformed yet they haven't totally bought in they want the benefits of going agile but that mindset isn't necessarily there right out of the gate and so what I'm asking maybe if that's kind of your belief is like well we just need to just let people just go and figure it out I'm suggesting that your executives probably want it to be a little bit more structured a little bit more plan driven and so again right we're going to talk about what I think by that what that means so why do executives care I'd love to do this in a Q&A format but we're gonna run out of time if I if I try to engage you guys and back-and-forth too much most of the executives that we talk to that are trying to do an agile transformation are trying to solve a business problem as a result of doing the transformation we as practitioners a lot of times care about the environment collaboration and communication and all those different things because we believe that they will lead the better business outcomes but when you're talking to an exec about a transformation the the kinds of things that they typically care about are really dollars and cents related can we save money can we be more predictable can we get things and market faster can we start charging money for for products before they're fully done are we building the right things are we able to be innovative okay so the drivers the drivers for an executive doing a transformation are absolutely dollars and cents related okay now when you you say well agile is going to solve that for me what we need to do is we need to have a hypothesis around how agile is actually going to do that what are we going to do to the system of delivery so that we get these better business outcomes okay so I did a version of this talk at version one a couple weeks ago at an end Lana's scrum meeting and I was challenging the room to say you know if you were given a pile of money and we were king for a day in your company what would you go do to lead the transformation knowing that in three to six months you had to demonstrate in some measurable tangible way that it actually made the company's performance better okay that's the level of bar that we're talking about right so if you have budget to hire people you have budget to hire consultants budget descend to training what is your working hypothesis about how that training is going to produce a better measurable business outcome in three to six months okay you need to have that really really thought through as a is a is a community we tend to think about agile is a cultural thing okay well I'm we use the word mindset a lot and the ideas if I can get everybody to kind of change their mind and to be more adaptive right - to be able to you know get this agile thing that we're talking about the idea I think that everybody believes is is that the system of delivery will begin to emerge okay if we could just get everybody to think and kind of feel differently then everything would work and one of the pieces that I'm gonna try to do here is I'm going to try to show you guys that while that would be awesome if we could get everybody on the same page at the same time I think that's a pretty dicey game I think it's really hard to change everybody's thoughts and minds at the same time and the other thing that I'm gonna make the case for is that in most organizations that you go into there are legitimate systemic and technological barriers to being able to do agile now granted if we all could flip our mindset then those things would be easier to fix but let's get real some of the problems on our companies are going to take three five ten years to fix right certain aspects of the technology stack are not going to flip overnight continuous integration and deployment and DevOps is not going to turn on overnight okay and so this culture thing that we get kind of obsessed with is it's it's important but in in the face of like real barriers that take real dollars in real time to fix right if we're gonna lead with that we need to really understand what our hypothesis is about how that cultural transformation is going to make that business benefit difference in 36 months right chances are it's gonna be a longer play okay the other thing that we see I'm kind of trusting that my slides are flipping behind me and I'm trying not to look at them right so if I get too far off Devon like way that here something okay because I hate reading slides to people so the next thing that you that you tend to see a lot is a very practices driven kind of approach to transformation and I got a really funny response I do some volunteer work down at the University of Florida and I was talking to a team of computer science people and it's like you say you guys have heard the scrum right they're like oh yeah daily stand-up right like yeah okay cool yeah so grown-ups think that too right and and it's like the idea behind like okay if I teach you how to do a daily stand-up right each other at a user story I teach how to do a review and retrospective and all those things right those are the enabling practices of of being agile right they don't necessarily drive the mindset and they don't necessarily create the system they don't they don't improve the system necessarily right so one of the failure modes that we see in people approaching agile transformation is if I treat it like it was just another process right overlaid on top of the existing organization that somehow the process or the the exposing of impediments is going to magically resolve all this stuff and what the net effect of that thinking is is that you see a lot of folks that are really going through the motions of scrum and trying to figure out why it's not working okay because sure scrum is going to show us our impediments but if we're not committed to fixing them right because one of your impediments might be to refactor the fifty-year-old cobol platform okay that's like not something that the scrum master like runs off and gets taken care of by the deck sprint planning meeting right so I mean there's like real legit things going on that we need to be very real about okay so what I'm going to try to make the case for here is that is that what we want to do is we want to look at the underlying systems of delivery the business architecture of the organization the technology architecture of the organization how teams are formed then how teams are structured what are the enabling entities within the enterprise okay because I believe that if we can get that kind of stuff worked out first or at least have a plan to figure out how to work those kinds of things out then we give a home base to great scrum practices great XP practices great TDD and all those kinds of things we give a home base to DevOps and continuous integration and continuous deployment and we create a context within the enterprise we're agile behaviors can begin to emerge okay it's really difficult to ask people to think and behave differently when their environment is incongruent with those behaviors okay so kind of the point of this little slide sequences is that executives care about real business value if we're gonna lead with culture or we're gonna lead with practices we really need to have a pretty clear hypothesis for how that cultural training and how those practices are actually going to create improvements in the system okay how are those impediments actually going to get resolved okay we need to have a plan for it and my suggestion is is that there's a lot of brokenness going on in most companies that we know before we start I don't need scrum to show me two weeks at a time I know that we're not forming teams the right way I know that we can't build backlogs I know that our DevOps infrastructure sucks I know that we can't do a build I know that release management takes a long time right so we need to be really real about those being the kinds of things that we're gonna go fix okay so what I want to pivot into now is I'm gonna pivot into a discussion about what do I specifically mean by this kind of systems first environment first approach okay so for the last couple years I've been doing variants of this kind of a talk and one of the early variants I talked about was this this thing I call the three things and and I believe that these three things are the absolute most fundamental precondition for being able to do agile well even to the point I would say if you're not doing these three things there's no amount of scrum that's going to fix it for you okay I would suggest that there's nothing in scrum that works actually works if you're not doing these three things okay and these three things for me our backlogs teams and working tests is software so what does that mean so I'm going to get really specific by what I mean by backlogs teams and working tested software so a backlog in agile we all like thematically know what that is and you're like you know okay Mike you know I came to your talk and you're telling me about a backlog but when you really go back right you look at like Alistair Coburn's work and use cases and his user story stuff my cones work right all the stuff like Roman Pickler's done right all these guys right Bob Galen right he's here he's written a lot of stuff on that a backlog is a very specific thing right it's user stories they're written in a certain format they're like a day or two or three big we can do a handful of them in a sprint they have this canonical form they have this way that we collaborate around them most organizations that I walk into are not building backlog to that level of specificity okay I like to go back to Bill wakes thing the invest model right popularized by Mike own independent negotiable valuable estimate a little small and testable write that formula is there for a reason most backlogs that you see with teams trying to adopt scrum are not like that we can't estimate them we can't interchange them we can't pull one out put another in write that kind of a thing so one of the first preconditions that we need to look for when we're thinking about bringing a part of the organization into agile is we want a hypothesis for how is that team whatever team you're going to get pulled together are they going to be able to get a backlog in the in the kind of the mechanism that we need to have that backlog okay absolute precondition sprint planning sprint reviews retrospectives daily stand-ups right every single thing breaks down if that team does not have clarity in the backlog right every single thing breaks down the next thing that I want to point out is the notion of teams we use the word team very very loosely right it's just the named group of people that are kind of assigned to something a team and agile is different right a team in agile is a group of six to 80 people that work together side-by-side they swarm around it they're t-shaped rate they're specializing generalists like whatever like metaphor you want to use okay but the idea is an agile that a team has a everything and everyone necessary to deliver the thing that is in the backlog okay most organizations have at least one if not 50 dependencies they have part-time people they have all kinds of different things the problem with malformed teams is that when you have teams that don't stay together and can't get to a definition of done they stop believing that they can okay and they won't establish a stable velocity because really the magic formula of agile right that kind of separates agile from total chaos is if I know the size of my backlog and I know the velocity of the team then I can start to determine at least at a high level how much scope I'm going to get through how many Sprint's is going to take me to get done what does that that is off-topic but I'll be happy to I will be happy to talk with you about that afterwards okay yeah I mean there's going to be all kinds of different management dysfunction we're gonna cut along the way right but what I'm suggesting is that we know how this is supposed to work right we know the size of the backlog we know the velocity of the team or at least we're supposed to so we can start to derive scope duration cost things like that okay and so if I don't have a team that stays together I will never stabilize velocity and if I can't stabilize the velocity I'm never going to have any idea of what I'm going to be done and you're absolutely fooling yourself if you think otherwise right and so so it's just a problem right but these kinds of teams are really difficult to form in most large legacy organizations okay the third piece we have to be able to again and make a sure follow my slides binding the third piece is we have to make sure that we can get to a reasonable definition of done at the end of the Sprint so we need to know what done looks like we need to be able to test we need to be able to validate I'm not saying we have to go as far in every case to be able to deploy into production but we have to be able to say look this is done and we don't have to go back and rework it any more I came out of project management the joke was always were 90% done we have 80% left to do right and the reason why is because writing the code is you know no disrespect it's the easy part right making sure that it's right and that it's defect-free and that it didn't introduce a bunch of technical debt right that kind of stuff is hard alright so sometimes we have to slow down the apparent throughput of lines of code and to get tested working done features in most environments that is non-trivial okay so what I'm suggesting here is that these three things are difficult but they are an absolute precondition to it okay so let's see which slides I put in here next okay so when we start to scale these ideas we talked about the idea of governance structure and metrics okay so governance is kind of a bad word natural sometimes but it's basically just the way that we make economic trade-offs and the face of scarce resources so the product owner in a pure play scrum team is a governance mechanism to the team they get to decide they get to prioritize they get to set business value right they get to do all those things that's just governance okay so there's a lot of different ways it's scale to start thinking about lean agile governance right safe introduces some lean agile governance techniques large-scale scrum introduces some governance techniques right lots of different ways to do governance not necessarily in the way we're doing it today but there's healthy ways of doing lean agile governance okay structure what does it look like to create cross-functional teams are networks of cross-functional teams that work together across the entire stack okay what has done look like when it's a multi team deployment in eight or nine or ten or a hundred teams have to come together what are the metrics they're gonna use to control that how we're gonna throttle work across it right how are we going to make trade-off decisions and all those kinds of things okay so teams backlogs working testing software at the at the lowest level become structure governance and metrics at the highest level okay and understanding that if we can't get these kinds of things installed at some point then there's not a whole lot that's going on in our transformation that is of much other value okay now if you're who I wasn't yeah there we go okay so what gets in the way one one of my favorite meetings I did it was in Atlanta and there was a group of CIOs that I was like doing like a Lunch and Learn kind of with and one of the CIA's raises his hand he goes but yeah like that that stuff's really hard like well how do I go about doing and I put this next slide up and I was talking about all the different things that get in the way and he said but that's what my environment is I've got technical debt I've got defects I've got a matrix organization I've got this and that the other I got dependencies all over the place okay and I said yep it's your job to fix them okay and part of the challenge that I think that we're not being incredibly transparent about as an agile community is the fact that we know the the brokenness right we know the failure modes in the organization okay and what we're doing often is we're saying let's train people on agile and get them doing scrum and then all of the impediments will show themselves and it'll be up to us to fix them but it's kind of like what I said earlier when your impediment is a 50 year old mainframe platform that's actually running server many billions of revenue it's really tough right it's really tough but to get to the point where we're really doing agile where we're really doing an agile transformation where we can get the culture change and we can get the behavior change we can get all the different kinds of changes this is the kind of stuff that has to be fixed okay so here's kind of like my theory of transformation adopting agile is about forming teams building backlogs and regularly producing increments of working testing software adopting agile it scales about the finding structure establishing governance in creating metrics and tooling strategy that supports agility anything that gets in the way is an impediment to transformation the stuff that gets in the way of doing that is actually the work of the transformation okay training people is like is like it's a necessary activity but it's an activity the outcome is a better performing organization in order to get a better performing organization you actually have to improve in the organization what's broken that work is the work of a transformation so make sense I'm gonna pause for a second and rest my vocal cords any questions I can take a question no guys drinking from the fire hose just crazy talk I thought I could just go to scrum school and everything would be great yes yeah yeah so so what I suspect is that when people come to me and they go well hey you know I did a transformation this way or I did a transformation that way I think most successful transformations were predicated on this kind of a pattern if whether that was explicit or not you know maybe they didn't really realize what was going on but if you successfully transform something then you probably implemented these patterns one of the patterns we see that's really interesting quite a bit is an executive that goes to from one organization to the other and in the previous organization they were really successful just introducing agile practices and and you know cultural stuff and everything chances are if that worked it was because they had a really natural team based organization and there was a lot of decoupling between them and there weren't a ton of dependencies and everything in the practices and the culture and the mindset it became an enable or a force multiplier on top of whatever they had which I would totally agree with right but then they do the same thing in the next organization and they've got that 50-year legacy platform they got all this technical debt defects dependencies misalignment all that kind of stuff in the same technique doesn't work because the underlying patterns that enabled it over here weren't available and they didn't have to fix it over here now they've got to fix it in their new organization it's make sense yeah yeah yeah so I'm gonna talk a little bit about how we recommend a structure and plan these things so good timing so what you know this this kind of notion of structure first or systems first is predicated on the idea that we are going to look for patterns organizationally for how we want to form and ultimately encapsulate teams okay and by encapsulate I mean allow them to operate with autonomy with minimal dependencies between them okay so most organizations there's a kind of a hidden underlying pattern that you can discover and it generally means that we've got some sort of services teams think micro-services right that are that are providing core capabilities across the platform you've got feature teams that are consuming those services you might do some kind of program coordination team you might do some sort of systems team if you're doing safe you might end up doing some sort of portfolio teaming but one of the things that we really believe in is this idea that you can begin to think about how to form teams at scale we know that we want encapsulation we know that we want to create dedicated cross-functional teams we might not did it right out of the gate but we want to have a pretty good idea of what we're going for right out of the gate so most organizations in some form or fashion tend to look something like this there's a set of shared services there's a set of services that get coordinated by a program team they get coordinated by some sort of subordinate to some sort of portfolio team okay almost always when we're in the presence of dependencies do we need coordinating entities so here's kind of a rule of thumb right we want things to be very loosely coupled right we want encapsulation we want no dependencies but here's the thing where sometimes we go wrong community we want to pretend dependencies don't exist because they shouldn't exist when they actually do exist okay and the challenge is is that most large complicated organizations are not going to self organize dependencies okay and so when you have dependencies when you don't have the right level of encapsulation you have to have more orchestration as you begin to encapsulate break dependencies you can deprecated some of the orchestration so the challenges is in the presence of dependencies dependencies have to be managed somehow okay we can assume that they'll be self-managed I don't see that that generally works in most cases and then we have to figure out how much coordination then we're going to need okay but most organizations at some form of scale start to look like a pyramid of teams okay you guys will recognize this this is you know very much the kind of pattern that Saif has deployed typically scrum is a great enabling set of processes to govern the performance of execution oriented teams right when you start putting in orchestration layers and you start putting in coordination we typically will tend to run those in more of a Kanban based system okay when we're talking about a portfolio a portfolio of governance in portfolio was basically just a Kanban system of projects hopefully small projects small batch size right but it's basically a Kanban system of projects okay so you start to think about what does the in-state vision of an organization that look that's going to agile look like when they've got dependencies right when there's stuff to manage and it looks something like this then we start thinking about what metrics that we want to use right so this is a handful of like starter metrics that you can use at different levels right so a big part of what we're trying to do is we're trying to think about what is the work of the transformation the work of the transformation is forming teams getting teams backlogs getting teams the ability to produce working tested software and then ultimately starting to systematically break the dependencies in the system so that we can improve the local autonomy and start to deprecate some of the control and actually let these teams begin to operate in a more emergent way so now we're going to start playing some concepts together the work of an agile transformation right the unit of value is a transformed organization okay now what we have to figure out how to do is how to take that transformed organization and break it into smaller pieces okay so we use some words in our practice we've talked about expeditions and base camps but basically what we're really saying is that the process of going through a transformation is incremental and iterative okay do you guys remember Jeff Patton's Mona Lisa picture I should probably inserted in here cuz I keep talking about it at this stage of this talk but Jeff Patton's Mona Lisa picture describes it's really kind of cool right it talks about incremental as like doing the quadrants right imagine the Mona Lisa and for right so an incremental painting would be doodle upper left upper right lower left lower right right that's painting it in increments painting it in iterations is like doing a sketch and then doing a watercolor and then putting oil on it and then fine-tuning the oil okay so you can think about transforming an organization in the same fundamental way you can think about breaking it into chunks increments and you can think about iterating it and helping it get better over time okay sometimes we tend to think about well I just need to go straight to where I want to be realizing that there's all these barriers right that are going to get in the way okay so if you think about the backlog of a transformation the epic feature and user story decomposition is a subset of the organization basically moving through progressive levels of maturity right forming teams building backlogs producing working tests and software right breaking impediments over time okay the I need to get somebody trained I need to get a scrum master hired I need to run a workshop those are activities those are not the value that you provide okay so when we're going back to our executives what we want to be able to say is I took slice of organization one and I got it to this level of performance and then I made some improvements and I got it to this level of performance and I made some improvements and I got it to this level of performance you guys with me on that okay it's not I got them trained it's that they are performing better okay and the hard part right what makes this difficult is that the impediments in the organization initially prevent it from getting better it makes it difficult for it to get better okay so what you've got to do is you've got to build the case you're like this is how good I can get it while it's got impediments then I get the impediments broken and I can say this is how much better it can be this is how much better it can be after that okay so incremental transformation is basically taking like an entire slice of the organization and implementing it in agile which would mean forming the team's putting together the orchestration layers the program in the portfolio layer getting whatever tooling you're using if whether it be JIRA or whiteboards or sticky notes or version one or rally or whatever right getting your tooling installed getting metrics baselines going getting the system delivering and performing okay figuring out what slice you want to start with in implementing the entire stack of delivery because what the executives going to care about is how is this part of the organization performing better as a result of you having been here to do it right so that's what I mean by incremental it's about figuring out which slice of the organization and getting the whole value stream if you want to call it that delivering okay but we recognize again right so then he'd pick up the next ones right so what we would recognize then is that the transformation process because we have impediments because we don't have perfectly form teams because we have all these things in the way also has to be incremental okay we can't just go trained everybody in scrum everybody's doing daily stand-up meetings we're done right we have to have the systematic removing of the dependencies and so we call these things base camps OOP I'm lost Devon what happened man maybe I lost focus hold on a second oh yeah thing okay cool so what the iterative side of transformation is is how are we going to communicate progressive maturity and performance of the slices that we're interacting with and so what we roughly outline is kind of like a five-step a potentially a five-step kind of transformation sequence the first thing that you can do generally is help the organization get stable and predictable okay help it get to the point where it's able to make and meet commitments it's not really are we building the right thing are we operating with agility or we figure you know it's like got dependencies I've got all this legacy stuff I've got all this stuff so we're gonna do is we're gonna form teams we're gonna get them really clear backlogs we're gonna get them stabilizing velocity we're gonna get them to where they can do like a rolling three-month plan they should be able to operate against some sort of roadmap probably not super super agile at this point because but dependencies make agile hard right but what we want to do is we want to stabilize the system in place then we want to start to think about how do we get things in the market faster sometimes that next phase is about reducing the size of the projects in the portfolio getting smaller things it could be about taking the waste out of the release release management process it could be about introducing some better testing practices braking testing and integrating it in with the delivery stream a little bit more effect léa right but the idea is is stabilize and then start to improve right so then we start to reduce batch size then at that stage you're gonna hit a wall because more than likely you can't go any further without some technology refactoring you've got to ultimately really start to encapsulate the technology components move from you know to a micro-services architecture or something like that start to go to the cloud start to put DevOps continuous integration and deployment kinds of things in okay but that's not usually step one because in step one you don't really know what your architecture looks like you don't know what you want it to be you don't know how you're gonna organize and plan around it so stabilize a system in place then reduce your batch size then start to really refactor and what's cool is that once you get some of these components things refactoring you've got actually dedicated teams around encapsulated technology then you can start to say okay I'm going to give you a bucket of money go solve this really cool problem because now you're not necessarily dependent upon anything else in the organization you've actually legitimately broken the dependencies and what that starts to look like it's scale is let's say for example you have a platform strategy and a and a go-to-market customer-facing strategy one of the things that we do is oftentimes we let the front-end drive requirements into the back-end services you know not every company operates that way some say this is how we're gonna evolve our platform the sales guys can only go out and sell the stuff it's actually going to be in the platform or in the platform's roadmap right they can't inject dependencies down into the backend that's kind of like a step four level of maturity but you have to have decoupled teams in order before you can really start to think about doing that right and then Step five is more like a radical like innovation kind of thing like okay here's a bucket of money go solve this problem kind of a deal okay so when we think about incremental transformation right we're talking about taking the organization and breaking it into slices when we think about iterative transformation we're thinking about what does the continuous improvement plan look like to get the organization from where it is today to where we need it to be in the future okay how am i doing on time they come almost oh my where am I supposed to wrap up about 140 130 130 okay cool let me scoot you over here right so then these things work together right so now what you can start to think about is your moving your transformation by taking slices and moving them through this progression so what you'll end up with is you'll end up with slices that are further ahead than other slices in the organization right and it becomes a really cool way of being able to communicate progress so when I put this talk together it was for agile 2016 last year and I was trying to think like like what would it be like if I were going to try to articulate steps to doing a transformation right what would it actually look like and this is a lot of what we're doing kind of in our internal practice to communicate with our clients about how we're making progress you know one of my big impetus is just to total candor is that as an external consulting agency when we go in and we sell a transformation we are accountable to our executives in this way right we have to be able to communicate progress or we don't get hired right is what it boils down to and so you guys as internal coaches and consultants I think can take the same kind of ideas recognize that to get the funding that you need to even sustain your internal practices that you guys have to be fiduciary responsible to your executives as well okay so kind of what the the high level process that we put together is is you know first of all build a leadership coalition right engage the executives make sure that they're on board and that they understand what it is that you're getting ready to do a big part of that is set their expectations let them know how you're going to to advocate for the architecture how you're going to break things up into slices the kinds of impediments that they're gonna see the kinds of investments that they're going to make get their buy-in get you know get a form together for you guys to be able to hold yourselves accountable next step define an in-state vision I don't think and this is kind of the first point that I made is that it's responsible to say that we're just going to train people and hope for the best right that kind of train and praise strategy right it's not really effective I think it's reasonable I think we know the patterns of how to form teams at scale okay so when we talk about an in-state vision with relatively little effort right we understand the patterns we understand where we need to form teams where we need to create orchestration layers what we're gonna do and say four versus what we're gonna do in something else where are the dependencies that we have to break right so an in-state vision basically paints a picture of where it is that we're going and then once you have the picture right then we can lay out a road map what are the different chunks what are the different expeditions we call them right the increments and then how do we intend to progress them through different levels of maturity okay and you can take an entire organization seven eight hundred people break it into a hundred and fifty person slices understand what teams are going to be formed how they're gonna form what we're going to do to them and then lay that out kind of over time okay call that building a road map next step this is where it starts to get really like agile if we really understand the nature of the backlog right so you think about a release plan usually about 90 days right program increment if you want to use safe okay you can create a rolling 90-day plan of all of the different elements in the organization that you're going to impact you know over the next 90 days we're going to work with these eight teams and we're going to create these two program teams we're going to operate within this portfolio we're gonna install this set of tools and get these metrics baseline right and at some point we have to show up and we have to do the work right but we know that that's gonna be very dynamic right the work the 90-day plan the release plan is like when we know the most about what it is we're going to do right so think of it as like a release backlog okay what are the teams we're going to form what are the entities we're going to interact with what's the level of performance to get to write that kind of a thing so you've got the in-state vision you've got the transformation roadmap now we put together a detailed 90-day plan that's kind of like our release plan for building a product okay but it's subordinate up to that roadmap then we start to get into the habit of doing like a 30-day sprint kind of a thing or you could do this this could be a two-week checkpoint our 30-day checkpoint where now we're basically we're engaging our team members we're doing the work of the transformation we are where basically we're running the workshops we're doing the training we're forming the teams right we're getting them performant we're coaching with them were working with them in the team room right all that kind of stuff okay but here's the interesting thing right when we're doing this now we're doing the work right we're doing the same work that we were doing before but now we're doing it in the context of a 90 day plan we're doing in the context of a road map we're doing it in the context of an in-state vision now we can go to our executives and we can say okay we spent this much of the funding over the last quarter this was the organization we impacted this organization went from having no predictability to this great measureable predictability and we can pull this all out of the tools we can show like what the next steps going to be what the next step after that's going to be okay we don't know all of the activities we're going to do but we can start to get good at sequencing the outcomes that we're trying to achieve right and getting really real about the nature of the work that's necessary to go into that connect activity and outcomes I just kind of talked about that connect outcomes to business objectives one of the conversations we have internally quite a bit is is that goals and objectives and outcomes are kind of recursive you know we know that we want to make more money as a company right but to do that we have to break down some of these barriers in order to break down some of these barriers we need to break the organization into small chunks once we break the organization into small chunks then we have to get it to certain levels of performance to get it to certain levels of performance we have to achieve these intermediate outcomes qi of these and rated outcomes we have to basically do this work right but what we wanted is we want to roll all that up right and connect the dots for the execu because the Holy Grail right of internal consultancies and external consultancies is to be able to say these are the dollars that I spent and here's the measurable outcomes that we achieved and to be able to link those two together right that's how you self fund an agile transformation okay so incorporate feedback manage communication create safety for everyone involved that's why we doing these names and boxes and getting some of this plan it's like it doesn't have to be a figure it out as we go and when people understand where they fit in the overall process that creates a lot of safety for people they understand where they're at in the sequence they understand what their jobs going to look like in the front they can mentally prepare right they can they can you know lay it out so I guess really what this talk is about right it's probably a couple things it's like it's like understand the nature of transformation work the unit of transformation is an organization that is getting better right then we can start to talk about what does it look like to do iterative and incremental transformation at scale then once we've got that right and we understand that that is our fundamental framework teams backlogs working Casso software break dependencies do this in the city of an incremental way then we can start kind of laying out a road map and these release plans and these 90-day plans to where we can be held accountable to make sure that the executives understand the dollars that are being spent to the actual outcomes achieved okay but you got to like think about the work fundamentally different that's why that first part of the talk was so important once you anchor on that and you understand how how it's supposed to function and what the work of a transformation is then it becomes really fun right it becomes like an agile project to actually do it you know and you know a long time I'd always heard people say use agile to implement agile but what they really meant was get together every two weeks and plan and do a daily stand-up meeting right but but the art is in what's in the backlog right and if we get the right stuff in the backlog and then we enable it with agile practices right then we've got a shot it actually you know I think effective with our executive teams I think we got a couple minutes anybody I don't ask a question yes sir yeah yes so anytime you make something like come across as sequential right I mean it's like all of this stuff is like you've got to get to an in-state as fast as you can you've got to get to this right you got to get names and boxes inevitably people start to talk whenever consultants show up right it's all red staplers and stuff like that right people are concerned right so yeah right so you want to get to that right so you try to do lunch and learns and you try to educate and you there's a lot of things that you can do on the side while you're building out this kind of plan you have a question you look like your raise your hand nobody else good okay guys thanks for coming appreciate it

Channel: LeadingAgile

Views: 39,268

Rating: 4.7675352 out of 5

Keywords: agile trainsformation, enterprise agile, scaled agile, leadership, organizational change, project management

Id: _iLo4iQnifU

Length: 51min 17sec (3077 seconds)

Published: Tue Feb 13 2018