Why Agile Fails in Large Enterprises - Large Scale Agile Transformation

okay so you're going to give me an HDMI cable here you guys have audio back there you guys good okay awesome let's see hopefully this will work good look at that all right it's even flipping okay excellent okay so this is going to be super hard from you guys because it's like I had to stand on this little blue box of tape and I am like definitely like a hand wave or move around the room so I'm probably like focus on you guys more because you're closer and I'm just going to like pretend you guys don't like this now I'm just kidding I just won't be able to give you the love that I would normally like to be able to give you guys so this is actually a talk that I launched for I think it was agile 2014 was the first time I presented this and I did it is keynotes for several different companies that it is a keynote for a couple of different conferences that I attended and and basically what I'm trying to do with this talk is I'm trying to build an argument for how I think we're thinking about agile transformation wrong in our industry okay so what I'm going to do is over the next hour 15 minutes 20 minutes something like that I'm going to build a case for why I want you guys to think about agile transformation differently so real quick I mean is there anybody going through an agile transformation right now okay anybody like anybody not doing agile at all at all in the room so you guys like everybody else is like all agile doubt right okay so how well is your agile going who thinks their agile is going awesome okay well yeah of course you guys get right but you know it may be so okay so who thinks this kind of gone yeah it's me okay awful okay there's some hands that didn't go up so some of you guys aren't talking to me but that's okay cool so this talk isn't just why agile fails it's why agile fails and large enterprises and what you can do about it and so as Brian mentioned my name is Micah Meyer I grew up in big complicated messy agile I got introduced into agile when I was a PMP project manager doing large scale kind of enterprise scrum mixed with XP mixed with Rupp mixed with PMI stuff right it was a really interesting hodgepodge that we're going through and what we were doing during that time is financial services if I didn't say that what we were doing during that time is we were blending approaches together because for us the idea of creating a small six to eight person scrum team that had like everything and everyone necessary to deliver an increment of product was absolutely impossible like we couldn't do it so we were blending scrum extreme programming we were applying David Anderson's early work in agile management before kind of pre Kanban stuff to do program and portfolio management and and just developed a really strong point of view about what this thing can look like at scale and then Brian also mentioned I spent a couple years with version one and what was really formative for me about that time is they did about a two-year period I got to experience lots of different companies going through different forms of agile transformations so I'm doing it really well so I'm doing it really poorly and then I became like really super focused on what does it take to do this right and I got really focused on why we were struggling and what the barriers were going on and these organizations so this is a story I'm going to try to tell you guys so a brief historical perspective I hate starting any talk with like the manifesto or anything like that but it's like there's a little bit of this that I'm going to use as a pivot into the next round of slides and so if you look at the history of software engineering right we've been trying to figure out how to build software for a long time okay and so this in this the slide isn't designed to be like an intro to the history of software development but all this stuff was going on that culminated about 15 years ago in the manifesto okay seventeen people got together and they were doing these things that were kind of proto agile and they got together Snowbird Utah and they said what do these things have in common okay and what they came up with was a set of values individuals and interaction over processes and tools working software over comprehensive documentation they came up with customer collaboration over contract negotiation and they came up with responding to change over following a plan what I think's fascinating and this is going to be like the starting place for the argument that I'm going to build is that if you think about what they were really doing during that time is that they were getting small groups of people around a table right doing things like pair programming having an on-site customer demoing working tested software on a regular intervals right they're doing burned down charts or you know whatever right you know user story cards things like that reasonable super-high level but right you guys get the idea but there was all this stuff going on they got codified into a set of values okay that's the point that I want to make right now okay and a set of principles right so I'm not going to read these to you but these are the 12 principles behind the manifesto what I think's interesting about this is one of the things that I struggle with with our community sometimes is that we get really super focused on culture right how we think we get really super focused on process the things that we do and the reason why I think is because when you deconstruct this six to eight people sitting in a room with an on-site customer able to produce something that they can actually get value from on regular increments to get feedback it got turned into a set of values and principles and those values and principles are hugely important okay but it doesn't tell the whole story okay and then scrum came along and in spun up the CSM stuff and it started really codifying the practices that we do Mike owns agile estimating and planning came out really codified the practices of what we do but what I'm going to make the case for is that the six to eight people sitting in a room working with an on-site customer producing something of measurable value every couple of days or every iteration or spring has gotten lost okay it's it's extracted behind the manifesto and some of the practices of scrum okay so I started one of the things was really formative for me about working for version one is I got a lot of time to write and to think because I didn't come out of like a pure play agile environment we were doing a lot of really goofy stuff early in those days trying to figure out how to make this stuff work so I didn't really have industry language so I started writing on leading agile comm and I started writing on version ones blog and I started trying to untangle and unpack some of the things that I was seeing as I experienced our industry firsthand and so there's lots of dimensions that I split this along but one of the dimensions that I started talking about was the idea of when you encounter agile language or agile practitioners you have to kind of understand where they're coming from and the three different points of view that I see most often in our industry so we just hit on right we either talk about agile as culture we talk about agile as practices or what I'm going to talk about is agile is structure okay the structures and organizations that lead to agility the six date people sit in a room on-site customer able to produce something of value every sprint ok so that's where we're going to start to go here's the interesting thing about culture I believe that culture is super super super important and I think an agile transformation would be a lot easier to do if everybody in the world got it ok but not everybody in the world gets it fair ok and so if we approach our transformation by trying to change people's like hearts and minds if we try to focus on being agile rather than doing agile right some of these things you hear a say being focused on values and principles the bet that you're placing ok is that all of the practices and structures are going to emerge from that ok and what I'm finding is that no matter how agile you want B or no matter how agile the people in the company want to be if the underlying structures in the organization don't support agility it gets really frustrating how many guys how many times have you guys seen somebody come back from a CSM class super excited to do scrum and just hit a wall when they get back to the office right okay it happens all the time right because it's like you know you start getting you know small companies right 3040 people right it's easy to run everybody through and to get everybody ellic cited at one time but if you're dealing with a 6,000 person government agency right there are structural barriers to doing agile okay next point if you start with practices right focusing on the things that you do the roles artifacts ceremonies test-driven development you know pair programming any of those kinds of practices the bet that you're making is that going through the motions of doing the practices will change minds but I would suggest again that if the underlying structures that are needed for agile to really take off aren't present what you end up with this is what we call like cargo cult scrum anybody doing the motions of agile without getting the benefits of agile right there was a comment that was made and again I hate to probably hearsay at this point but I read someplace that Ken Shui bird said one time that 70% of the folks doing scrum aren't going to get the value from doing scrum right why because doing a daily stand-up meeting doesn't make you a j'l okay having degrees of freedom being able to respond to change when you learn new things being able to get feedback from your customers that's what increases agility right so no manner of practices are going to help us be more agile if the underlying structures of the organization don't lend themselves to agility okay the third thing when I think of agile structures right I'm watching my slides haven't delivered this talk probably in this form in a couple years so so the reason why I didn't do the ones that I'm doing now is because I just had come up here for the agile DSA thing and there was some fear that if I did the same deck you guys wouldn't come today so so we're we're I'm having to cheat on my slides a little bit so if your structure driven you're focused on forming teams building backlogs producing working test the software installing agile structure Governance metrics things like that because what we want to do is we want to give a home base for the practices that we learn and the cultural attributes that we want to take hold ok so my general bent on agile transformation is that all three of these things are incredibly important but where you start is important as well ok if we start with practices and we think the structure and the culture is going to emerge or we start with culture and we think the practices of the structure are going to emerge I would suggest that's not the way it works right we have to be able to get the fundamentals right and then support that with great practices and then coach culture over time because culture takes a long time to change ok so that's the the hypothesis that I'm starting this talk on ok awesome ok so what do I mean by structure so it was interesting as I went through this deck I realized that my thinking on this has evolved and so I did this talk in 2014 and then I did a talk called the three things you need to know to transform any size organization into an agile Enterprise you can clearly see I am NOT good at writing short talk titles okay so so what I did is I lifted this next slide sequence out of my three things talk ok and so I started to tell the story this way then we kind of built on it this year and did this thing called the executives guy deleting large scale agile transformations which is really just kind of a progressive kind of realization of what we've been doing and so when I talked about the things in agile they'd have gotten abstracted behind the manifesto in the practices of scrum I would suggest are these three simple things teams backlogs working test and software okay if you don't have those three things nothing you do with scrum is going to work no cultural change that you guys want to install is going to happen okay might that's what I'm banking on for the next hour or so so what do I mean when I talk about a backlog I can't tell you how many people I say do you guys have a backlog and they say yeah of course we have a backlog and then I ask what it is and it's just this series of like thematic things that the product owner wants to build okay they span sprints they can't be done in a couple days right the team can't swarm around them or on the other extreme what we get is a bunch of engineering activities in the backlog okay when you press a room and you say what is a backlog right I always go back to the Mike cone bill wake stuff invest independent negotiable valuable estimator will small untestable okay things that can you can pull one in and take another thing out valuable in the language of the customer small can be done in a day or two testable I know when I'm done right and then estimated all I need to know how big it is if I'm going to pull it into a sprint and when I very first did this I can't remember if it was one of the scrum gatherings or if it was at agile 2014 but I had 500 people in the room right and I said who in the room builds backlogs like this not one person built backlogs that way what is that yeah not one person okay because what you find is that in most large organizations the the infrastructure decision-making roles and responsibilities is not incredibly clear right who has to come together to build that backlog okay because most large organizations fall into the trap of the next thing right how do we form a complete cross-functional team what does that even mean it's scale okay so back in the day I'd always read six to eight people everything and everyone necessary to produce a working tested increment of the product okay well what does it what does that mean when I've got four hundred people all working across a code base what does that mean when I don't have encapsulation I don't have any kind of services orientation I don't have any kind of componentization right the idea is is that with with agile and agile team is basically like an intersection of and this is a little bit jargony but like business architecture technology architecture and organizational architecture I need a business problem I need encapsulated piece of that architecture and I need a dedicated team to deliver it and when you have that right put a product owner in front of it right and maybe you're good but most large organizations do technology challenges organizational challenges business process challenges all those kinds of things can't form the kinds of teams that same 500 people how many people are forming that kind of a team nobody in the room raises their hand maybe three or four but like not a lot right given the size of the room okay and so when you get really specific about what I mean by a backlog and what I mean by a team most people aren't doing it okay the third element the ability to produce something of value every sprint now does anybody know what the definition of done is you guys heard that right okay cool is anybody so serious about done that they don't call it done anymore they call it done done right done done right how about done done done anybody that serious about it right okay the reason why agile is like done so much okay is that when something is done I get to check it off the list a lot of project managers in DC I used to be a project manager the problem with project management often is it's traditionally done in software is that you get this 90% done 90% left to go kind of a thing where we've written all the lines of code but yeah it's not really tested or maybe it's tested but we don't have all the defects worked out of it or we have most of the defects worked out but it's not quite ready to deploy or the customer hasn't looked at it or it hasn't been signed off on we like to take partial credit as project managers in the software industry okay the problem with partial credit is that when you get to where you're towards the end of the project you don't know how much work is left to do every time you leave technical debt every time you leave a defect every time you leave something partially done what's happening is that there's an indeterminant non estimated backlog that's building in secret fare okay so when you hold to your definition of dun dun dun what you're saying is that done is important because here's the thing to me when I was early an agile that separated agile from total chaos if I know the size of my backlog and I know the velocity of the team I can start to anticipate how far we have left to go in the backlog or how many sprints it's going to take to get it done he has with me okay think about it if you don't have a backlog that's estimated and you don't have a team that stays together they won't establish a stable velocity by the way and you can't get to done you have no idea where you're at in that project is that fair okay so the challenge is is that we have to do is you have to really sit and evaluate and ask yourself do I have the three things now if I have the three things would it be possible for me to ask me to go grab me a bottled water I had one a little bit ago thank you very much Brian Wow thank you okay cool so so if you have the three things that's what I call structure sometimes I'll call it systems if you have great systems in place if you have great structure in place then all of the practices around scrum start having meaning okay now the interesting thing is is getting into this idea of like this cargo cult scrum it's like a daily stand-up doesn't fix this okay almost every single problem associated with sprint planning comes from the fact that the product owner doesn't come with a ready backlog the precondition for sprint planning is that the product owner shows up with a ready backlog that meets those criteria right the team has to be able to get together in those first couple hours and figure out what the plan for the next two weeks looks like they have to be able to get to a definition of done every failure mode that I see in scrum or XP or safe or whatever right I'm just picking on scrum since this is kind of the simplest one is a failure to form teams build backlogs or produce working tests and software we fall on the trap of going I need a product owner I don't care whether you guys have a product owner or not but I do care that you have a backlog right I don't care whether you guys have a scrum master or not but I do care that you guys have impediments removed and we can do all the things right so we get really kind of dogmatic into the roles ceremonies and artifacts and we forget these fundamentals all right so your your homework kind of coming out of here is think about is there anything and agile that's going to work the way it's supposed to if these three things aren't in place will you be able to get the value out of it that you expect and I would suggest no right just kind of an interesting aside one of the things that we find is that a lot of lot of organizations really naturally lend themselves to teams backlogs working to us and software right infrastructure is great somebody really smart built the architecture right the organization is is really new and geared towards agile and agile czar just a really simple natural overlay but here's the interesting thing about large organizations they're not okay and because we're not being explicit about team's backlogs working tests and software we're just going through the motions okay sometimes I'll see CIOs that they're like oh yeah when I we were like this 100 person company like everything was perfect we did XP and voix I'm going on and trying to sell them this transformation stuff and everything they go it's not supposed to be this complicated I'm like yeah but it's because you don't have the fundamentals right right the previous organization you have the fundamentals right this thing you just inherited is a mess okay so let's talk about what that mess is okay oh okay actually oh it's funny okay inserted this set of slides in here and then I totally forgot where I was going so you guys bear with me here okay cool so one of the things that I think is cool right was when you start to go into teams backlogs working tested software another way that you can express that where I'm at is this idea of clarity accountability and measurable progress so by giving a team a backlog what you're fundamentally giving them is clarity about what you want to build one of the challenges that I see all the time is that the product guys are flipping some general idea over to the team letting the team try to figure out what it's supposed to be and then they're not happy with what they get on the backside right you don't get to abdicate that kind of responsibility right the business has to give the team clarity on what the build in the form of product owner or some entity that's going to create a backlog for them accountability this is another interesting thing one of the things that scrum all the cultural stuff around scrum is totally predicated on is the team being able to hold themselves accountable and I might add being held accountable by the product owner or the outside stakeholders or what have you okay think about what happens when you don't have a team that stays together people are matrix across multiple teams they've got tons of outside dependencies all around them right what starts to happen is the team stops believing that they can make an immediate commitment they stop believing that the Prophet's process adds any value to them okay so when you don't keep teams together it's not just as bad as like well we're not going to stabilize velocity I see that that teams will stop believing that they can get to a definition of done okay they can't hold themselves accountable nor can they be held accountable by the rest of the organization and then like I was saying about the 90% done 90 percent left to do is we don't have measurable progress on the backside a friend of mine in the community actually tied this to Titus to the Dan pink stuff anybody familiar with his book Drive autonomy mastery and purpose and you know what that's really about is the fact that knowledge workers aren't really driven by money like we have to be like taking care of to a point right we have to be able to feed our families and take care of our kids and pair mortgage and all that kind of stuff but financial incentives actually degrade performance so what he talks about is what knowledge workers want is autonomy mastery and purpose and it was really interesting aha moment when I kind of went from backlogs teams working test the software clarity accountability measurable progress to the notion of purpose autonomy and mastery okay the back log gives purpose having a complete cross-functional team gives autonomy the ability to get to a definition of done gives mastery so if you buy into the Dan pink stuff and you buy into what I the argument that I'm laying out here right it's like the energy that scrum is supposed to bring into the company right that empowerment a self-organization right being able to be trusted by the company being self-motivated it breaks down so I'd suggest that teams backlogs working as a software isn't just about how to do scrum better but it's about how to engage people better right so it's a really interesting thing when you start unpacking this team's backlogs working to us a software idea when you start to scale it it starts to look like the words I like to use or governance structure and metrics and so governance is an interesting thing you guys in DC right you live governance I'm sure right but but governance often times in the Adric community is a dirty word right so I look at governance is just how do I make economic trade-offs in the face of scarce resources okay how do I make prioritization decisions who gets to decide okay if you look at what safe is safe is just a governance framework around scrum give or take right same with less a little bit right same with discipline agile delivery all the scaling frameworks are really just fundamentally governance frameworks okay within them they have structures how do we form teams right how do we do the things that we're being asked to do how do we measure how do we control okay so teams backlogs working testing software clarity accountability measurable press autonomy mastery purpose structure governance and metrics right it's how it all scales up together okay so here's the interesting thing right when you get into large organizations trying to adopt agile the thing that gets in the way of forming teams building backlogs producing working test software or even structure governance and metrics at scale are dependencies okay how many of you guys have dependencies in your organization oh the rest of you guys are just lying come on seriously really come on okay can't believe you guys everybody has the tendency is that come on if you're doing anything non-trivial there's dependencies right okay so you go into companies right and you start to look at the barriers to agile and and this is like the eight that came up top on my mind three years ago when I was building this slide right but things like matrix organizations okay it's not so much that a matrix organization is bad in and of itself but when you have managers that are taking developers and spreading them across multiple projects or QA testers across multiple projects or different development resources or whoever's required to build a product and spread them across multiple things and then moving them around is necessary to load-balanced the organization right you start to violate the principles of forming teams okay you start to think about like okay well where do I go when I have a question not instantly available resources having too much work in process limited access the subject matter expertise large products with diverse technology when I first started getting into agile we were building large-scale systems of systems in the financial services industry we had ACH processing engines on the backside PeopleSoft systems dotnet front-ends Java front-ends Web Services Oracle databases right all that kind of stuff this idea of putting eight people together they could do all that stuff and work across the entire stack wasn't going to happen right you get into this idea of when you're building integrated systems of systems who's the product owner who gets to decide because you have a platform strategy and then you have an integration strategy what you often have his product people at this layer and product people like this right who gets to decide when there's a bottleneck okay so those things are real right but but they're they get in the way of us being able to be agile share requirements between teams technical debt and defects low cohesion tight coupling eight architectural problems and one time I was doing a flavor of this talk for a group of CIOs in Atlanta and one of them kind of bravely state raises his hand goes but Mike that's what I deal with right this is the world that I live in and I said yeah right but every single dependency every single thing you leave in place reduces agility think about it what is agile right nobody adopts agile because they just want to do scrum and I like daily stand-ups right everybody wants to do agile because they believe that it's going to help them respond to change when they learn new things be able to put things in market faster be able to get feedback start generating early return on investment right there's all kinds of reasons that people want to apply scrum and so the interesting thing is is that in the presence of dependencies in the presence of these architectural challenges and organizations you don't have the ability to achieve agility you have the ability to do agile but you don't have the ability to achieve agility and so it's really interesting right so when you start with culture you're assuming that if everybody just got it they would self organize this stuff away I have a buddy who might actually be watching he's going to know I'm talking about him if if he's actually watching this but he's been on a journey for about ten years within his organization to refactor their back-end okay it's requiring incredibly intentional investment okay it's at the highest levels of the organization to progressively start to refactor this stuff okay so suggesting that we're going to get everybody interested in agile and that investments going to kind of magically happen it's a little bit of wishful thinking right just saying I want to do scrum it's you know so what is the expression scroll doesn't fix anything scrum just shows you your impediments right those are the impediments that it's showing you we kept pointing at that screen but that's green right those are the impediments it's showing you so one of the things that I think is that we're being disingenuous with our leaders sometimes when we start with culture or we start with practices and we say it's just going to show us our impediments and we have to fix them well the fixing them are major major investments sometimes there are major reorganizations sometimes and so what I think we have to start doing is we start thinking about how to how to evangelize this stuff in companies we have to start being more direct with the kinds of things they're going to get it get in the way but Mike we don't know everything that's going to get in the way absolutely we don't know everything but I think we probably know 70 80 90 percent of it okay we can create a hypothesis around the rest of it okay we don't have to pretend that we're making it up from scratch we know that this stuff is going to get in the way right so we need to start being on top of that I'll pause for a second take a drink water you guys have any questions you thought you guys by my premise so far I can put out if you put out three things yep okay crack this is the structure yep where to start yeah I think you're saying start with structure I am saying you start with structure we're going to go deeper into that here in a little bit so I'm building an argument for you right so we talk about where does it come from where does this culture stuff come from where does the practices stuff come from okay and then once I get really specific about this team's backlogs working test and software I'm holding out a standard for you guys that I think that most of you guys probably aren't achieving in your organization's okay you guys might be doing scrum really well that you're doing safe really well but I betcha most of the folks in the room aren't getting the business benefit from it that they want but here's the thing so now I'm given everybody in the room a pass because it's not totally everybody's fault okay these organizations are messed up okay but the challenge is if we actually want to achieve agility we have to start getting really real about what we're doing right we have to start getting really real about the problem that we're trying to solve so kind of a transformation theory that we came up with is adopting agile is fundamentally about forming teams building backlogs producing working testing software it's not about principles and practices and who's the product owner and do we have a good you know whatever right backlogs teams working tests of software it's scale it's about defining a lean governance framework it's about creating networks of teams and collaboration all the way up the enterprise it's about the metrics and tools that enable agility and then anything that gets in the way of forming teams building backlogs producing working tested software putting in lean governance networks of teams and metrics at scale is an impediment that ultimately has to be removed not to do scrum not to do safe but to achieve agility okay yeah we're coming I guess I agree with a lot of interesting but I guess one thing troubling you mention clarity yeah and also business fat mm-hmm don't you think that in this world like there is no sort of a single-step way which are just going to nowhere you're yelling and then me utility is about creating a situation we could explain anti fragile things so you can get take advantage of fleeting opportunities yeah how do you do that with Clara well so here's the interesting thing okay some business we're going to get in this in the end to in a section or two for now is that is it sure right I mean the ability to respond rapidly to market the ability to respond to change the ability to do all these things the challenges is that in order to do that you have to have an infrastructure that supports it okay you have to have good architecture you have to have good team organization you have to have all those kinds of things now I'm going to break down some different dimensions to think about where you fall in different Continuum's but I would suggest that not even every company is that right now so bear with me here I'm going to I think I'm going to hit your your question here in a little bit okay so solid agile practices will help operationalize a system and encourage a healthy adaptive empowered culture emerge over time so build the systems get the barriers out of the way the practices and the culture come next that's the point that I'm trying to make to this point okay so we're going to pivot here okay so now we're going to have like a shift in ideas okay the first thing is I was building the case for teams backlogs working test the software structure governance and metrics but most importantly the case for breaking dependencies okay now what we're going to have to figure out is what do we do in the presence of dependencies while we're trying to remove them what do we do with our organizational culture the way it is while we're trying to get it to be more adaptive right while we're trying to get it to be able to respond to change and so a couple years ago we invented this little model we call our compass or four quadrants okay and one of my proudest moments that I probably shouldn't say this on video but one of the coolest things was I think when I first rolled this out ville 2015 one of the guys from Jeff Sutherlands organization came to my talk and then they talked about this in their talk and scrum dot-org has since done some videos around it so it's like the first thing that I feel like I've ever really contributed that like a serious other thought leader actually like picked up on and used right so it kind of gave some credence to this and I think it's a really valuable insight so a couple years ago when I first started writing about some of the challenges that we were having adopting agile in different companies I started talking about the fact that kind of to your point that certain companies are built for predictability okay certain companies are built for change certain companies value predictability certain companies value change so like a really key indicators if you value predictability is if you're doing annual planning cycles projectized organizations trying to put together gigantic interdepartmental Gantt charts right trying to resource level across the whole year right trying to figure out exactly how much scope you're going to be able to build for how much money and all that kind of stuff not no value judgment but rest assured your organization values predictability that's what it's going for okay there are organizations right a lot of the new web startups my company I'm sure Excel all right a lot of maybe some of you guys that really value and are built for change you recognize that the markets are changing and that things are going to be all our place you can build your organization from the ground up most of the time when I run this exercise with executives and I say okay do you want predictability or do you want to be able to respond to change what do you think they say yes of course right they want both right it's so the only thing we want people to recognize at this point is that the more you strive to get predictability the harder it is to respond to change okay the easier you make it to respond to change the harder it is to make any commitments okay there's a tension right so one of the things you try to do is just get executives to reconcile that there's a tension okay and so most of them can do it by the way yeah so on the vertical axis we talked about emergence versus convergence and those are unfortunate words but I can't think of any better words to use and we've tried a bunch of them by the way so don't like send me emails with suggestions right I just decided I'm going forward with this right but emergence for me is like Google right if you think about what Google sells they sell data they sell advertising what does Google build right all kinds of stuff right what other products do all kinds of things right whatever the market will bear to so they can collect your data and sell the people and sell you advertising is what they build doesn't matter how many government contracts are there that it doesn't matter what you build for your customer so probably not many as what I'm hearing right so here's a bucket of money just go build me what everything's cool right inspect and adapt in the market you know missile system can do whatever it wants to do carrier can do whatever it needs to do right all that kind of stuff so on the other end of that extreme talk about the idea of convergence right and so certain markets value emergence right very lean startup inspect and adapt figure it out as you go kind of like what you were talking about and then on the other side other markets value I call it convergence because at the beginning of a project no matter how much we think we know about it there are aspects that we're figuring it out as we go right so we're taking a ton of risk and uncertainty and we're trying to converge upon a time cost and scope outcome that's acceptable to the customer so emergence is I start with a business goal and I can build whatever I need to do to solve it convergence is I start with risk and uncertainty and I'm trying to drive towards the time cost and scope okay so when I started writing about this I started writing about the nature of organizations in the nature of markets and then I kind of accidentally coined this idea of the predictive convergent organization and the adaptive emergent organization and kind of to your point what I was thinking about is in the upper right quadrant the adaptive emergent that's where s is agile we want everybody to be okay because in an adaptive emergent organization we don't value making any commitments we value responding to change we want to do the best thing for our customer based on what we know today right all that kind of stuff great greatness right on the other side the predictive convergent organization I was talking about companies that are built for predictability trying to make and meet specific commitments right there are companies like that okay and is agile us a lot of times what we're trying to do is we're trying to sell an adaptive emergent way of doing business to a company that values a predictive convergent way of operating that's why it feels like a cultural thing okay sometimes right if they just saw it right if they just could get it right they would get it I'm telling you I don't see a world in which government contracts are written that way right I mean there's going to be a place where companies want to make any commitments okay and so as I was building this out I was thinking about predictive convergent and adaptive emergent and then I had this aha moment one Sunday morning I went up my office and I wrote the quadrant and put these things on the axis and I said okay we have two squares on a 2x2 grid right do the other two exist and it was fascinating because when I filled them in I came up with predictive emergent and adaptive converging and it took me a little bit of a while to figure it out but if you think about it right does anybody work in a company that values predictability has all of the structures and everything for making me all the planning right all this stuff but stuff's changing all the time is anybody work in that kind of environment okay yeah so so the words that I started off using is that's in a rational place to be right you can't make and meet commitments if you don't know what you're building and is changing all the time right you just can't okay and so some words that we've used over time or things like ad hoc somebody came up with a really good on its way more politically correct called heroic right a heroic organization I mean they're getting things done but they're doing it with death marches and and you know individuals that are just killing themselves to get the stuff done right what we find is that most companies that are trying to adopt agile are in this upper left quadrant right there there they're built for predictability because there's tremendous uncertainty and what they want to build they're using that as an impetus for going to agile challenges that the organization doesn't always value those things the organization's customers don't always value those things so then just to build out the model the adaptive conversion that was the hardest one because how do you make and meet commitments right to a time cost and scope but still keep the option open for change and what really the aha moment was that's a batch size right you make smaller commitments so if you think about everything in scrum or safe right it's all about the two to four week commitment or the PI every 6 to 12 weeks right the quarterly release plan right create opportunities to change doesn't mean you have to change but we create opportunities to change so the way it kind of built as I talked about the ad hoc model traditional tends to live in the lower left quadrant agile is in the lower right quadrant and then lean startup is in the upper right quadrant so one of the exercises I like to go through with people in companies they say where do you think you are you know it's really fascinating I've done this exercise with folks and there would be like 12 executives in a room and they all identify in a different place on the quadrant it's fascinating right it's so you can use this as a way to say okay where are we now and where would we like to be and we're going to go a little bit deeper into that but here's the thing I'll make sure okay cool is it making sure I got my slide sequence right so this is going to be the first half of the title of the talk why agile fails okay so a big build-up just to get to the first like line of the talk okay so why does agile fail most organizations that are trying to adopt agile I believe large organizations are in the upper left quadrant they're built for predictability they value predictability they're organized for predictability but because either their market is changing so fast or because they haven't put the time and energy into fully eliciting their requirements it feels very ad-hoc it feels emergent it's changing all the time okay so we're going to tie some concepts together so what they do is that they do an agile pilot in the upper right quadrant okay so here's the interesting thing in the upper right quadrant we put six to eight people in a room they give them an on-site customer they can produce something of value every couple of Sprint's you guys see where I'm going here okay they create all the perfect conditions for agile to exist they release it from its governance constraints okay and they take the best in the brightest and get them over in the corner and they just do agile and you know what scrum works when you do that fair okay so now we've done our scrum pilot and now what do we do we say okay let's pick another project or two but we matrix people into the organization and we hold them to the same governance and you know what we so what we're basically doing is we're putting the adoption of agile back into the to the left upper left quadrant okay so what I think is agile is failing is because we pile it in the upper right quadrant we give out all the conditions and then we take the practices and sometimes the mindset and we overlay it on top of our broken organization that's full of dependencies that make sense okay and so the next part we have to strive to struggle with is what do we do about it right how do we overcome this because the the in arguable set of truths that I'm trying to anchor on is if we believe that it's teams backlogs working test the software if we believe that true agility comes from breaking dependencies not by applying scrum okay how do we get to a greater better organized dependency free environment over time okay so when we first started kind of trying to untangle this we've gotten a little bit more mature around it is what we started talking about was this idea of in the upper left quadrant it's incredibly low trust and one of the things what agile looks like to say right I could say we'll just trust us right just trust us right empower the teams and the teams are going to do awesome stuff but I'm telling you teams doing awesome stuff on top of broken organizations does not lead to greater agility it doesn't lead to any of the business benefits I tell you I have project managers that will call us periodically and they'll be like yeah we were trying to do everything right we're trusting the team's empowering the teams but they won't make immediate commitment they won't tell us when they're going to be done and you know what they got to there they ran out of money and they didn't have everything finished and we didn't know it right well if I had a backlog and I knew its size and I had a stable velocity and I could anticipate I was getting to a definition of done I would have been able to solve that problem okay but the reality is is a lot of times they can okay and so it's very low trust so saying just trust me is often not good for the organization right because the teams have not demonstrated trustworthiness the environment that the teams are operating within does not lend themselves to being able to make any commitments okay so kind of our initial hypothesis and this was what we should do is instead of asking the organization to trust us we should get the organization to become trustworthy okay and what I talked about initially was the idea of becoming predictable getting really good clean backlogs getting really solid velocity being able to start to anticipate scope and duration and all those kinds of things getting really rock-solid about it okay now here's the thing we don't want to do that with you know traditional project management so what you do is you do that with a combination of kind of lean agile techniques sometimes in this quadrant I talked about team based iterative and incremental but more highly governed more highly planned driven so in this quadrant I might be doing things like annual roadmaps broken into quarters three to six month release plans really strict kind of three-month backlogs right not the let me just make it up as I go but putting in the constructs to drive some of the certainty that you're talking about okay another interesting thing is I don't know if any of you guys are like Gartner subscribers but Gartner talks about this idea of bimodal what we find is that there are certain or musicians with certain parts of their infrastructure that actually need to stay in this predictable quadrant I mean how many people want a bunch of 24 year old agile Asst working on their mainframe banking system serious right you guys you guys cool if your bank balances off we'll just fix it next front right I mean there's certain things systems of record right things that are more that have to be more stable sometimes it's okay to kind of stay in that lower left quadrant okay for the things that want to move right as we move to the right we start thinking about how to reduce batch size right that's through a combination of program and portfolio management changes sometimes it's release management sometimes it's breaking dependencies sometimes it's technical architecture testing practices DevOps things like that right that's what's required to move over to the right and then as you move up and you actually have fully decoupled teams operating around autonomous increments of the product now we can start to think about doing more disruptive innovation within those platforms so it's interesting is that as a group of practitioners what you guys have to figure out is which quadrant are you in and which quadrant do you want to get to and what's interesting is sometimes that's not driven by you guys sometimes that's driven by the people that are paying the bills and what they're willing to invest okay and I think again a core challenge that we have is that what we believe is agile as' is either a not technically feasible given the constraints within the organization or it's not where the organization wants to be so doing a transformation is often a lot about meeting the organization where it is helping it be successful in place and then making incremental systemic improvements that help increase agility over time you got a squinch efface man you got a question yeah so maybe maybe a more like a comment so it seems like you're kind of building up a foundation first step is okay what would you say to getting the back wall it's the three things man it's back logs teams working tested software okay but sometimes the challenge becomes is that is that forming teams when you don't have the right organizational structures in place or forming teams when you're when you know the right number of people to staff the teams in place or trying to create autonomous teams when you have dependencies right I mean there's lots of different things right trying to get smaller batch size when the organization wants longer term planning so what you find is that usually and we're going to go through this a little bit more detail in the next slide sequence but stabilizing this system requires a lot more energy than people are putting into it today okay like just the idea what you said of building a backlog you know putting a BA and calling I'm a product owner and tell them to show up with user stories is not usually sufficient in these environments I mean a lot of times we're creating small working groups of Architects project managers analysts maybe five or six people almost operating in a kind of scrum team of their own they do nothing but decompose backlog forward and deep okay that are feeding multiple scrum teams integrated dependency aware backlog subordinate to a higher level portfolio kind of a thing right so there's a lot of elements and safe that are that are really sound right if you if we really unpack the model I think I've got some slides in here we'll see how far we get but the idea is is that is that the level of rigor and discipline required is greater than most organizations are currently putting into it or are able to put into it one of the big challenges with backlogs is you think about it and I say this flippantly early on the talk but it's like if you put a product person in front of a technical team they're just saying hey me and I want to go climb this mountain go figure it out right if you're really going to empower that team to go do it at their own pace and their own scope okay right but if you're trying to get eight or ten teams or a hundred teams to operate operate in an integrated fashion and a tightly coupled poorly architected kind of environment ain't going to happen right you're going to create gridlock okay because the challenge is that as those teams figure out their backlog they realize oh I got to go get something from somebody else and they go in the ask them oh I can't do that guy I'm already scheduled out for the next six prints right so when do I get my dependency managed right so what we find is that is it especially so what it boils down to is early in these transformations you've still got to do some of the four we're planning the dependency management the architecture all that kind of stuff but what what is it what makes it agile right well we're doing backlogs we're doing things you're doing working as a software it's just that we're putting more intentionality into the planning because we have to one of the things I say quite often is if you have dependencies you cannot pretend they don't exist and you cannot pretend the team is going to self organize them away okay if you have dependencies you have to manage them if you have encapsulation if you don't have encapsulation you have to have orchestration as you get greater encapsulation you can reduce orchestration as we get the organization right we can reduce the level of planning an overhead that makes sense so that's kind of the premise that I'm going for here and so I gave you guys my theory of transformation so kind of corollary one is agile can mean different things to different companies and not all approaches will work well in every organization you can't come at a government contractor always with a Lean Startup approach right if there's a specific date a specific amount of money in a specific scope I would suggest you have to respect that if there's dependencies and poor architecture and all that kind of stuff I've been talking about you can't pretend that scrum team level scrum is going to make it go away right you have to have a strategy for for working that stuff out and resolving it okay sometimes safe will work sometimes won't sometimes less of work sometimes it won't sometimes it's just lean agile program governance on top of scrum okay but one of the things that I spend I feel like I spend a lot of time doing is giving people permission to plan forward if they need to well but Mike that's not agile well Mike will tell me house you're going to resolve all these dependencies and have some reasonable assurance you're going to deliver on time okay so a lot of times that lower left quadrant it's team-based it's a herd of an incremental but it's still governed it still has a lot of planning around it as with me okay and then as you progress around the quadrants you can start pulling some of that stuff apart but it's all around encapsulation right and then yeah go for it well so so when you look at we say planning cycles within scrum I would kind of say like well what does that mean right I mean scrum in its simplest form is the product owner sits down with the scrum team on every two week intervals maybe they get together every three months and do release planning right I mean do all that stuff but what I find is that the level of visibility into the backlog has to be more tightly coordinated like I'll tell you one time one thing that's interesting I don't think people realize is how pragmatic guys like Jeff Sutherland are like I was sitting at dinner with him one time and I was like hey I find that the single product owner metaphor doesn't work all the time right I sometimes I need to get a group of people together and create like this working group and they do the backlogs loane goes yeah yeah do that no in but that's not what the scrum guide says is well I think these guys intend for us to take the patterns and extend them and do what works I don't think they intend for us to simply apply them in a stupid way that doesn't work okay if it's not working don't keep doing it okay just because a jille says to do it right so the idea is is that what I need is is I don't need product owners operating in scrum Cadence's what I need is backlogs that our dependency aware that the teams can start processing without thrashing around them the Sprint makes sense it's very nuanced if a single product owner can give that to you by all means right but if they can't or you don't have one that can then you got to do something else because I don't need product owners I need backlogs it's a really subtle distinction right okay yeah okay so we have to have the ability to adapt it to our current set of constraints okay so one of the things that we talked about is we talked about this idea of creating an agile journey okay and a lot of us when we pick up the book on agile we want to be able to just go right out of the gate and just do agile if you can form teams build backlogs produce a working tested increment by all means pick up the book on agile and start to an agile start doing scrum start to an XP right but if you have dependencies if you can't form teams if you can't build backlogs if you can't get to a working tested increment adopting agile by the book isn't going to solve the problem okay so what we generally find is I was actually we first created this I was I was kind of a little dogmatic about this path but we've learned that there are ways of going straight from one quadrant to the other if you're willing to create the conditions for that quadrant to work so that I'm not going to go deep into that but we're going to talk about is that in most large organizations trying to adopt agile the path goes something like this ok and ok I want to see what's on my slide ok ok cool I want to make sure I didn't get ahead of myself here ok cool so a lot of times what it boils down to is that if I'm going to go from this chaotic heroic or rational ad-hoc state the first thing is I have to do is at the build trust with your organization and I have to become predictable using lean agile techniques often that requires forming teams getting higher level constructs in place to be able to break down backlogs create dependency aware backlogs to deal with bottlenecks in the system to deal with some of the challenges that we're going to have because we don't have all the right things in place we have to plan in the presence of dependencies we have to subordinate to existing contracts to existing portfolio governance all that kind of stuff it's not going to go away day one ok so the first step in this kind of journey can be let's stabilize the system let's don't go straight towards ok we just have to make it up as we go because things are changing right let's put the energy into stabilizing the system step two let's start moving towards reducing batch size if we're doing 12-month projects let's do six month projects if we're doing six months let's do three months if we're doing three months let's do six weeks okay what kinds of things have to improve in the system to be able to deliver or plan more frequently sometimes that's technology practices sometimes it's release management sometimes it's a little bit of DevOps sometimes it's a little bit of working with the organization on program and portfolio governance lots of different ways to attack that problem but step two is is we've stabilized now let's get things in market a little bit faster okay now there's going to be a lot of organizations as I mentioned banks mainframe platforms systems of Records Gartner mode one kinds of things that probably don't ever need to be any more agile than this and if that's your level of agility that is probably okay okay because here's the thing you can get a lot of this agility without doing like major refactoring of your platform step three if you really want to start unpacking this we have to start making platform changes services orientation componentization breaking the app into smaller feature sets right whatever that means to you guys to decouple usually wear heavy DevOps comes in legacy refactoring kinds of things probably not all of your organization needs to go through the step maybe it's just the the strategic pieces that need to be pulled out and decoupled right there's ways of kind of thinking about that but step three is kind of that hurdle to get through if you want to truly have team-based kind of organizations now here's the interesting thing what I think safe is doing is it safe is taking these upper left chaotic kinds of organizations and it's putting a planning wrapper around the value stream let's make sense okay it's basically saying this is the thing you're going to deliver we're going to do these big room planning sessions we're going to get everybody into the room to do that and what it's basically doing is it's saying okay dependencies are going to live here in the center okay and we're not going to try to break them or refactor them at least there's not being explicit about it and we're going to wrap it on this planning thing that's why safe is so big and heavy and requires so many more roles and so much more definition it's like you safe gets kind of mocked in the industry sometimes by people that like really want small light agile but with Dean's pragmatically doing as he's saying dependencies exist we got to wrap them and we got to deal with them ok yeah I don't know yeah absolutely right yeah yeah yeah absolutely so that's actually the failure mode that I see most common with safe safe implementations is that they go through the motions of safe okay but because the teams aren't encapsulated they don't have stable velocity there's too many internal dependencies those dependencies are not being forward managed very well that they they actually don't find them so you get now we're starting to get a lot of people that are really going through the motions of safe but they're not able to deliver on a steady cadence a predictable increment back to the business okay but the fundamental failure mode of safe is the same thing that's killing scrum just at a larger scale okay it really is it's fascinating so if the value stream is truly encapsulated like if you walked into a company that had seven or eight scrum teams and they were as relatively new and they could do the big room planning or as a division or a group or something that had true encapsulation you probably could do that okay but there's a lot of environments where the value streams or even overlapping okay so again it's all about applying the method into the context that was intended to operate in if the context is broken you got to fix the context right you don't want to change the process so there's a lot of failure modes of safe right now - but what saves kind of doing is it's kind of saying okay we're going to jump over phase one phase two we're going to go straight to phase three and we're going to stay there so I would suggest that in some ways safe is ineffective and it's up and its ability to forward plan right because you're not going to figure that out in a two day meeting but then it also falls short of agility sometimes because it's not focusing on decoupling right how are your forming teams right how you're breaking the dependence of how you're improving the system that's a process rapper okay so I was with a client last week and it was like they were they were kind of bought into a safe implementation and we were kind of like crafting some languages said okay this is how what it takes to do safe well here so if you don't have the conditions to do safe we're gonna have to do some safe Plus right which is the lower left quadrant stuff right if you've got some organizations that need to move faster than safe then we want to start deprecating some of the control as we improve the system okay so we started talking about safe plus safe - right and again I think I think Dean would agree with that right Dean's not dogmatic about any of this kind of stuff it's us who apply these things in a dogmatic way okay because the challenge is that these guys that are doing methodology they have to get it so specific that will buy it and come to certifications and it can be trained on and all that kind of stuff which is fair okay but at the same time a lot of times we don't check our brains in with us and actually help to adapt the methodologies the way they're supposed to be adapted okay but if you can truly get over some of the dependency hump okay then what can start to happen is now we can start to think about team-based project deliverables like the Holy Grail to me a vag 'el is your team right you've got a responsibility for a feature set I'm approving work for you right think about you had a single product owner project to do break it down on the backlog you have a single team that's doing it right that's pure play scrum right that's the way it's supposed to work it when it when you'd all have a ton of dependencies and then if you moved even further past that fully decoupled team-based funding you could now say if you want to get kind of to where you're talking about earlier is I'm not even going to give you a project with the specific set of requirements what I'm going to give you is a goal like go take this market right go and prove this make it 50% better or do a/b testing right figure out what the market needs how it needs to evolve but you've got to get there is my point right just trying to change somebody's mind and wanting them to operate differently I'm suggesting isn't going to work you got to improve the system okay how are we doing on time by the way just machine we're at so it's about 8:00 do we have 30 minutes or do we have 15 okay so I'm going to start blowing through some slides here okay go ahead varsity organization you're going to leave along this path not everybody is going to make you ignore yeah nor should they yeah absolutely yeah so I guess oh so generally it's like I kind of like last year I went to the Gartner conference and I'd listened to all I want was the by Midori because I think bimodal has been talked about very poorly in the industry and so what I find is that it tends to become like one of the metaphors they use dislike aap is an app store okay they're talking about systems of record versus systems of innovation so things that are like systems of record the API is the backend the things that need to be more stable high volume transactions right they don't change as much those tend to be candidates for the lower left quadrant okay also things that maybe they need to change but because of the expense associated with decoupling that are or improving the organization there's certain things that might just need to be left down there on the lower left things like mobile web pieces of the the components that really need to innovate fast things that actually aren't as much systems of record but more systems innovation those things can pull forward okay so I kind of look at Gartner mode1 as the lower-left Gartner mode Tuzla as the upper-right and then there's going to be some things they're going to have to pass through the middle okay or maybe they pass through the middle or they just kind of stay over that lower right quadrant because not everything needs to be disruptive innovation sometimes it just needs to be small batches and get things in market faster and learn and all that kind of thing I mean there's a lot of it's really funny sometimes we think because we don't know everything we don't know anything a lot of people have a pretty good idea of what they want to build they just need to get really good at figuring out how to go build it right the further you go around this arc the more options you create for yourself is what I would suggest I hope that answers your question yeah okay cool so what I'm suggesting is that organizational change can be mapped out in a way that outcomes are measurable and predictable and economically justified and so my talk that I did this past year with the executives guide was really all around really this one slide it's like in the point that I kind of started off with is that even if we want to have a self-organized agile transformation where the organization just inspects and adapts into a better way of working most of these executives sometimes these guys are going to the to the board for millions of dollars to make these changes and improvements and we have to be better as an as a community and communicating how we're going to make these changes what is our hypothesis how do we know that it's valid how do we know we're getting the outcomes and the improvements that we said we were going to get for the dollars that we spent right I think that's a fair place to be so what this begins to do is that when we when we think about the nature of transformation is forming teams building backlogs working test the software structure governance metrics breaking dependencies over time and you start to think about how we map that transformation what's the start what's the end we start to have like a mental model for how we could actually plan our own transformation okay and one of the things I had always kind of heard and this is another thing gets really miss applied is the idea of using scrum to implement scrum because ever heard that right well generally what that means is like take all the tasks that you want to do all the training all the whatever and put them in a backlog and do sprint planning and daily stand-ups and reviews and retrospectives and things like that what I would suggest is that the fundamental I agree with the idea of using scrum to implement scrum but the unit of value and it's in an agile transformation is a transformed organization right so kind of introduced this idea of iterative and incremental transformation and so to develop a roadmap and I'm going to kind of blow through this pretty quick here but the idea is is kind of remembering focus on structure governance and metrics teams at all kinds of different levels of the organization you'll see a little bit of this reflected in safe this is like a really simple kind of reference architecture services teams product teams program team portfolio teams collaborative cross-functional teams at all levels of the organization okay what you find is in most organizations they create some sort of hierarchy some sort of services layer that gets consumed by some sort of product or feature layer that gets coordinated by some sort of program layer that is subordinate to some sort of governance layer okay there tends to be more of these less of those okay is it always three layers or four layers know sometimes it's five or six sometimes it's two right don't build anything more than you have to build but this is the fundamental pattern from a governance perspective scrum is typically the lower tier governance Kanban lean is typically the middle tier type governance Kanban lean is typically the program portfolio governance right portfolio level governance metrics right scrum things that you know and love down at the bottom lean metrics in the middle lean metrics at the top okay so what I'm suggesting is that again when you think about your organization in this structure governance and metrics model you can create a hypothesis around what you would like your organization to look like fair okay and if you can create a an idea of what you want it to look like okay I was like again I told you I've done this talk in this forum in a couple years right so the point that I was trying to make on this slide is that these constructs and metrics and controls I believe can be established without violating agile principles but you remember I've kind of changed the game in my world to be teams backlogs working testing software right getting things in market fast being able to get feedback okay so lean is all about reducing batch size getting things in market faster getting feedback faster right so when scrum at the bottom lean in the middle and at the top okay so what I mean by incremental transformation is that we want to take this structure governance and metrics framework and we want to figure out which piece we want to deal with it first okay so what I'm suggesting here is that you can take your in-state vision right your nose no idea of what you want structure governance and metrics to look like and you can begin to slice the organization the primary increment of value of a transformation is a is a transformed organization up and down this vertical slice okay now if you guys remember Jeff Patton's Mona Lisa picture it's pretty famous picture at this point you know how he talks about the idea of increments being like the quadrants of the the Mona Lisa and then he talks about the iterations being like going from going from like a sketch to a watercolor to an early I'll painting to like a fully realized oil painting right think about like that right so when you look at your entire organization structure governance and metrics then you can start to think about how to break it up into increments like the quadrants of the picture but then from an iterative perspective you can start to think about moving them through those phases that we talked about right stabilize the system reduce batch size break dependencies change your governance change your innovation strategies okay so if you think about it so what would it be what would it look like to say I have a minimally marketable increment of my agile organization minimally marketable agile isn't like inspect and adapt and power let everybody go figure it out right the organization isn't ready for it so stabilizing the system in my view is the minimally marketable increment of angel' transformation and then as you improve the system you can start releasing control and empowering and letting people go as you actually build the kind of organization that where that will actually be successful okay okay yeah go for it you have to give it a lot in practice let me tell you what the challenges right in practice most large organizations have taken like a platform strategy and like a product strategy and so what happens is the platform spans multiple products and the challenge is you have different lines of business that are now expected to share like a common component infrastructure okay and the challenge with that is is that is that there's GM's have fiscal responsibility to their product but they don't always have total control over what gets created in a shared system okay so there's usually kind of a balance so usually the product organization is relatively straightforward the market segmentation is relatively straightforward the prioritization comes in is what do I want to do with the shared components and which is another kind of reason for kind of my case here about this first stage agility minimally marketable agile is that let's say I take this vertical slice in some subset of these shared services right that are most closely aligned with this group right if these guys are doing my iterative and incremental but more planned governed agile and then these guys are still doing waterfall over here my stable structured agile will out waterfall the waterfall guys okay and then what happens is that then you get like three or four slices stable working together then you can move them and progress them together okay so that's kind of how you start to think about it right so agile transformation becomes about you can actually plan it by saying we use this word expeditions of Basecamp so in expeditions like an increment based camps are like moving through the journey so we take an expedition and move it through base camps expedition to move it through base camps for 1015 teams you can start to kind of predict right how long is it going to take to get everybody trained how long is it going to take to get these things stabilized what are the things we need to do to round out the teams what are the key dependencies that we need to manage a break what are the key architectural constraints that we need to deal with right when you stop trying to make you know make it up as you go and you really thinking about the problem you can actually linearize the problem a bit now are we going to learn are things going to change absolutely right we're going to make mistakes and have to have feedback absolutely right but I mean you create that hypothesis and really lay that out and it becomes a really powerful tool for executives and doing change management because now you can say okay this million dollars that you guys have to spend this you know quarter to write this is how we're going to spend it these are the things that we're going to try to improve this is how we think the organization is going to behave differently when we're done this is how much faster we're getting things in the market here's our metrics baselines right this is you know it doesn't have to be soft and squishy at this level right and so let's see what else I have in here okay so we're talking about iterative and incremental stuff organizations can adopt agile safely and pragmatically by iteratively and incrementally introducing structure governance and metrics and maturing practices and culture over time as we create the conditions in the organization for those practices and cultural things to thrive okay so summary you got my theory of transformation right form teams build backlash produce work and test the software anything that gets in the way is an impediment that has to be broken if you guys are going to leave dependencies in place you have to manage them you cannot pretend they're going to self-organize away I think this is an excellent opportunity to go back to your executives and sponsors and say this is what's getting in our way we need we need to get out in front of fixing these things because it's driving the team's crazy right and then kind of these corollaries and stuff like that right so we've just all recently gone through that so what questions you guys have for me yeah yeah yeah interesting right so so yeah I figure yeah whenever I come to DC I just assume everybody in the rooms government contractors doing work for peps right so so here's here's the interesting thing so whenever I work with any kind of municipality and we have this conversation the first thing that I ask is I go how how specific are the actual requirements okay and so again this is a broad generalization but what I would suggest if you think about like laughing walls epic feature user story kind of decomposition I would suggest that the epics are pretty well defined I would suggest the features are probably well defined but there's probably some room for negotiation down of the user story level maybe not always but I would suggest in a lot of them it's like that okay so I have this idea like again like five six years ago I started doing talks on agile program and portfolio management and one of the things I would talk about often is that if you guys is a government contractor have sold in effect a fixed time fixed cost fixed scope delivery to somebody okay it is in your economic best interest to manage that or you won't be profitable there okay so what would you do right those are no longer estimates it's a point that you've sold the deal and committed to it those things are no longer estimates they're constraints so now what we have to try to do is we have to figure out how to optimize our economic outcomes in the presence of constraints so what that means is that when you create that team right that middle tier team that I've been talking about where you get collaborative requirements decomposition what that team does is it looks up at your epic commitments in your future commitments and it says okay what user stories can I build that optimize my chances of delivering the epics on time and getting all the functionality in and the reason why the notion of minimally marketable feature is so important is because at every step of the way if I want to optimize my chances of delivering that contract on time I better be delivering the smallest thing that could possibly satisfy that contract requirement every single step of the way right okay so what we do is we put that team in place and they're there they're looking up and decomposing down making trade-offs at this level to optimize chances of success at this level the challenge is is that if you just give it to the teams and say just go do scrum right without that intentional constant backlog grooming then you don't win right one of the time one of the hardest dates one of the kind of the hardest things this wasn't a government contract thing but I had eight people sitting in a room for about four months and like it was literally I got on the ground and it was like go we put together the road map we put together the epic plan the future plan and then started aggressively delivering the backlog as fast as we could because we had to keep the scrum teams busy and we had to we had to get through the rest of the project and I remember the product owner coming to me one time she's like Mike I this is minimally marketable as it gets I've taken out as much muscle we're down to the bone I can't go any deeper right and they ended up like you know going into the hardening period like two weeks or something like that you know so so aggressively aggressively aggressively make it as thin and minimally marketable as you can and then at the point that you hit the wall then you might have to go over the contract in a performance or whatever but there's there's tactics for doing it I believe when you're willing to look at agile is like a lower left quadrant kind of thing if you're stuck in the upper right quadrant this is what agile is this is the only way to do it then I don't think you win I don't think you win when your customers were like that yes sir so what are your foam it looks like though these things single swing with a good man if you don't have good managers who anticipate dependencies how much differences are well known even yeah yeah so wait till the last minute when you need somebody else's product yeah so so that's a really loaded way you just said that right you know you're the roomful of agile is talking about managers we don't have that managers in agile right teasing with you just tastes like it isn't right yeah so so where do managers go right so I don't think it's just managers deciding the when I talk about the requirements decomposition process I talked generally about four points of view there's a product point of view an architect point of view a product management or project management point of view and like an analyst point of view and what I want to do is I want to get a collaborative team in play and I want them to collaboratively decompose the backlog down and out okay sometimes it makes a lot of sense for the managers to be in that room doing that work because quite often the managers kind of are the architects right they are the people that understand the product they are the ones that are making those decisions the trade-off we make with manage in agile is that we want managers to manage the context to manage the inputs to manage the outputs but we want to empower the team within the cell of the scrum team right yeah absolutely yeah so so I tend to unpack that word manager a little bit in this context but managers often can play those roles any other questions thoughts does this feel plausible yes okay so again right if you really get so let's just do one quick recap so why does agile fail right we're in effect applying a practice or a methodology or own mindset into an environment that's not ready for it okay and it's going to fail every single time so what do you do about it right what you do is that you focus on creating the right context for those practices and cultural desires to thrive but very often that's not a flip the switch because these are deep meaningful changes that you need to make so be very pragmatic with your agile right at you know a shoot for forming really clean and capsulated teams getting really good backlogs being able to produce a working tested increment but be real with where you are given your constraints make trade-offs in the short run but here's the thing when I say that sometimes people will go but Mike if we take shortcuts now we're never going to get where we need to be right so that's why I say put together the end state vision right get really clear on where you're at now where you want to be lay out a roadmap in your transformation about how you're going to get there and then start communicating to the business as you make these changes the kinds of economic improvements that are happening and then ideally what you do is you create pull for future changes right ok so just be really pragmatic about this stuff because there's nothing in agile this like a really it's like a silver bullet right I mean this stuff has to be managed and and I think some of us have drank the kool-aid and we're not managing stuff that we know needs to be managed in the name of agile okay yes ma'am yeah more about yeah super-hard yeah yeah yeah yeah well so so here's the thing is that there will be environments where oh yeah is there a question or here oh okay okay that's sorry I thought it's like trying to get my attention okay so so here's the thing right so not every team's gonna have a tech writer not every team's gonna have a DBA not every team is going to have a subject-matter expert all the time so what tends to happen is it down at the lower levels you organize scrum teams okay and then a lot of times what you'll do is you'll take those subject matter experts and you'll level them up and make them a force multiplier and there'll be like an adviser to the teams or they'll be like in that requirements decomposition kind of feature that group that I've been talking about one of the things I didn't get really explicit about is in that middle program tier we like to run a really explicit Kanban it so sometimes when I'm doing a talk on that I'll put like analysis design build test deploy and so what you might find is that like that product owner team is doing the analysis and design all the decomposition and dependency management up front the build backlog then when it gets to build those backlog items are down getting built at the teams and then let's say you had a performance and scalability lab right there's performance and scalability people aren't going to be down at the team level they might be up here in the program layer is like a step in the Kanban and then deployment and release management could be after that okay so as long as there's small batches running through or managing it and kind of a lean thing paying attention to work in process and you know making sure that we're subordinating in to constraint all that kind of a thing then that kind of system can work so a lot of times its org design just somebody fit into a team or they fit into this larger value stream and even if you're managing like really explicitly in a larger value stream you can still wrap it in a safe construct and do that right as long as you have the right levels of encapsulation and I know that was like a lot of stuff for like a really like a two second action yeah we can do like white boards after there's something yeah one more one more question come on yeah yeah yeah okay so so I'm going to answer that two ways so I don't care about the product owner on the scrum master but I care that the that the functions that those roles were formed to do are done okay so if the problem when you look at it the other way is you can have a product owner and not have a good backlog you can have a scrum master all day long and not have a protected team okay so one of the challenges is that and this is language that I really reject in scrum right teams don't need to be protected they need to operate within a rational system right if they operate it if you think about if you had a team that operated in the way that I'm talking with a really clear backlog able to produce a working tested increment what would that team need to be protected from right the system around that team is broken and so again right I understand that in a broken system the scrum master might have to play that role but what I would suggest is that long term that won't solve the problem okay the only long-term solution for agile at scale and complex organizations is fix the system just as right and that feels and arguable to me because I mean that scrum master just going to get burnt out under value they're going to go do something else right they're going to get tired of fighting against a system that is not going to fix itself so the cool thing that we have in our favor right now is that this isn't ten years ago right we're not explaining agile to people right we're not like this isn't like oh your waterfall let's do a j'l well maybe it is in this town but most towns it's not that right but you know but but you guys tried to pick on you guys but you get the idea right most executives at least in public companies CIO CTOs chief product owners they get a jille they want it but the problem is is that a lot of us are selling them snake oil right just do these things and this magical happen and they know how broken their organ is Asians are and they know this stuff won't work and so they're dying for people to show up and be able to say this is how you do it this is how we're going to justify the investment this is what it's going to look like this is what your roadmap is this is what's going to happen and they're smart people right and so we have a really unique opportunity as agile Asst to go tell a bigger story and to make meaningful change okay and so we don't have to fight this groundswell grassroots thing as much as we used to right there are executives out there that really get it they just want something that's credible right none of this magic hand wavy stuff that we've been doing for the last ten years okay I think we're I think we're at you Mike okay awesome guys good

Channel: LeadingAgile

Views: 114,221

Keywords: agile, scaled agile, mike cottmeyer, enterprise agile, agile failure modes, agile organizations, large scale agile transformation, agile methodology, agile transformation, agile software development, agile project management

Id: Oo3zlOTbN2E

Length: 92min 19sec (5539 seconds)

Published: Thu Dec 15 2016