 Okay, so how many people work for product companies like Microsoft or Phillips or IBM or whatever. How many people work for service providers like Tata Infosys, get stuff like that. How many people here are coaches or Mentors or you know working on your own have coaches that are on work on your own. Okay. How many people are other? How many people try to raise in your hand? Oh? Not many. Okay. Oh Thank you. Okay. So nice What I want to talk about today is the dispensable enterprise. What does this actually look like in practice? So what's the story that I'm about to tell? Well, one of the things that I've noticed over the years and I'm a tad guilty of this myself is that Agile software teams are really good at building awesome racecar engines. We're good at tweaking agile We're good at tweaking agile software development. We've got a lot of great ideas We can you know, you know keeping the engine analogy going we can you know get better and get better fuel mileage We can become more performant. We can speed things up. We're phenomenally good at this So you got a bunch of really bright people Optimizing software development. I guess that's a that's a very good thing actually, but unfortunately We take these awesome racecar engines that we're building these awesome agile software development teams and We put them in organizational tractors We put them in these legacy organizations with legacy systems and legacy mindsets and legacy management legacy government governance and We've got these you know awesome racecar engines in these tractors and that's a big surprise when we don't win the race I have no idea why you know, I don't think I don't think a tractor has ever won formula one I don't think everyone's even been entered But anyways certainly if one has been entered at some point in history. I don't think it won Because what we really need are? racecars We need these it department racecars that can support our enterprises that can support our organizations But that's just not enough either. We also need a team to run the race car So I'm not a race car driver So yes, I could yeah, I could I could go and buy a race car I presume I could somehow enter it in a race and it would probably I would probably lose because well first of all I'm not a very good not a very good race car driver I have to presume but also I don't have a good supporting team. So we need an organization So we need a great IT race car But we also we also have to have that in an organization that can take advantage that can use and work with the race car In order to win the race So we need to look at the big picture. So this is what I'm what I'm gonna talk about today So I want to address three three important questions. So first of all, what does it mean to scale? At least in it within enterprises and then I'm gonna look at scaling from two points of view How do we scale tactically? So how do we help agile software development or solution delivery teams? I would like to say scale to meet the needs of the situation they find themselves in and Also, how do we scale strategically? So how do we scale agile across the IT department? Because once again, if you know, we have these great race car if we have these great racing car engines These great software development teams, but the rest of the IT department is a tractor Then it doesn't really matter what we're doing. Yes, we'll have a tractor with a really cool engine So what, you know, I'm sure the farmers of the world are go out drinking and they brag about the great engines They have their tractors, but if that doesn't really make news headlines Because we want to win the race because these days if you're not winning the race or if you're least not competitive Then you're pretty much you're destined to go out of business So anyways, what does it mean to scale agile? So first of all like I said, I like to distinguish between two two types of scaling first of all tactical How do we scale agile teams and then strategic? How do we scale like to IT departments? So scaling is it more isn't just about team size Okay, now obviously, you know team size is interesting so we can scale agile all the way from teams of two people To teams of several hundreds of people. I've worked with teams of many hundreds of people Delivering mission critical software into the market like single programs of six seven hundred people Delivering mission critical software into the marketplace. There's not many teams out there like that But they do in fact exist the vast majority of teams are actually 10 people or us Well, let's actually see so many people here right now are working on a team a software development team of 10 people or less Many people are working Maybe a third half. How many people are working on a software development team between 10 and 20 people? 20 to 50 50 or more Okay, pretty big. Not so bad. It's a little bit of a little above average Only about 2% of all software development teams are 50 or more people, but be that as I mean apparently You're above average That's the way I'll spend that one Okay, so Another thing we have to have to be concerned about more scaling is geographic distribution One of the great myths in the agile world is that agile teams are co-located now. This is obviously a very good thing I'm a firm believer in co-location, but the minority of agile teams are co-located The as soon as you have people working in cubes or working in their own offices That's a form of geographic distribution Let alone if they're working in different buildings on the same campus or different buildings in the same city Or different buildings across the planet and the more and more geography distributed you are the greater the risk goes up and you know Cost goes up and bad things start to happen to you so a point that I want to make right about now is that teams in different situations will work in different ways So a team of five people will work differently than a team of 20 than a team of 50 than team 500 a Team that's co-located in a single room will work differently than a team that's in cubes Then we'll work differently than a team that's spread across multiple buildings different teams in different situations will do different things Then we have organizational distribution It's pretty straightforward when everybody on your team works for a single division of a single company Little harder when you have multiple divisions involved politics start to rear their ugly heads It becomes a little more difficult to prioritize stuff like that a little harder yet If you're involved in a consortium of companies that are trying to build some sort of a shared environment Little harder yet if you're off-shoring or if you're outsourcing some of the work So you've got one or more external companies that you're working with to get the job done There's some sort of business contract in place So once again different teams in different situations will work in different ways Then we have regulatory compliance Some team roughly a third of agile teams work in regulatory compliant situations. That's just the reality It's not and it's not it's not a paradigm thing at all If you're working in the health care industry chances are you're have to conform to health care regulations I've done as I've worked with agile teams in very highly regulated environments and those teams those highly regulated teams Work in a different way than the teams that don't face any regulation at all Then we have domain complexity some teams get to work You know build you know address very simple problems So for example, you know not to not to Denigrate the conference, but you know that the conference app. That's a reasonably simple problem to solve right fairly straightforward building an air traffic control system Several orders of magnitude more complex than the the conference out. I Have to think that the air traffic control system team will work in a slightly more sophisticated manner Then the applicate then the conference app development team. It's got a full range on that one And then finally we have technical complexity It's pretty easy to work in an environment where you're working with brand-new technologies You're building a silo system that doesn't have to interact with anything else and it's green fields You're building it from scratch. I've never been involved in something that trivial It's a little more difficult when you've got to work with older technologies We got to support multiple platforms when you have to work with legacy systems when you have to work with legacy data sources When you have to fix legacy systems because you're you know for some strange reason You want to pay down technical that when you have to pay down technical that in your database also a little more sophisticated So we have a wide range of technical complexity that we're dealing with as well And we're gonna work in different ways when we do that so different teams face different scaling factors Okay, and you could all and you could also very easily argue that we're missing some sort of a people or a cultural or skills based scaling factors. Well, that's Yes, I agree. Maybe so but anyways, this is this is challenging enough. So any given team will be somewhere on these scales Your team will be have a different set will face a different situation than your team even though you work for the same company and Maybe developing reasonably similar things but different teams in different situations. It is what it is So one process size does not fit all you need to be flexible Choice is good. Well, I'll hammer on that a few times today. So an interesting question is is this real is You know, are we actually seeing this in practice? So one of the one of the things you might know about me I'm one of those annoying people that send out surveys a lot because I'm a firm believer in finding out What the heck is actually happening out there as opposed to what the gurus are telling us? Because usually what the gurus talk about and what's really happening can be very different sometimes. So in this case It does in fact seem that we the agile teams are in fact facing these complexity factors Sometimes we have agile teams. So for example an interesting thing when we ran this survey This is not something I expected one of the interesting things that happens when you're whenever you run me We do research like this You find you find things you don't expect one of the things that was very interesting Was that agile teams are more likely to be taking on hard problems than non agile teams So the organizations that are doing agile and particularly more interesting ones that are doing both Traditional or you know non agile and agile are finding that agile is much better at dealing with complexity than not so agile ways of working So they've learned to you know Oh, I got a hard problem better give that to my agile team because they're more effective at dealing with that hard problems This is not a good message for the traditional folks What I also found was interesting which I also didn't expect was agile teams on average tend to be a little more bigger than Not so agile teams The good news is we're less likely to be geography distributed now Some of that might be we're still sort of figuring out how to do Geographic distribution that some organizations have have clearly figured out how to do agile in a geography distributed manner But for the most part because we're we work a little bit smarter in the agile world We tend to avoid Geographic distribution when we can we try to you know get people as close as possible So that's a that's a good thing. So anyways, we are in fact seeing People applying agile at scale and it is in fact working. I don't have all the stats with me here today But just take my word for it There's ample evidence that agile does in fact work at scale So if you still happen to be an organization where people tell you oh, you know agile is good for the simple trivial things But you know the real men they do traditional. Well, no, that's not true anymore Agile works at scale now having said that just because other people have figured out how to scale agile and make it work Doesn't mean that you will figure out how to make it work. So, you know, there's no guarantees in life on this one The other issue just to briefly I'm talking about before we get into details a little bit later on is We also need to think about how do we scale? How do we build this racing car this it racing car? So how do we scale agile to the it level and so this is a very high level flow diagram? We'll go into a little more detail in a bit But the idea is how do we how do we streamline the flow throughout the entire it effort? Because all it takes you know Once again, it gets back to the racing engine if we've got some agile delivery teams or lean delivery teams And they're doing a great job But then suddenly they have to work with the data management crowd in order to get a change to the database and it takes six weeks To you know to add a column into a table it takes six weeks to do five minutes where the work Well, that's a bit of a problem and I work in organizations where that's the case It takes six weeks to do reasonably straightforward things because of their onerous processes and all that all that sort of stuff So if we don't streamline everything And we don't find ways for these people to work together effectively Then it doesn't really matter all these cool things that the that the agile teams are doing because we're still gonna get you We're still gonna get Brought down by the one or two teams that are working in the old way The other interesting thing about this is Something that we call this called the bimodal problem. So Gartner talks about organizations being bimodal So you've got mode one teams that they call predictable, which I find insulting But anyways, they're the traditional slow teams then you've got the mode to the agile lean teams that are working fast and In a more disciplined quality focus matter that gets stuff out the door quicker And the idea is that the observation is that somewhere around 80 to 90 percent of organizations Have both mode one and mode two going on Because either they haven't fully transitioned to agile yet, which I think is the case in the vast majority of them Or it makes sense. It does in fact make sense to have some mode one teams and some mode two teams I argue that it's really multimodal. We'll talk about that in a few minutes, but you know be that as it may There's at least you know two or more modes of working in the vast majority of enterprises out there And we need to respect that so if you're an enterprise architect and You are supposed to support development teams, which is you know the fundamental job of enterprise architect At least one of the fundamental tasks. They have to do They have to be able to work with the the traditional teams in a traditional manner and the agile teams in an agile manner And the lean teams in a lean manner and so on Okay, so their jobs become more difficult if you locally optimize on enterprise architecture You've got one way to do enterprise architecture, then you're not going to work well with at least one one of those modes of teams okay, so that I think is an important thing the other thing is this is also this diagram and like I said, there's more to it than this but This diagram is think of this from the point of view of the CIO. So let's let's raise our view up Let's get away from the selfish, you know, whatever our selfish points of you are unless of course your CIO And then this is your selfish point of view but let's look at it the point of view of a CIO and As a CIO if you're responsible for having an effective IT organization to support the rest of your company You got to make all this stuff work The challenge is that there's different bodies of knowledge for all of these things So that you know the development folks the delivery or you know software development folks They've got several bodies of knowledge. We've got the agile cannon. We've got the end you know this the software, you know the software engineering box and Two reasonably different things and see Matt and all good sort of stuff the data folks have got Dama the Management the portfolio management folks. They've got the PMI and the Prince to stuff the enterprise architects They got togaph and modaf and dodaff and zhokman and Five other things that I can't you know whip off the top of my head the operations folks have ITIL and they're all great bodies of knowledge They're all wonderful. They all got some great ideas. They've all got some not so great ideas as well It is what it is They contradict each other. They don't fit together very well. They overlap All of them are the center of the universe like this conference is all but how we agile software people are the center of the universe We're the most important people on the planet and if we were to go to an ITIL conference Well the ITIL people very obviously the most important people on the planet and so on and so on and so on So it's a complete dog's breakfast and worse yet So if you're the CIO you've got to listen to all these people go blah blah blah I till the greatest things in sliced bread and we're the center of the universe blah blah blah Agiles the greatest things in sliced bread where the center of the universe blah blah blah enterprise architecture center the universe All that sort of stuff, right? What do you do? What do you do? So keep that in mind So anyways, how do we scale agile tactically? So an important observation I'm a firm believer in empiricism and as well as in constant improvement so One of the beautiful things about empiricism is that there's a lot of you can see a lot of great things happening out there You can also see a lot of not so great things happening out there So I'm a firm believer in asking questions around the lines of what you know, so any given practice or strategy I'm always asking the question What in what situation does this work? What are the advantages? You know, why would I want to follow this practice if at all? What are the disadvantage with the side effects that I might not you know What are the negative side effects that I might not like about this practice in what situation? Does this practice make sense and in what situation or situations? Does this practice not make sense? I'm a firm believer. There's no such thing as best practices. That's a marketing term Okay, whenever somebody talks about best practices, they're taking you for a they're taking you for a ride Okay, every given practice every green strategy works well in some situations. It is the kiss of death and others So you have to be really smart and you gotta be obvi- you gotta really got to reserve and ask You know ask questions and try to figure out does this practice work well for me So you need choice Because you got to choose the right practices the right strategies the right team structures the right cultural aspects for you And you should always be striving to improve One of the great things what agile is that it made it clear that you know We should be we should be reflecting on a regular basis. We should be actively striving as individuals and as teams to get better That's all good stuff. So anyways The dispensable framework came out of empiricism It was based on the observations of my of myself and my team going around organizations around the world Seeing how they were applying agile in practice seeing how they're applying agile in these not so perfect situations and many of you when you're sticky up your hands very clearly you're not working in such perfect situations and Chances are pretty good. You're not empowered to change those situations drastically at least not quickly You got to learn to live with it and do the best you can the situation you find yourself in and then improve your way out of it I hope or improve your way into a better situation So there's a bunch of you know great great characteristics of that exactly what you expect from agile stuff It's very people-oriented learning oriented We try to get rid of the some things we that you might not expect We try to get rid of all the prescription out there by being gold-driven or capability driven We'll walk through some of the implications that in a few minutes On the Software development side of things I'm a firm believer in looking at the full delivery life cycle from beginning to end and Better yet if you're a stable team, then it's just well from the beginning of that stable team until you know infinity and beyond To quote a good cartoon character. I'm a firm believer in being solution focused not just software focused I think the one of the things the agile manifesto did was cause some significant damage out there in developer land by being too Overly focused on software development. We don't build just we don't just build software. That's a that's a misnomer our software runs on hardware We often have to improve the hardware that we're working on and even deploying to the cloud That's a hardware upgrade in my mind or a downgrade depending on your point of view We often have to change the business structure I know that you know the business processes are on the usage of these solutions We often change the organizational structure of the people that are using these systems We often have supporting documentation. So we have this full solution that we're working on Not just software. So we need to up our game, right? So, you know in the 90s we are the industry was on the right path maturing in that respect We sort of you know one of that we sort of down backslided When we started for overly focused on software. So anyways room for improvement and we're enterprise aware I'll talk about what that is this based on the observation that my team is only one of many teams and That we need to work with these other teams effectively And those and those obviously those other teams need to work with my team effectively as well And we need to do what's right for the company not just what's convenient for my team We need to look at the bigger picture a little more robust Stads of hybrid so one of the one of the great things about agile is that there's hundreds if not thousands of practices out there The problem is that there's hundreds if not thousands of practices out there How do you how do you find out about them? How do you know which ones to apply? How do you know to what extent to apply these practices? Or to even to apply them at all? How do you choose intelligently? So that's an interesting thing. I want you to think about for a few minutes So anyways, like I said, it's pretty easy to observe that my team or your team is one of many teams in your company Unless you're a very small one-team company So how do we how do we make this work? so In this financial we baked in this philosophy of enterprise awareness and what it what it is is We observe, you know, if you observe the history of software engineering that the traditional folks are all about individual awareness I want to be the best tester I could be I want to be the best programmer or the best architect I can be I'm gonna do my work and then gonna throw it over the wall to the next person And then they're gonna do their work and throw it over the wall the next person and so on more like a Tayloristic You know very finely grained way of working and that's theoretically interesting But it's a phenomenally inefficient way to of organizing a team So the agile folks came along and they observed. Hey, you know people people teams of people build software We really need to be team focused We need to you know make have these whole teams We need to get out of their way, you know Given the resources they need this time and money and whatever it takes and then get out of their way Let them you know support them as much as we can of course, but let them do their own thing That was definitely a step in the right direction But we really need these teams to be enterprise aware. I don't need I desperately if I'm a bank of America or if I'm you know some large insurance company or Ford Motor Company or Microsoft or any any these you know reasonably Reasonable-sized organizations. I don't need you going off and creating yet another customer database. I just don't Okay, if there's an existing customer database out there, please we use it. Please follow common conventions Please pay down technical that when you run into it Obviously, we'll have to fund it and find ways to find all this or stuff So we need to we need to be a little more mature. Please follow a common technical roadmap Please follow some sort of common business roadmap make make sure that whatever you're building reflects the overall needs of the Organization and what are whatever our overall direction is? So we don't want teams just going off willy-nilly Doing whatever they want. We need the fleet of teams needs to be sailing in pretty much the same direction for us to be effective as an organization So we can up our game there and this is important. This is a culture building thing So earlier James was talking about the need to you know to improve quality and pay down Technical that well part of that is you got to bake it into your culture So for example if you go home tonight and say you're the only one at home and you walk into the kitchen You want to make yourself dinner? And you walk into the kitchen and somebody has spilled orange juice You didn't do it, but somebody in your family probably your idiot teenage son So the idiot teenage son spilled orange juice, right? It's the usual culprit for anything stupid that goes on in your household So as an adult, what do you do? Yeah, you clean it up, right? You do your cooking first because you're okay. That's strange. So most people Clean first right you clean up the orange juice There's nobody to complain to you you're only on at home so you can complain so maybe you're bimodal but anyways Yeah, you can complain to yourself all you want. Nobody's listening. Okay, so what do you do? You're an adult you clean the orange juice up right as to what you do Well, if you go back to work tomorrow and you open up a code file And there's a mess in the code right poor quality. Whatever the poor quality issue is What do you do? The majority of you will probably leave it alone because you're under the gun You're you've got to you've got to build whatever feature you got to build Somebody's yelling at you to you know be on time and be on schedule. Most people Don't clean up the coat. They haven't you know, so you've somehow you as an adult You've baked into this idea that oh we need to clean up juice when we see it But as a IT professional as an IT adult we still you know across the industry We still haven't figured out Oh, we need to pay down technical debt when we run into it and we have all these excuses for why it's not our fault But it is what it is. So anyways, we need to start baking dispensable. We want to start baking some of these I some of these Cultural imperatives right in to right into our organization So following common conventions working to common guidelines working to a common vision working together Paying down technical debt not such a bad idea Another important observation. This is a snowflake. I realize I'm in Bangalore You never actually snows here, but in Toronto or I'm from you know, it snows, you know 365 days a year. That'll be the lie that I tell you about Toronto. That's not true at all But anyways snows in the winter so snowflakes are unique People are unique if I look around this room It's a room full of unique people And even if there was a is there a set of twins in the room Every so often that no, there's no twins Okay, even if there was a set of twins or triplets if you if you know anybody who are identical twins The one of the big things that they do in life is they go out of the way to prove to you how they're not identical Unless of course they're on TV and there's all shenanigans But even twins are desperate to show you that their identity that they're unique So every person every team and every organization is unique This this is a critical observation. We we're in different situations. So we're gonna work in different ways Even two teams are in basically the same situation We'll still work in unique ways because they're different people with different skills and different preferences And they're gonna work in different ways This can be phenomenally frustrating in a large enterprise where there's people running around with this vision of oh, we're gonna have a repeatable process repeatable processes Have nothing to do with efficiency. They have everything to do with bureaucracy and justifying bureaucracy And they're a good marketing scheme for you know for those of you working it at the service providers You can still sort of get away with you using CMI as a marketing scheme Although those days seem to be numbered, but anyways, we'll have to see how that plays out So what's some of the implications here? Well, if everybody's unique and every team is unique Then one once one process size one life cycles does not fit all so when I go into organizations And I do this around the world constantly It's pretty easy for me to observe that hey There's some teams doing some sort of a scrum-ish type of a thing It's almost always scrum butt or scrum and or you know, whatever you know Whatever marketing terminology is being thrown around today, but there's some sort of of a scrum-ish type of a team of teams going on Sometimes there's some sort of lean-ish con-bonnish things going on Sometimes we see some sort of continuous You know some of the smarter teams or the more effective teams are doing some sort of a continuous delivery type of a thing And every so often we'll see some sort of lean startup You know lean product startup type teams because they're they're taking it They're doing a new product and I see this even in in insurance companies and in banks and in retail companies when they're you know Very clearly not startup companies and yet they're still they've still got teams following a lean startup process Or or some sort of a lean startup type of a thing or you know, they should certainly be doing that So anyway, so because it's easy to observe that different teams work in different ways in this one agile We support multiple life cycles and this can be a mind-blowing thing. So if you're an IT governance person Well now you're oh and You could also have mode one teams going on some traditional teams as well, which we don't cover But you know, we accept the fact that they exist. So if you're an IT governance person, oh My god, all these teams are working different ways They're not they're not creating the same artifacts at the same point in time in the same way following the same templates and oh, no My boom my head explodes right so if I'm if I'm one of these teams like the data management team or the IT governance team or the enterprise architecture folks or whoever they are and I've got to support multiple delivery teams and these teams are working in different ways Then I need to be flexible enough to support multiple teams working different ways And worse yet, even if they were all agile teams So let's let's say we're in the fantasy nirvana land and if we've got all agile teams They're all still working different ways Anyways, and even though I could wave my magic wand. So let's let's just beat this repeal process idea to death Say I could wave my magic wand and all these teams out there You're all following the exact same process right now. You're I because I'm Harry Potter and I'm magical and I can do this Doesn't matter because in a month or two because all these teams are agile They should be improving the process as they go. They should be holding retrospectives or some sort of a reflection activity They should be learning. They should be getting better. So a couple months from now There'll be noticeable deviations in these teams because you'll be learning Six months 12 months from now. There'll be significant deviations in the teams Because you're different people in different situations with different preferences different ways of working and this is what you're naturally gonna do This is the reality in enterprises might not be what you want to hear might not be comfortable But this is the reality. This is observable reality. So let's make this work Let's deal with reality So keep that in mind So let's go through some examples, so There's different ways and this is clearly not all of the ways that we can manage changing requirements But here's a few we can use some sort of a scrum product backlog type of a thing We could extend it a bit with some unified process Concepts and have different types of things on the on the stack and all this sort of stuff But it's the same basic idea. We have a stack of requirements. We work down the stack We could take some sort of a lean approach You know have some sort of a work item pool or a requirements pool We're gonna call that we're pulling things in one at a time. We got different ways We can prioritize the work all good sort of stuff We could do the evil formal change management approach Now all of these strategies have advantages. They have disadvantages They can all be used in agile lean situations I have worked in a situation where formal change management in an agile team where it actually made sense Now that that those situations are few and far between There are several orders of magnitude of people out there that think that formal change management is a good idea when it in their situation when it really isn't but We have to respect the fact that in some situations It does in fact make sense to do formal change management and what this situation was I was working with the team and we were building the software for pacemakers And when you're doing life critical FDA anal and retina of regulatory stuff like that If you don't want to go to jail, you do formal change management Now we also combined it with our product backlog To you know streamline things but for some things we did a formal change management That is the reality on the ground for some companies and we need to respect that if that's not your reality Then please don't do that So anyway, so in this financial we're all about choice So earlier James was telling us how we you know how these Discipline these agile scaling frameworks are all about being safe or being comfortable or acceptable or whatever it is and that's important Because if it's not acceptable It won't be accepted by most enterprises. That's the reality on the ground as well But if you want to be agile We also need to be bold or bold I sort of like the bald one because you know because all the incredibly sexy men out there are in fact bald But anyways, if I would show you ladies, please pay attention. Don't let anybody tell you different Yes, some some men do in fact have full heads of hair my five-year-old daughter also has a full head of hair I just figure that one out for yourselves. You can correlate What are you know taking any implication that you want about the what's going on there? So the point so what okay, so nice back on track. Okay, so choice is good So when we want to address changing stick cooler needs when we recognize that different teams are in different situations And have different skill sets and different priorities and different preferences and all good sort of stuff We need to give people choices. So one of the things that James was talking about is we you know to be truly agile We need to be we need to be bold or we need to be bald Those two things are not mutually exclusive being acceptable and being bold or bald Are not particularly acceptability involve this are not mutually exclusive trust me on this so anyways what we can do is We can give people choices. So the way you read this chart is we've got this goal So throughout construction we want to address changing stick cooler needs somehow because the requirements are going to change and they're going to involve And all this sort of stuff when we do that There's several issues that we need to consider first how we're going to manage our work items So for example, what which one of these techniques or others are we going to follow rock or combinations? They're up how do I prioritize work is it by business value is it by dependency is it by Priority is it you know or by many other techniques when are we going to accept change? So if we're following if we have iterations, do we accept change? Do we accept changing requirements in the middle of the iteration or like you know like most teams do or do we push it off to a future? iteration like we used to do like like scrum used to prescribe up until I think the 2012 scrum guide How do we interact with staples of these so one of the problems that James was talking about which I fully agreed with is product owners are certainly not a perfect solution a hell of a lot better than what we used to do was a step in the right direct Significantly better in writing documents and throwing them back and forth to each other But certainly not ideal so for example When we look at this when we look at this was stickler interact with the team We have this list of choices and it's not all choices So one of the choices is for the team to work indirectly via proxies a product owner being a proxy a business analyst Be a proxy a product manager perhaps being a product a proxy I should say so we're not directly working the developers themselves don't directly work the stakeholders a better way of working Which takes a little more discipline a little more skill is that active stakeholder participation to be side by side? You know what XP used to call on-site customer what we called agile stickler participation in agile modeling the basic idea Was that you work side by side with your stakeholders? So that's that's what that's what on-site customers all about we up the game a bit in agile modeling I said hey, I got a live body there. So instead of just asking them questions and having conversations, which is a great idea Put them to work The business people can actually do some development if you let them they can be active involved in modeling sessions They can draw things on whiteboards. They can fill out a index cards and post it notes or whatever your tool of choice is They can write code these business stakeholders who apparently have no techy skills whatsoever five minutes later They'll be whipping out Microsoft Excel and white writing some you know Uber cool macro That might not be getting tested properly, but details But they can in fact be involved in development if you allow them and it's highly desirable too And it's hard to do and a lot of organizations struggle with this But as James was saying but it's clearly an option So the acceptable strategies which might allow agile to get in the door are this you know throw documentation around Which is a really bad idea Maybe we can up the game a bit get them in you know good business analysts or good Procterors, but eventually we can evolve into active stakeholder participation like Diana Larson talks about like we were talking about agile modeling 15 years ago Now the way you read this chart is That so we've got these goals this this process goal We've got these these issues of these these factors that we need to need to consider and then for each of these factors We've got options now. We're not saying we've identified all possible options. That's not possible but we are saying there's a pretty darn good range and it's enough to wake you up to let you know you've got choices now in behind all this Every single one of these practices or strategies has advantages and disadvantages. So we want to help you make intelligent process decisions so today You might only have the skills or the cultural ability to work with product owners or business analysts That's the best you can do right now today fair enough Better ways of working. So let's bolder ways of working that We can make make you aware of so that way, you know, you've got off. There's an opportunity for improvement here So eventually it may be in a in a retrospective when you start to realize hey, we need to get better at understanding requirements It might tweak that. Oh, hey, let's go looking. Oh, hey working side-by-side with the stakeholders. That's such a bad idea Let's try it out put him to work even better. I can speed things up got more more hands That's such a bad idea Work to another example So we can explore scope in initial ways at the beginning of a pro of a team You know be at the beginning of a software effort if it's a product team or a project team We have to we have to do some initial scoping effort Gotta figure out which direction we're going in and we can do you know user stories on index cards or in some fancy tool We could do whiteboard sketches. This is a UI flow model or a UI Sketch type of a thing and there's different types of obviously many many different types of sketches you could do You could have one of those evil You know evil detail big requirement up front documents There are in fact a few situations very very very few situations where that makes sense But it's a valid technique Usually around keeping me out of jail type of a thing or we could go very high level have goals I've done multi-million dollar efforts where the requirements document was a list of five goals five bullet points Not even a pair not even a sentence Okay, definitely not a paragraph and it was a multi-million dollar effort funded based on five bullet points now That was you know a really a proven team with a good with a proven track record So they didn't really need you know detailed requirements But the point is is you got choices and all of those strategies are applicable in some situations and not others To do what's right for you So the way we capture this in a goal diagrams like this so we're exploring the initial scope Well, what level of detail do we need to go to and the point? I want to make here is that you are implicitly making these decisions On a regular basis you are implicitly making process related decisions So when you're when you're approaching requirements when you're doing requirements However, it is you do it on your teams at some point in time you implicitly thought how much detail do we need to go into? What what types of models do we have to create how are we gonna do user stories in epics? Are we gonna do personas are we gonna do? You know UI prototypes we do data models or class models sequence. You know, what whatever it is that makes sense for you You had to make those decisions. You had to figure how we're gonna go about modeling Are we gonna have formal modeling sessions do jabs from the 1970s? Are we gonna have agile in formal agile modeling sessions all good all good strategies? How are we gonna approach non-functional quality of service requirements? Because those thing you know the non-functionals they will drive a lot of your testing effort They'll drive a lot of your architecture decisions as well. They'll drive you know drive some of your well functional Requirement gathering so we got it. Yeah, we want to start thinking about those reason be early in the effort We got different ways we can fund teams. This will be a bit mind-blowing for the people working for service providers but The way we read this chart so one of our options is to do it once again This is not all the options out there. We could do cost plus So a low time of materials with the occasional delivery bonus in the extreme this is just pure delivery bonus and we and you get paid paid based on value a slightly slightly more risky Way to work is a time of materials So you just get paid a time material rate a slightly riskier way of funding an effort is Stagegate funding so we go we go to the well We you know we go to the financial people every couple months and please fund me for the next quarter jump through whatever their hoops are the riskiest way To fund an IT effort is fixed price the worst possible way unethical way For IT people to do if you want I'm not gonna go into details on that one But please feel free to Google Ambler estimating unethical or Ambler fixed price unethical Will get you to a very interesting article on this subject. So the interesting thing about this slide So we've got choices. Those are these choices are all valid in some situations for agile teams. They all have advantages and disadvantages Do you know when to choose each one? The strategies towards the top or the least risky but also require the most governance on the point on the point of view of the of the business Fixed price pretty much gambling but requires the least you know just fire and forget and hope for the best Everything so anyways, we've got choices. So we capture that is in the secure funding goal So I can go through all all the goals, but just want to give you choice. I want to make you aware of these things so in summary at least to summarize this Goldman approach for delivery we talked about 22 different goals and What and these are all based on observations and not every team does these things So not every team chooses to do risk management for example probably not a badge and probably not a good choice But that's okay. I'm one of the things that James was talking about is how do you do how do you how do you bake in? You know, how do you do or wouldn't it be nice for agile teams to pay down technical debt? Yeah, wouldn't it be nice? So not only do we bake it into the culture at least try to bake into the culture We also bake into the product into the process because there are ways that we can improve quality as we go Hopefully avoid adding avoid creating technical debt to begin with that's another story But if we do run into technical debt, it would really be nice to be paid down and there's a bunch of techniques to do that So anyways when we're scaling tactically, there's a lot of great ideas out there in the agile community that we can leverage But that's just a start and there are some challenges. You know Jane other speakers Have been talking about this at this conference that we need to go beyond scrum We need to go beyond some of these other techniques, but they do form a pretty good a pretty good start This one agile puts it all together. It tries to answer questions. How does this stuff fit together from beginning to end? How do we make choices? How do we you know? How do we live with you know, how do we how do we accept whatever we have to do right now? But how can we inch our way up into better ways of working in the future? Okay, how do we become more bold and Then finally and the idea is that if you don't know how to do agile in reason we're straightforward situations as a Team you're probably going to struggle at scale So if I don't know how to do agile on a small team chances are pretty good I'm going to struggle if it's a large team if I can't do agile when I'm when I'm co-located I'm probably not going to be able to figure out how to do it when I'm geography distributor on the planet You got to learn how to walk before you try to run Okay, and I think a lot of organizations right now are really sort of struggling with this They get good at scrum and then boom they skip a step and they try to go up And they try to start doing you know agile at scale when they can't even do it At they can't do agile at small scale yet at least not reasonably consistently and yet somehow in fantasy land They think they can do agile at large scale Good luck with that now one of the good things one of the things we've observed over the years is that Most of the scaling effort tends to fall down or most of the process tailoring effort made by teams Tends to fall on four of the 22 process goals So how do you approach initial requirements? How do you approach initial architecture? How do you coordinate your activities between within your team and between other teams and then how do you approach testing? That's the blue thing is there and I appreciate you probably can't read any of those these slides are online if you want them So that's scaling tactically now. How do we talk about scaling? How do we go about scaling agile strategically? Well, it's the same sort of issue we have choices and hopefully want to work in flexible matters James was talking about feral architects Roving around your company. I'm not so sure about the word feral. I've seen some feral dogs Out on the street. I'm not sure so sure it will not pet them But I certainly wouldn't have any problems going going into somebody's house and petting their domestic dog That's you know part of the family and working together effectively, right? So anyways, so but this feral architect concept is baked writing as well We can't see on this diagram. He's taking my word for it We're firm believers that the architecture owners on development team on the delivery teams should be actively working With the enterprise architect that might even be one of the enterprise architects depending on the on the way You choose to organize your team and that pattern applies for more than just architecture, of course So anyways, let's talk about so in this in dispensable We've been recently in the last year or so we've been extending it to address this it issue this racing car issue So we've been adding what we call process blades to give people choices because the thing once again if your data group is Offdoing, you know traditional data stuff. They're gonna hose you up or if the enterprise architects are forcing you to go through some onerous You know architecture review process. It's gonna hose you up The entire organization needs to be working together We need to have all these teams collaborating together in an effective manner learning as we go and these IT departments are what's called Complex adaptive systems. So if we're truly agile or reasonably agile, we should be learning. We should be improving as we go So my team will be changing the way that we work based on our learnings Your team will change the way that it works based on your learning if we interact together The changes that I make might have potentially changes to your team and vice versa So we're constantly changing and we're caught and we're constantly learning together and evolving together And we still need to keep this overall flow Going as well and hopefully speeding up right and getting better Okay, so this is something that we got and we can't possibly do this if all of us are working from different playbooks If we're all working from different bodies of knowledge that contradict each other and have Greatly different philosophies, you know an agile person if you go off and read the dama You know the dama data management guide or book or Bach or whatever it's called You will you will probably vomit in your mouth when you read that stuff, but it's the religion in the data world And we have to work with them Right, so we need and we need to respect that So how do you do it? So anyways when it comes to program management? We've got choices There's many different many different techniques and once again I'm not saying that we've got we've identified all possible techniques and all possible combinations but we give you a pretty darn good list and it should certainly get you out of the out of the prescriptive mindset and Let you know that you've got options some of which are significantly better than off than others sometimes From a workflow point of view this is a this is a what I call one of our selfish workflow diagrams We're from the program management point of view so from that activity. How are they interacting with these other activities? What types of flows do we see between them? How do we optimize all these flows? So once again because we're complex adaptive systems who are whatever the people are that are addressing these other activities They will have an effect on program management and vice versa and we have different ways to get some information back and forth Across these activities and ways to collaborate interact with each other We've got you know various patterns for how do you organize larger teams this case? This is one way to organize a program team. Oh And an interesting point we like to say we have explicit architects There's a there's an architecture owner in each of these sub teams and they're part of the overall architecture team for the program Because you've got this court means architecture technical coordination to do yeah We at the enterprise architecture level we've got choices and we can leverage ideas from togaf and modaf and all good sort of stuff And once again, we've got flow So I'll leave you. I'll leave the scaling discussion At least this trick to teach it scaling discussion with there's a little more to scaling agile than a fancy poster Okay, and yeah, we have a fancy poster to well, maybe not so fancy, but semi fancy poster and There's more to scaling agile than just that I think we need to need to be a little more aware of that We need skilled people working together who want who want to work together want to be successful as an organization We want to make this you know, we want to win the race as an organization because the organization is paying our salaries And if they don't we don't win the race no pay can't pay my mortgage. That's such a good thing So what's the story I told? So we've gotten very good at building racing car engines An agile delivery and lean delivery very clearly important, you know, don't get me wrong. This is a good thing. We've done We've moved the ball forward very very good thing But that's a start. Well, we really need our net is an agile or a lean IT department We need a racing car not just a racing car engine But a racing car by itself isn't any good either Right, it's gonna sit in the driveway to look cool. That's okay But it's gonna sit in the drive and get nothing done We really need a racing car with a team that can run it take advantage of it and actually win the race Win the business take over the market, you know, whatever it is that your organization is striving to do Okay, so we need to look at the bigger picture and we're gonna be working at all three levels to improve at once It's not just a you know a change or a quick cut over type of thing. This is a multi-year Well, it's an infinite effort. We should always be improving. We should always be trying to get better So we've got options. So in this financial our goal is We want to help make these options clear to you Well, I let you know you've got choices that choice is good and Help you make intelligent choices in a streamlined incredibly lightweight manner because software development is complex IT is complex one of the one of the common things that we get from people is wow, this is really complex I might my brain is gonna melt well, I Would I invite you to take a look at this and then ask the question always asks is what would you take out? and the answer is well Nothing and you miss this this and this okay, so you want to make it more complex. Okay, fine You know, yeah, I can see that but you know, we're trying to keep it as simple as possible We are in a complex environment It is what it is. This is why we get paid what we get paid if I if I teeth software development was simple We wouldn't get paid what we get paid We just wouldn't right we wouldn't have as much fun either I think but anyways be that as a man So, so thank you very much, and I guess we got a couple minutes for questions No, we're out of time. Okay My work here is done. Okay. So anyways, thank you much. I am available out in the hall All you got to do is come up to me and talk to me. I'm also available by via email to so don't be shy If you got questions and you can't find me in the hall, then please drop me an email. Thank you very much