I'm from the States, I live near New York, and I'm a coach at Big Business. We are here about, is a scaling paradigm that I like, which starts to recognize platform versus product concerns. This is the entire presentation, so we have a lot of room for questions now, or maybe we should do the problems that we're going to be talking about. Don't presume that we have to say, oh my God, should we be doing agile? Should we be doing scrum? Presume that most people do this already. In fact, if I go into organizations that don't officially do agile, the first thing I ask the teams is, who knows what scrum is? Who knows what agile is? Most of them do it, and we still want to get some ideas about consistency. But agile is the new black, everybody has it. There is a problem that a nagging problem, which is not nagging, put the toilet seat down, the problem has to do with big organizations and complex problems. Most people like to talk about it, is to not talk about it. They say, no, no, no, no, it's easy. All you have to do for scrum teams to coordinate together is have a scrum scrum. And to be honest with you, I don't think that solves a lot. If you're having problems as an organization working together, then I don't see why having a couple of people get together a couple of times a week and ask three magic questions of the teams. What have the teams done? What are they doing right now? What problems do they have? I don't think that solves a lot by itself. But a scope issue. This is not a presentation talking about how to organize scrum teams together to put products out on the market. Subscribe to a particular form of that from Craig Norman with feature teams. And I do believe in that. What we're going to be talking about is how to plan between teams to work collaboratively on different products within the organization. And I'm going to start recognizing some things in that organization which many people call core competencies. So let's talk about this distinction that I like to make between products and platforms. And I'm going to use as an example a now dated picture of Apple products. Apple makes a lot of hardware and they make a lot of money doing it. And the way that they differentiate their product lines is do you hold it with one hand? Do you hold it with two hands where you put it on a table? And they want you to be able to do lots of different things but be able to do the same stuff on all of their different product lines. Now to do that they recognize certain platforms. One of them is like an iCloud. iCloud allows you to have the same sort of content wherever you are. That's the way it's advertised. That's the way Apple wants people to understand it. They're not the only ones of course. Microsoft has the same sort of thing. But it's something underneath the products that are actually sold to you. Now iCloud happens to be very visible. It's in your face all the time. There are other companies that are quite not so visible. And I was working with a major US telecom that would be agency that we were working on a product and all of a sudden we started to see that the things that they wanted to work on on the bottom they were doing things like changing the TCP IP stack to actually implement platform product features and they needed to do this with a whole bunch of different products that we were trying to put together. And one of the first times I saw it was the first time I really wanted to delve into it. They also sold that platform. They actually had something like an SDK. They marketed it to other companies as well as marketed it sort of with cost sharing inside the organization to the product teams. So it was kind of a pain in the process to transform that organization. They were so used to doing things the way that they were which was very waterfall-ish. A lot of planning up front to change that around to something a lot more agile. Okay. So the point I want to make is that if you're developing features that will transcend any one product delivery there would be lots of different products that are out there but that planning and coordination doesn't happen in the typical simple agile scrum sort of adoptions. Especially when you start talking about things like oh it's easy to scrum scrums. But concerns talk about the functional and non-functional stuff that has to happen for people like product owners to be able to have value to the customers that they sell products to. But larger organizations that are trying to scale they need to understand a different thing that platform and that platform addresses concerns that cross-cut among many different products. And we need consistency within them. Those are the sort of things that are platform concerns. How many people in the audience work in companies that have things like platforms within them? In other words, kind of components Yeah, yeah. It's really funny how even in enterprises with just IT sorts of things we start to see some of that come out. We used to call them silos. Right? And silos came about because of the understanding of economy scale. That sort of thinking that manufacturing thinking said we can do this in a predictive sort of process. Right? But that doesn't really work in the space that software development finds itself. We're not going to go into that. That's pretty introductory stuff. However, I do believe that because of architectural concerns that it's those decisions which are very difficult and costly to go back and refactor looking at architectural concerns there is some... there's something in there for centralized design. Architecture is going to require that. Good architecture that requires less refactoring later if it's expensive is something that we have to deal with. And good architecture doesn't happen with committees. Good architecture doesn't happen to just grow out of nothingness. You need sort of the best and the brightest solution to make that occur. So we need a way to make that nice small group accountable for the architecture and at the same time we need a way to make them effective within the organization to get that work out. That's really what we're all here about today. Two other small concepts that I want to consider a long way that is the difference between research and development. It's really hard to make. I don't know if the same language transcends all of our components but I've talked to people and they say, oh, we have an R and D team. I say, well, what's the difference between the R and the D? And they say, no, there's no difference. Research gives us ideas that enable new products to be formed from them. Development is the thing that holds that idea and makes it into something marketable. Research usually has the different paintings I was working with the GPS company. We had a ton of problems because these guys were putting together pretty circuit boards to try to get past the simulation and emulation interaction on the test on the real metal. And the paints of building pretty circuit boards are the same as putting together a couple of classes, compiling it and running on the automated test. It takes a longer time. And the problem is, you could go to development people and say, I got these three things over here I need you to work on for the next two weeks, and you commit to that and you say yes. But then you go back to the hardware people and say, we've got some issues with brown loops and how are you going to take care of that? And they say, in two weeks I don't think we can do that and give you new engineering samples. So we do have to recognize that the difference between research and development is real. There's another issue that we have to recognize and that has to do with the type of work that our teams or research teams versus development teams work in. So this is probably a familiar diagram to you, the Stacey matrix which measures the way that we understand a problem versus the way that we understand the solution. And in Stacey things that are very far from being understood either with the problems or the solution art or pay on it things that we know a little about it, they're simple. Most of development for software is in this complicated to complex space. And within that research stuff will fall more to the complex side and most of the development stuff will be somewhere closer to complicated. Because it becomes less of a research problem more of an engineering problem. Finally as far as the business is concerned they can care less about this stuff. Most businesses are very concerned about what their products are finding the right market for them making sure that they hit the right kind of points in terms of pricing and timing and what not. Whether we do agile or I should say whether we do scrum findable they couldn't care less. So it's kind of the problem. Now I'm going to talk about six ways that I've encountered that people try to solve the problem but I need to be able to store them so I can say from bad to good. I'll have one exception this diagram is called a Seinfeld Seinfeld Seinfeld which talks about the problem in a different way if we have simple sorts of problems to solve basically just use a nice checklist. If we have more complicated problems the checklist either is too long or really can't be put together but we will have a number of best practices that we can enunciate and follow. Complex problems on the other hand are only solved when we start looking at the values and principles behind the sorts of things that we do. And truly chaotic problems you really can't make much of a plan to solve them in a complex space. It's really a matter of scientific experiment and trying a whole lot of things very quickly and trying to solve a chaotic problem. So what I'm going to do is grade my solutions based on lean principles and of course we'll talk very briefly about the seven deadly ways to money get on to the solution to give you some time to talk about that. It comes from Tahitio no? He described it in the 2200 production system. Now this was taken by the Poppindex back in 2003 that a very famous book there. I'll bet everybody in here has read called Lean Software Development and Agitokit. I'm going to spin through these what I do and as I talk about the solutions I'm going to use the acronym Tim Wood because it will help organize things so each of the letters follow the same order and they don't get confused. The first waste is transportation and it has to do with moving things in a world of goods and services when you start seeing shipping crates you start seeing places to store stuff you know that there's transportation waste that's occurring underneath it in software we see that kind of stuff that we have handouts we complete one document put it away and notify somebody you have to move on to something else those handouts will occur with the development process we talk about analysis, we talk about design coding, testing each of those things and many times we reflect that process in the silos that we put together thinking up they'll know how to do it best so we'll leave it up to the silos to handle that which is where we get things like QA groups for all that transportation waste Inventory waste is kind of related it's related because the stuff that's work in process that we're dealing with doesn't have any value yet there's a lot of costs associated with inventory but until we translate that into something that the customer needs you're right right we don't see inventory waste because we see it as the way it works we do our business around here we don't challenge that kind of stuff those are the sorts of things that occur with documents or classes for code that we don't need within our current scope right another great inventory waste very easy to make you can do this on Monday morning go back to your repository because each time you're branching the code you're committing another inventory waste which all come up when you try to code together in conflict merge inventory kind of ways motion waste is a little bit different than the transportation waste because instead of damaging the goods that are working on we're damaging the things that are moving on around right and it's not a bit more difficult than a software it's not that in software we're damaging the machines we're actually damaging the people that are doing the software development and we damage them by task switching so when you have a group that has to move from one thing to another and they can't focus on getting one thing done there's going to be motion waste inside that process rating waste is something I'm sure everybody knows about right it's amazing when you look at it Womack once described a weighting waste that Coca-Cola was having they looked at the cycle time between mining oxides for aluminum and producing coke in cans that people would consume and if I recall correctly somewhere around 92% of the time was being spent in inventory and waiting for the next process instead or at 92% waste on waiting and the companies that can go and get rid of that waste will benefit a lot right we commit waiting waste all the time again it has to do with solid but we process it as a waste that occurs when we use things that are more expensive than we need to so for example if we were going to use we're going to build a car and the car needs a spark plug right using a spark plug that's only going to last for 100,000 miles let's say 250,000 kilometers right it's fine that's going to be the average life of the car using a spark plug that's 10 times more costly but can last twice as long yeah it's a better spark plug but who cares we do that kind of stuff that's often relevant we do it all the time and oh a great UML 2.0 diagram is so much better because look before it's a standard but all we really need is a nice picture on the board to make a talk to take a photograph of it send it on to the next point or this is actually very funny a group that was trying to use every one of the guys with four design patterns because they felt that they had achieved their volume using every one of them over processing overproduction is related to batchage and I'll talk about that and it will slow us down overproduction will result in things like inventory waste the first motion waste a lot so many people consider overproduction waste which is building more stuff than you need so you have to inventory it because it's a bad thing a great example of that occurs when you look at the Pareto effect, 80-20 rule and Josh had a picture up there it was actually from a stand-up group that showed that where we only produce 20% of the features that are actually used all the time or frequently and 80% of the features that aren't used will be all shown tempered with the fact that a competitor that has those other features you're probably going to have to achieve feature parity, that's another story defect waste is a really horrible waste because large defects that occur can be dealt with right away usually they're not stable usually aren't all that damaging they may become again something of a learning experience for us where there's even a small late defect we're going to find out until like the night before a release is supposed to happen might cause an evening or a night of pizza and mapudu we have mapudu up here well into the evening mapudu in the United States is known as the most highly caffeinated beverage so it's the choice the drink of choice for many people alright, 70 degrees I want to talk briefly and I'll how to show off hands who knows James Womack and his lean thinking book and the exercise that he did with his daughters alright, I'm going to get this started I'll do it quickly we better talk about batches large batches are a bad thing but the problem with large batches is that at a very early age we get convinced that we can be very efficient by doing things in silence and it goes back to assembly lines and trying to transfer that to other activities that we do so in 1996 James Womack this is the resolution is a little weird here so you're seeing this stuff on the bottom yes we are in 1996 Womack talks about a story he gives about his daughters now James Womack was a researcher at MIT on lean topics and his daughter was 6 and 9 back in those days people communicated with like newsletters that actually printed them put them into envelopes and mail were not like once a month he wanted to be with these daughters so he said hey listen guys I got this stuff to do but I got to take these flyers today and fold them and stick them into envelopes and mail them back you guys want to help and they said sure daddy so he said alright what I'm going to do is I'm going to take each flyer I'm going to fold it I'm going to put it on an envelope we're going to put the address on it I'm going to put a stamp on it and then I'm going to put in the policy and they said daddy that's done we should really have them where we fold all the envelopes first and then we put them all into the envelope fold all the flyers first then stuff them into the envelopes and then we'll put all the addresses on we'll put the stamps on classic assembly line and James of course said hmmm I don't think you're going to do so well let's have a race and they said okay so they divided up the stuff the daughters were doing it and James of course was doing one envelope and flyer at a time what do you think one and James is the same choice and what do you expect from MIT research director but we couldn't understand why and your daughters especially have to do that but when you look at the problem you realize all of the ways that goes into putting stuff in nice neat stacks and moving them to one stack or defect ways right how many times have you folded like a letter or a flyer put it in the envelope and find out it didn't fold it right it doesn't fit right so if you fold in a hundred flyers now you've got to go fix a hundred different things right so the idea here is that work in process with is very important back sizes are very important and what James was doing is what you call single stream flow you do one thing focus on it then move on right that's one of the principles that comes out when you do things like scrub and some of the combat situations allow us to focus not task switch right not commit so many lean ways and the point of all of this is that as an organization we don't need efficient silos what we need are effective organizations okay and again when we start looking at the ways we'll figure this out so let's go in and talk about ways that we can go about doing this problem see how I'm fixing it I'm not going to dwell on this but the first way that many organizations are doing things with scrub and then throwing up their hands and say oh my god I can't do this let's go back to waterfall because like which is big and complex scrub and edge and they don't scale you know we know waterfall we're good at it we feel much safer when we use some of the templates from things like rock or prints what happens when you do that is you start taking all the silos and then matrixing them okay you work 20% on this project you work 20% on it you're 10 so the team if we will is matrixed out of the functional areas and then the projects go across them which means that everyone has at least two managers there's lots of status reporting going on lots of meetings that occur and the silos are managed to be efficient but the organization can't be very effective even if they do what they say waterfall well we can find out we can be on time, on budget, on feature it's still fail and that's the biggest danger in this stuff to go back I'm not going to go through each of these because I think you already know them but you're going to see the grades that come up like here's Tim if it's not a red letter that means bad so I would consider waterfall to be the worst possible way of dealing with the skeleton it's probably going to be started at the organization why would we go back to it now the two other ways that are kind of related the first one I'll call let's do scrub everywhere but we'll keep our platform silos and most of it comes out of like oh if we could fix those product delivery teams that's going to fix the problem but our core components man those are really important we're going to keep doing them in a waterfall kind of way what happens when you take the organization is you'll find the one thing hopefully one thing that you're going to keep it aside you'll find something where there's a lot of web dev going on and then a big data component on the back end right you're going to get these other teams into a list from teams and then you're going to have an endless number of meetings talking about the dependencies between the back end stuff on big data and every one of the stories that the other teams are going to be working on all the other features right so what we're going to come up with basically is a waterfall plan that says when we're going to be doing development for each of the teams so it's really waterfall planning with some scrum execution somehow that's supposed to work what doesn't because the scrum teams no longer can always be ready to ship the planning that went on at first we plan out all the dependencies any assumption that goes wrong like an estimation the whole plan fails and the other problem that I find is that the silos that we keep are usually the most difficult things to work with so the product teams are left hopeless about how to integrate this stuff with their product they don't understand the platform it's all about the platform people but those guys are still too busy so I look at the results of this guy's stuff with batching really didn't move the needle everything is all pre-planned with three dependencies transportation still uses so many documents and the platform team usually wants it that way changes are needed you've got to make some perculean sorts of efforts to try to change what's going on right now platform teams project plan inventory waste haven't gone away right because we're not really going to get rid of any of those dependencies until the very end now motion wise since we have scrum teams some product owners may be able to figure out stuff to do that doesn't have dependencies so we made a little progress with that it's yellow you can do better any wise nothing's changed until we get that to end integration including all of those platform concerns product owners can't sign off they have to see it work over processing it has gotten slightly better right because now we're focusing delivery teams we're not having them matrix and task switch between many different projects at once so that's going to get a little bit better over production again we're going to assume that once people are starting to use agile and scrum they're going to conform to things like Yagney they're going to need it so they'll be able to focus better and do just the kind of stuff that we need notice that that may have some architectural issues and defect wise since we can't do integration until the end it's still just as bad as before now I found a really interesting spin on that with things for component silos and guest stars how many people in here are used to guest stars so you go to a place and you find out that they'd like to staff real product delivery teams and say to a scrum but they say we can't do that so instead you'll have blocks of planning meetings and you'll start hearing comments like these are actual quotes we'll be bridging our integration at the end just like we said sounds very waterfallish you guys are going to have to figure it out we don't have any time we're fully booked for all the timers out here so we have to figure it out or yeah we could have done it this way or that way whatever but we've already made all those design decisions so you're going to have to take it the way that we do it what it looks like is very similar to the other diagram except now there are some people that we give like I guess pink stars to and we say you're a guest star you go to scrum team 1's planning meetings they ain't even going to go to the daily scrumps right you're number 2 you're number 3 and so on and so forth giving them that title of guest stars it's kind of supposed to make them feel better because they don't have to sit with a platform team to just do the work and the unfortunate thing is that when you ask people how has the word come in their reply is they're like we're doing good or if they're asked questions it's like well I don't really know but don't worry it's going in order to spec so they never really get to discuss things that the scrum teams actually need which is like what's the architecture going to look like how does this integration occur so we still have the problem that we get great architectures but they solve different problems and we have problems with integration at the end which is massive rework followed by death marches not a good thing in terms of results the action hasn't fixed we're still doing integration at the end transportation gets a little bit better because it's verbal questions that are going on there's not as many documents out there inventory doesn't get different motion is still a little bit better because again the product owner can make things flow waiting doesn't get better because we call them guest stars this is still a silo of the platforms over processing production and defects they all get attacked we take the platform team and we put a couple of people on each of the scrum teams we say there you go you're t-shirted or t-shaped rather and go forth and be married some of the platform people actually hate that because they consider the product people like a lower form of life so it can be a good initiative the problem the real problem is architecture because the architectural concerns now are on each of the scrum teams to figure it out and somehow work this together so that's the root cause of this is that we still have people that are out there and somehow we haven't been able to engage on best and brightest into this kind of stuff that we need but the platforms together make one part of the problem that makes sense in terms of results because we're doing scrum some of the things get better matching in truth but doesn't go away and that's because we're still going to have to take these steps of architecture that are costly to have to bring them together for the scrum teams we're getting rid of a lot of the transportation ways but you know we have the danger of these fragile architectural solutions in different ways it goes away to the extent that we don't have to create documents to take and move between silos it's better motion is better because of that waiting and over processing we're still just a little bit better what we're doing is we're replacing waiting on platform teams though with waiting on product teams those dependencies have gone away over production is still better I want to move away from this though talk about these two solutions one of them has to do with forming a different company we may find ourselves with silos saying hey we're the guys that have the primary intellectual property of this company it fuels the organization and until and unless we get enough staff to work with so that we can put our talent on all the teams we need to stay together right or you have an organization that actually has a product and a platform it's a platform that is used on internal products and it's a platform that they sell to actual customers outside okay and it makes a lot of sense what happens with this is you'll organize company B which is going to be a platform team and you're going to have several teams out there whether or not they work with scrum or agile doesn't really matter because your product teams are working completely independently what we're doing is focusing on the platform concern this is going to open actually another reason for this a very important reason there are regulatory reasons for doing this Microsoft is a great example of a company that was under regulatory pressure if they had to do this and I see this also happen from some of these big companies that are out there in fact the client I'm working with right now has this problem in terms of what can go wrong companies that are successful will it be able to organize their backlogs and treat most of the customers that they need to treat well do the jobs for them but we still have problems in terms of that disassociation of purpose we have platform people we have product people in there they're really not coming together enough and again the job we're trying to look at is optimizing the organization we're trying to optimize a platform that's where we really go wrong so if you look because of time I'm not going to go and teach you these if I analyze this believe I don't see great results however I believe that it's better than a lot of the stuff you saw in the first three or four solutions because you actually get stuff done the biggest problem with this just to summarize it is that once you have a different company your cycle time the smallest amount of time necessary to see a change like a minimal marketable feature a minimal product they go from like a spring's worth not just to a release's worth which is what you would hope to achieve with like waterfall but actually can become two releases worth because the new company has to take this in mix it with all the other things for the planning on the next release not just when you do this but it's a great solution to certain problems the way that I'd like to see things done is what I call spring everywhere and core component conglom teams and it's a radical departure okay I'm going to skip this slide what we actually do is take our platform divided in half we're going to recognize the platform our team research team we're just going to be working on the next reference solution to stuff that product teams have on their roadmap they're not just creating a component we're not just creating artifacts of what they intend to do they're actually creating working software hopefully something that the product people are waiting for so think of it as a a reference solution in an SDK we then have a D team, a development team these guys are split off they'll be sent onto the different product teams as necessary in the component fashion so where a product team has a platform of concern these guys come out of work with the platform they will embed with each of the product teams for whatever time it takes to do that work so I'm assuming the platform has a backlog of stuff we don't have enough people to stack all the product teams to split them off into little squads two people I'd say that will go onto each of the product teams as necessary but what happens when you do that when you do it in a component fashion is that product owners can now start to plan their backlogs and their dependencies based on the average cycle times that it takes the platform to do the work the other great benefit of it is that organizations can start learning from one another how to work the architecture how to work the solutions that the platform is dealing with to get this thing better t-shaped and that work that will not allow enables the organization to learn about what its platforms really are like the big data size that nobody understands they're always better off in the end for that the other thing that development teams tend to do that I've usually worked is that while their days with the different product teams that they're working with they will puddle together to talk about problems that they're seeing so a development team can very well be implementing something that perhaps the R team is going to be doing later on what we need right away since these people are platform people they'll know how to integrate this together yes we'll create some inventory ways in terms of branching and stuff but we have to deal with it we can go wrong in a number of ways the biggest is that it's a very radical departure from how organizations normally work okay and politics can play a big price you also if you're going to do this need to have a proper way of handling your portfolios so that the funding and the work that the platform people are going to do is going to line up with what the product needs are and you're going to need to do this again in an anticipatory kind of way because the R team is always like a release ahead right that makes sense alright the results on this stuff of course I consider much better the biggest result that I want to talk about is the batching result right we can never eliminate all that waste but because we're working and focused with product people all the time our batching gets to the minimum that we can possibly do and do it in a way that's consistent with good architecture right I'm going to leave it at that just to reiterate things scale is a really tough proposition for large organizations because it's basically a very complex problem but just throwing up your hands and saying oh we're going to return to the waterfall that isn't going to make things any better okay even if you have scrub teams for product development your organizational waste is going to return with a big vengeance you normally see these organizations that are doing a transformation at first the little pilots that they put together are very successful then when they try to take on the bulk of business for the entire organization it fails remember Stacy remember Sintfeld the complexity theory is going to rule I didn't really talk about Conway's law I forgot here's the proposition it came out in the 60's and somebody said oh you know development usually follows an organizational structure and the joke about it is if you have four organizations you're going to have a four passing pilot travel communication you don't want to exceed like seven start small you're not going to fix it in a quarter right the organizational structure is going to emerge that's going to take some time it's a long time we can take whatever time we have inside this break and have some questions and answers and we can discuss things thank you very much the reason that I the reason I think that we need to do Conway for the development teams is that the estimation component is very useful we want to talk about overall if we're doing strong things like points for the entire story but talking about what the contribution of DT those little squads is going to be is useless so any of the estimation occurs on the product side but the work that has to happen from the platform people is really tasks does that kind of get to where you're going with it what do you believe in estimation for platform issues what do you believe in estimation on the story side or the future side good question I think on the integration point when you're working with multiple product teams do we need to do integration early or late no in the words of Alphanone who was a famous gangster from Chicago when he was talking about trying to bring elections where he said vote early and vote often integrate early and integrate often a big component of continuous delivery which means continuous integration which implies lots of automated testing automated deployment so please do that all the time that's the only way you can really cut down on the defect waste is to encounter the problems early that's why there are so many grids of the batching and stuff yeah I agree I hear something maybe you could we started a little bit so I apologize let's get it