 Hello. Okay, I've got my work gear on. You're here to work. I've got you for 20 minutes. I'm going to try to deliver some value. My name is Stuart Corcoran. I'm a principal engineering improvement manager at Red Hat, which is just a fancy way of saying I help teams with their agile and lean improvements. I started my career as a developer back when waterfall was state of the art before agile even been invented. And I'm one of the rare breeds that gave up a promising development career to go into QA. Not even QA, but QA management. And then I spent 15 years building tests and QA organizations as well as technical support orgs. Been executive management, been in consulting. In the last 10 years I've spent in lean and agile because having grown up in that waterfall world, I see all the benefits of lean and agile and I want to apply them throughout the world. So, let's talk about breaking down the silos. And starting with a definition. So, silo or silo mentality means teams or groups within an organization that won't, can't, or are hindered from working together in an optimal way. I'm going to talk about why that's bad. Going to give you some ideas about how to break down the silos and we're probably even going to try to do a demo. Bet you've never seen that. So, here are the takeaways. We'll start with the end in mind as Stephen Covey would say. Here's what I want you to get out of it as my customers for this talk. I want to give you the ideas about how to break down silos. I want to give you encouragement to persist in this effort because it is hard work. And I want you to know that it's all about profit. So, you may be thinking, great, that's the name of the talk. Break down silos. I get it. Encouragement. You may be thinking, that's a good thing. I'll go for that. And you may be thinking, it's all about profit. What? Or if you're like me, you're thinking, when can I get out of here and get a beer? But I digress. So, let's talk about profit. The reason I want to talk about it is because this is hard work to break down silos. Why do you want to do it? You want to do it because there's a profit motive and you want to avoid riots. I'll get to that. So, I think all of you know this, but let's go through it anyway. Most of us are, I assume, paid by companies to do good work and keep you off the streets. Companies need profit to stay in business. Cost, by definition, reduce profit and delay increases cost. Delay in delivering products and services increases your company's cost. And, silo mentality causes delay. So, you got all that logic, so let's run it the other way. Silo's cause delay. Delay raises cost. Cost reduces profits. Profits puts a company out of business and you're out on the streets rioting and nobody wants that. So, let's get back to the other takeaways. Persistence. I want to encourage you to persist in these efforts. You've heard just the last talk and other talks in this track today about teams that have gone through this either this or other improvement efforts and none of them happen overnight. It doesn't happen like this. You flip a switch, the silos are blown up and everything's hunky-dory. No. It happens more like this. Hard incremental work chipping away at the silos and making incremental improvements. And that's what we want to do. And what I'm going to do is give you some tools like this big construction crane to help you do that. Tools on how to start. Tools on how to address the challenges you might face. And then ultimately tools to succeed. And so if you can see down here, I'm this little guy with my vest and my hard hat on trying to help you chip away at the big silos. And just by the way backing up, I've been looking at this slide for about four weeks now and just this morning, I noticed that guy's there too. It's odd. Alright, so that's enough of the best joke. And I wore orange because I didn't want to get confused with the yellow vesters. Not one of those, sorry. Alright, so our next why, we discussed why we want to break down the silos because of the profit. Because you don't want to be on the street writing. But why do they cause delay? Well, it's because they lengthen the feedback loop. A silo lengthens the feedback loop. Alright, let's start the demo here. Now, you may have seen throughout the course here of the two days, people trying to do demos, you know, and you think they're brave doing a live demo. Excuse me. Ah, have a cold. But have they ever tried to do a live demo? They thought up in the middle of the night before being jet lagged and awake and using volunteers that they've never even talked to before. That takes guts. But we're going to do it. So, I need two volunteers. One for an easy task, and one for an easier task. Okay, I got one volunteer here, volunteer there. You want easier or easier? Easy. Easy. Easier task is you're going to time this test loop. Okay, so when I start, just look at the clock, see where we're going. And just when we get done with the passing of the test, that's when we'll stop. The easy task is you're the tester. I'm the developer. You're up there near silo. I'm down here in my silo. So, I've been working on my product here. Here are the requirements. I'm putting them in my container. Look, containerized. And I would toss this, but my box got broken. It would all fly out. So, this all goes up here to that silo. And you start testing while I go on to the next thing on my to-do list. Alright, Dev and Test feedback loops. And by the way, when you're done, just throw it back over the silo wall. The feedback loop for Dev and Testers is important because that's how you get the best product, the best quality product, is to have good feedback. Now, the only reason there are silos between Dev and Test is because there are testers. And the only reason there are testers is because the developer can't get the best feedback themselves. It's just human nature that if you've created something, that you are not going to be the best one to objectively look at it. That's why you need the tester for that unbiased perspective. So, that's why we want those guys. That's why we need to have that information go back and forth. Now, when you have a silo, it takes a long time to get that feedback, to get that information and it causes delay. And why does it cause delay? Well, because of context switching and context loss. So, when you're in a different organization, as Dev and Test often are, they're often not sharing the same goals. They don't have the same tools. They don't have the same priorities and they are therefore usually going to have miscommunication, misunderstanding, and all of this is going to cause delay. Really. Okay, well, excuse me while I switch context, my product is back. Sorry. Sorry, I'm being delayed in delivering value to you. Test failed. Four sheets, not three. Page zero and four have too few line segments. Hmm. Okay. I don't get it. Hmm. Guy's obvious an idiot. But he's in another silo. I don't know who he is and I don't care. But, I can't move on with a failed so I'm going to call him up and I'm going to say, and he kept my pen too. Well, I will just have to I will just have to IRC. Not enough information. I call up my tester say, hey, tester, what's your name? Sweet tea. Good to know you sweet tea. I got the bug report. Seemed to be misunderstanding here. Could you tell me the requirements? Three sheets of paper. Got it. Each sheet must have symbols on it. Got it. Each sheet must have fine line segment symbols. Straight line. Got it. And no, isn't there another one? I've got four. A circle symbol counts as two line segments. What version of the requirements are you looking at? Well, weren't you at the meeting? This is V2. Thank you. You get the point. So, context switching. Where was I? I was on context switching just when I had to switch context. You all know this. You're doing work. You get a bug report. You have to drop what you're doing. Figure out what the code was that you're working on. Fix it. Send it back. Go back to what you're doing. Very time-consuming causes delay. And, of course, open source world because you have the extra benefit of another silo, if you will, upstream. You've got to send it all up there, get the patches reviewed, comes down, then it goes to test, and you see the point. It just gets longer and longer. And so what we want to do is shorten that feedback loop as much as possible. So, sweet tea. You know, I think we should break silos. Come on down. I've got version three now of the requirements. Why don't we talk about it, work together? So, here they are. Should be three sheets, right? Should have symbol on it, right? Each sheet must have seven lines. They're up in the ante. There should be no zeros. And a plus symbol counts as three. Okay? So, let's code again. I'm going to start coding here. You take that and you start testing. So, what was our goal? Seven? Seven. Alright. I'm going to code one, two, three, four, five, six, seven. Why don't you test that? One, two, three, four, five, six, seven. Why don't you test that one? One, two, three, four, five, six, seven. Good. How about that one? One, two, three, four, five, six, seven, eight. Uh-oh. Ah, there should be no zeros. Really? No zeros. So, we have to do, alright. But we're right here, so I can just fix that. How many is that? One, two, three, four, five, six, seven. Three sheets. I'll have seven. And we're done. How long did that one take? Four minutes versus half a minute. Alright. Excellent. Eight to one. Thank you. So, there. A demo. A demo of breaking silos and how it improves. So, shorten the feedback loop is the key of why it caused delay. Or, that's what you want to do because it caused delay. Alright. On to the tools. So, how do you get started? Everything is about communication, understanding each other. So, one way to do that to get started is to set a common high level goal. So, you want to set a goal that is customer centric. One such as deliver high quality software to the customer. Or deliver value continuously to the customer. Or complete all the elements of definition done on this feature. Notice they are not goals like land all the patches upstream. A developer goal. Or deliver this feature to test. That's a developer goal. Or test all the code. A tester code. Or find as many bugs as possible. A tester code. Now those are fine sub-goals but you have to have this overall higher customer centric goal that you both work toward. You both agree we're not going to be done until we hit that goal. The second tool in your toolbox is walking their shoes. That means understand each other's processes, their tools, their environments, their priorities that they're getting from their management. And talk about those. And then the key is just don't discover them as you're making this happen. Actually plan to educate each other on it. Set down and say here's all of our stuff. Here's all of your stuff. Let's look at them. See what is common. See where we're going to have issues. And fix those up front. Or at least try to mitigate them up front. And of course if you can merge those together as best you can. Especially at the goal level again. And then always retrospect on a regular basis. So that you know that your work in understanding those goals is having effect. That you are actually understanding each other and not having miscommunication. And finally I guess I highlight this one is of course it's all about people. So we are not teams of automatons. Everyone's an individual. And again if communication is a key then you have to understand how individuals communicate. You have to understand their communication styles, their learning styles, their communication methods and tools, their preferences. And ideally understand their motivation. And again this gets to if you have a separate organization there might be motivated from above in a different way. But again be transparent. Get those out in the open to say hey this is how I'm being motivated. How are you being motivated? And then do your best to mold those into a common motivation that you can both share. And so the key is just to intentionally be a team. Not just hey we want to be a team. But you have to do things. You have to take actual actions up front to become that team. And this is some of the ways to do that. So next challenges that you may face. There are many but here are just three. First distributed teams. So teams in silos are often organizationally distributed. And usually especially in open source geographically distributed. I mean that is the definition of open source. They are distributed teams. So some of the ways you can address that are in person as much as possible. Now it's often a challenge but do the best you can. At least think about trying to meet in person on some sort of cadence if it's even annually but if more it would be better. And that's because of the nonverbal communication that happens in communication. To the degree that you can't do that then use video conferencing and turn the video on. I don't know how many video calls I've been on and there's no video on. If you turn it on it's not as good as face to face but you still can get some nuances of the nonverbal communication out of that. So I encourage you to do that. Finally time zone overlap is another issue. So try to discuss with your team up front how you're going to address that. You can do regional meetings with teams that are time zone compatible and then have a communication in between less frequently. My colleagues Neil Smith and Chuck Coppola did a whole presentation on just this topic. So if you're a Red Hat employee you can find that link online. If you're not Neil's right there so hit him up for it. Alright another challenge. Management support. So in my experience there's several kinds of management support. Full full semi full and semi semi. So what I mean by that is full full you have top to bottom management support of your effort to break silos and the team sees the need for it and is fully supportive of well. This is the best case scenario. I've only seen it once in my career. And despite that it still took two years to fully break down the silos and realize the positive results from that. Semi full. This is management is not supporting this but they're not prohibiting it either but the team sees the need and they're on board and trying to do it and that's fine as long as you have two teams that are going to do this they can take those tools on how to start and start working on it and then start communicating that up to their management to tell them see how much better this is. If you do have management that prohibits this effort well it's a different talk. But it's a much shorter one. Get a different job. And then there's semi so this one is there's management support sort of there's team support sort of this just means there's going to be managers that are very enthusiastic want this to happen. There are teams very enthusiastic and want this to happen and others that are like I'll participate but I'm not really into it. That's fine too. I mean those teams that are enthusiastic again can just demonstrate to the others how well this is going to work. And then the final challenge is all teams are different and that's not I mean that's not really a challenge it's just a fact. It's all about people all people are different so the teams are going to be different their characteristics or interactions are all going to be different. The challenge is don't force uniformity don't make all the teams do something the same way don't make them all break down their silos exactly the same way let them find their way what is the best way that fits their team. So those are the challenges how do you succeed back to persistence you just need to persist in these efforts because they do take time I heard Rashid yesterday Rashid Khan talk about their efforts he told it said it took them four years. You heard earlier an effort that is ongoing at 16 months none of these improvement efforts happen overnight but one way to persist to help you persist is use an improvement cycle and there are lots of different improvement cycle names there's plan to check act plan to study act they're all the same I cut mine down to just three experiment learn and adapt and I like experiment better than plan because a plan usually if a plan fails that has much more negative connotation than if an experiment fails an experiment by definition is you don't know what's going to happen but you're going to try something you're going to try it short term and you're going to try it and learn from it see what you learn and then adapt excuse me adapting can be hey that experiment worked great let's expand it to other teams or let's make it part of our SOP it can be well it didn't work exactly right but it didn't completely fail and we see where we can tweak it so let's adapt it run another experiment or of course there is there can be a this totally failed but like we heard in the last talk you know there's no experiment as long as you learn from it you learned a way not to do it okay so that's how you succeed just persist so I mean sum up first can somebody tell me the name of that formula that famous formula no I don't know what it is I just googled the sum that is I don't think it's a famous formula at all summing up breaking silos reduces delay which increases profit which keeps you from rioting reduce delay by shortening the feedback loops between dev and test or any silo groups and it's all about people increasing the communication reducing misunderstanding reducing misconceptions that all cause delay do that by understanding each other's goals your processes their tools and try to make those common as much as possible don't force all teams to do it the same way and in the end persist just keep trying stuff use an improvement cycle to get you there you don't have to get it all in one big bang you take it in little incremental steps so that's why I have I'm not going to have time for questions but I will be around if you have any and if you didn't get anything out of this or didn't take away any ideas then at least we can go out beer now thank you