 It's 11.30. Let's get started. Are we ok? Right. Hi, Simon Reason. This is Mike Pollard. We're going to do an enterprise experiment. So I would like to ask you a very simple question first. Who here has successfully introduced agile into one single team? Come on, let's get those hands up. I see Marvellous. Right about half the room I'd say. So lets get it right first time. No, probably not. I bet you tried different things. You tried things that were... maybe successful, maybe not. What you're actually doing was experimenting. So when we introduce agile in the enterprise, to make that successful, Ymwneud yw bwysig i ddweud arweithio lleif arfermyn. Yn hyn arwch Simon. Ac mae'n golygu yn ddyledig ymwneud a'n gallu'n weithio'r ysgrifennu lleolau a gweithio'n ddiwylliannol sy'n mynd i deallu ac angeni'n gweithio'n ddechrau sy'n meddwl iawn. syThat the do that by doing some scientific and may be not so scientific experiments live on stage. So great. So like any good scientist we've got a hypothesis yeah I've got a hypothesis and he's ours. So I hypothesis reads as we scale then the simple theory is applied to a single team will remain the same across the enterprise. So what are we means by that in. Well let's think about all those who had the hands up how you introduce the adeil into that first team. I bet you got them collaborating with your customers. I bet you understood the capacity of the team so that you could start to understand the flow of work as it came through the team. I bet that you were thinking about how do we get those highest value items out of the door first. As we introduce adeil into our single team, it's all quite simple. We create an environment where the team can become self-empowered, self-organising, self-managed. Very, very simple. So, when we scale in the enterprise, why isn't it just as simple as we do it with one single team? Mike, why don't we try one of these scientific experiments? Let's do an experiment and always safety first. I've got about that. I really want to have an accident. Mess up my lovely shirt. That's right. OK. Just amuse yourselves for a moment while we organise. So, should we introduce some props? Yeah, let's try that. Let's see where we go with this. So, I'd like you to imagine for a moment, I can do myself up. So, I'd like you to imagine for a moment that this here cone represents a delivery team, our single agile team. We'll call this the cone team. Like any good team, they have a backlog. So, this jug represents our backlog of stuff and inside that backlog represented by rice are the features that we hope to pull into the delivery team and release. So, this contains the value features. This rather lovely container here is what is going to capture those built features. So, we'll call this the capturing built features container. That's a brilliant name, right? Thank you very much. Just thought of that. So, Simon, I was wondering if I could have five seconds on our clock please. Yes, you've got five seconds. Do you need a hand? So, the cone team are going to pull some value features and deliver those into our capturing pot. So, on my mark, Simon, if you'd like to start us off. Can we just make sure that Mike here is at this countdown? All right, I want to hear you. Okay, so ready and go. Five, four, three, two, one and stop, Mike please. We've got a bit of an opening problem there. Stop, thank you. It's okay. So, what we can see here just by going single agile team is that our team have delivered some features or built some delivery features. What we've also shown you is I bet if we did this again, there's no way that that team would be able to deliver that entire backlog in five seconds. So, straight away, we're starting to get an understanding of that team's capacity. Now, we have a blockage in our team at the moment. We'll sort that out. Now, if I was to change the word team and say this represents the enterprise, then our theory still remains the same. We start to get an understanding of the capacity of a single team and the flow of that. And why can't we get an understanding of the capacity and flow of the enterprise? So, what we're saying is that if we understand the capacity of a single team, that simple theory remains the same as we scaled in the enterprise. If we understand at a single team how we build and deliver those highest value items first, that simple theory remains the same across the enterprise. If we have that simple theory where we create an environment where a single team can self-manage, self-organise, it's simple. We do that at the enterprise. Thing is, though, time and time again when we start introducing these ideas, we start encountering difficulties and we start encountering issues. So, me and Simon have been spending our, I don't know how many years, working together, running a number of experiments in the enterprise to try and understand why. So, like any good scientist, we look to our colleagues for inspiration and a very happy chap here, Mr Thomas Henry-Uxley. He's very happy. Look at him. Thomas said that the great tragedy of science is the slaying of a beautiful hypothesis by an ugly fact. Well, we've been working and trying to prove this hypothesis for a number of years and we've yet to find an ugly fact that proves this idea. And there's another chap that we took some inspiration from. Another happy one. He looks happy as well, doesn't he? So, the point is this, right? We haven't got the answers. You probably haven't got the answers. But what we do know is that there's lots and lots of questions we need to be asking ourselves to make this a success. Mike, why don't we have a look at what we're trying to prove behind this hypothesis? Let's have a look at that. Ha ha! You see? I came prepared. So, as you can see, no expense spared on our idea. But this drawing, and I'll reveal it all in a moment, is something that we've presented a few occasions. And this is our theory behind scaling agile. So, those that kept their hands up must have an idea about single teams. So, we've got an idea. We've called it project A for a moment. But this could be anything, a big idea. And we work collaboratively with our customers and stakeholders represented by the red people there. And we unpack that and we create a backlog. And we're constantly working iteratively and delivering something into production. Pretty simple. Well, if we scale, it's just more ideas and more teams. And as long as we collaborate with our customers and work closely together, as long as we have a good understanding and constantly refining that backlog of work, it's just a bigger backlog of work. It's pretty simple, right? Same simple. So, let's take a step back. Again, let's just think about that first team. I bet you picked a project which wasn't too risky. I bet the team that you had working on that first agile project, you knew they were going to succeed. You knew that that team knew each other quite well so they could start to collaborate. I bet that you gave them the whole environment where they could start to self-manage themselves. You helped them. So, we actually have everything we need for that one team to be successful. Then what happens? I want some of that, right? I want to do what they're doing because they're bloody successful, right? So, what do we do? We say, let's build more agile teams. Let's spin them up on mass. Is that a great idea? I don't know. Maybe we should run some experiments on that and find out what that feels like. Let's do that, Simon. Why don't we do that? So, let's introduce our first idea which is what we affectionately call, let the right one in. So, our decision and our idea to change the way that we work and we work in an agile way, we're starting to use words like co-location, collaboration, knowledge share, working closely together as a team, all these wonderful things. We put a lot of energy, and as Simon just talked about, we put a lot of energy in setting up that first team and showing that that can work in the organisation that we work in. So, the question is, is why don't we put that energy as we spin these teams up on mass? We've put it into a single team, but when we spin them up, are we really thinking about the team now? Are we really thinking about all the members in all the teams? Or are they just another resource that we can push into another team? Here's an experiment. So, let me introduce you to what we call the balloon team. This is a balloon team and it's a high-performing team in the organisation that we work in. The circle, just before we go on, the circle represents that balloon team's culture. They've nurtured that, they've worked together, and they've worked together for a while, and that now represents the team's culture that they're very proud of. There's a vacancy for that team, and here's a vacancy. We need somebody to join that team, and this is the balloon team's vacancy. Here it is. So, we need somebody to be able to develop in dot balloon. That's an essential part of being part of the balloon team. They need to have five years' experience, because it's quite an intensive role. We need somebody to know what they're doing, hit the ground running. They need to have some understanding of agile, working in an agile way. They need to be able to work in a team, and that's how we collaboratively work. Desire of all, but not essential, is that they should be able to develop in pink dot balloon. So, here's our vacancy. This is what we hope to do, Simon. Have you got any candidates that could potentially join this balloon team? It's funny that you should ask that question, because we have done some interviews, and we've got a couple of candidates on our shortlist. We have. Let me introduce you. Two candidates, all very happy, all very nicely... Pink dot candidate and red dot candidate. Right, so let's go through our vacancy. Dot balloon developers, can they develop in dot balloon? Well, of course they can. Look at them. Okay, good point. Five years' experience. Pink candidates are seven, and the red candidates got six. Brilliant. Agile, any experience in working in agile way? Obviously, and they've told me they're agile on India right now. Agile on India, but you asked them at the interview. You asked them at the interview, and they... Well, they said yes. Work in a team. Did they have the ability to work within a team? Then they said yes to that as well. Fantastic. What about pink dot balloon? Well, look, you're asking another question, that pink dot balloon... So we have someone that ticks all the boxes, and we've asked that. Absolutely, not so much. Well, fantastic. Well, that sounds like... I don't know about you, but Mr Pink seems like the perfect candidate to me. Title. I'll bring it over. Let's bring him over to the team and put him into the team, please. All right, let's see what happens. Oh, thanks. So what we've just done is we've just pushed Mr Pink into that delivery team, and we've now broken that team's culture. So let's try that again. Same candidates, same interview process. But now let's bring the team to the candidates. So you're going to have to come over here, Simon, because it's probably better viewed. So now let's try Mr Pink into that team, and I think you'll notice that as a team member, we're now deciding whether or not Mr Pink will fit. He doesn't. So now let's try Mr Red. Mr Red actually fits into that team, and I'm now putting that candidate into my team, without breaking the team's culture. Marvelous. Marvelous. So what we're trying to demonstrate here is working in this new way isn't just about having a list of skills that you tick, and it's now a resource, I hate the word resource, but it's now what people call a resource that they can just push into a team, and that will tick all of the boxes. One of the best places that I ever worked in, back in the UK, was an organisation that was very proud about the culture that it created, and very proud about how it worked. They recognised the fact that each team has its own culture too. So if anybody joined the organisation, or anybody that was going to join the team, they went through a process, a rigorous process, to ensure that they were the right fit, because we knew that by breaking that culture, we'd potentially disrupt the team from within. So we had a massive HR process, on-site recruiters were involved, and the biggest thing that we did, was we ensured that the teams were the ones that made the final choice. So each candidate would come in, they'd sit and work with the delivery team, they would go to meetings, they potentially might pair with one of the developers, all part of that process to ensure we don't break that team's culture and that we make the right choices. So the questions we ask ourselves, when we start to scale, who's really making the decision on bringing the right one in? Are we thinking about letting that right person in, so that each team is set up for success? Just like we do with a single team, where we create the environment for those, set up that success, we need to do that as we scale in the enterprise. So, you know, in a single team, they're always talking together, they're sharing knowledge, they're sharing ideas. In the enterprise, we've got to do exactly the same. So you just might need to make it a little bit more formal. So you might want to have brown bag sessions, rock-ups where people come and share their knowledge, or book clubs, video clubs, where we talk about things and start to bounce ideas off each other. Another great thing to get that collaboration going is activity-based working. That means that when I come into the office in the morning, I can sit wherever I like, and whoever with I like, to get the work done. So, if we're creating and focusing on creating that environment for our teams, there's a few things, though, that we need to really think about. So, aren't we actually getting the teams to build the right things? Are they really close to their customers? That's a very good question, Simon. So, this is what we affectionately call golf course to cash, because as we all know, all the greatest ideas in an organisation come off that executive golf course. You play a lot of golf, don't you, Mike? Yeah, I'm particularly good. I'm actually really quite rubbish at it, to be honest. Anyway, so we split golf course to cash up into three things, idea, build, and release. So, if we think back to that single team, the idea, build, and release notion is pretty much blurred together. As a single team, as we all know, they have their hands up at the start. We're working already pretty closely with their customer. If I have a really good idea, I know exactly where to take it. I can put it in front of the delivery team that I'm collaborating with, and we can talk about what we can build for the customer and build it. Then we'll release that, short incrementally, short increments, release some value, get some feedback, and the whole process continues. Pretty simple. It is simple. But what happens when we scale? What happens to that idea to done? Because most of the energy we put in is in the build and release phase. I know that's what we do, right? So, we put energy into those great XP practices, like test-driven development, continuous delivery, continuous integration. We put energy into making sure that we can do great scrum practice or CAMBAN. So, what happens is the build and release phase, they start to merge. We've got a very slick way of actually releasing. But getting my idea from that golf course all the way to those teams is still a major issue. Because if I've got an idea, what have I got to do? When I'm working with multiple teams, I've probably got to create a large idea so that I can get my budget approvals. I've got to create business cases. I've got to do some form of funding. I've got to go to steercoes. I've got to do portfolio play. I've got loads and loads of things to do, just to get my idea into those teams. This is what we like to call that organizational idea maze. So, the questions we like to ask ourselves when we scale in the enterprise is... Are we close to our customers? And are we able to quickly put those ideas off the golf course into action? And have we really thought about how the flow of that work gets from the idea to done? And are we always so focused on that build and release? Have we even considered the idea, the organizational idea maze? Have we even thought about changing it? Or are we still working to contractual agreements between idea handing off to build? Generally, we see a clash between the way that we always seem to work in idea and the way that we want to work when we introduce agile and build and release. So, one of the things that we've really learned is we need to really take a holistic view. We want to really make this work in the enterprise and think about idea build release. So, think about golf course to cash. We need to be spending a lot more time in understanding and working within that organizational idea maze. So, we've looked at the questions that come up when we're trying to be close to our customers. Let's have a look at some of the other things where we get hindrance from that organizational idea maze. So, this is what we rather affectionately call from pot to pot. So, one of the big advantages, as we all know, when working in this way is short incremental builds, release into production, feedback, and continue. So, the ability to release early and get that return on investment. Again, pretty simple. Why don't we do another experiment? Do you know what I think that's a really good idea? Now, for this one, I need one volunteer from the audience. So, don't you like to come out? Please don't be shy or I might have to pick on my wife. She won't be very happy. No volunteers? Here we go. Come on up to the stage. Big round of applause for our man here. Come on, what's your name? Rahul. Here he is. Rahul. Rahul, thank you. Nice to meet you. Hi. So, for this experiment, let's just imagine for a moment that we've taken our idea through that organizational idea maze. We've now come up the other end. Typically what we'll see is we'll have some funding, some funding approved for us to spend on our idea. So, have we got any funding? Have we got any funding, Rahul? No, he says, but I'll tell you I've got some coming with me. OK, so, if we can just bring our funding, let's just see how we will push it over here. Fantastic. There we go. All right, we've got a funding pot, Mike. We've got some funding, that's fantastic. And typically what we also see is that at the end of that organizational maze there is some form of scope, some kind of stuff that we're kind of saying that we're going to build and deliver for that funding. So, this team here, the cone team, the purpose of this experiment, this is the scope that we said that we're going to deliver for that funding, which is in the funding pot. In the funding pot? Cool. Have we delivered something already? We have delivered something already, we've delivered something. What we're going to do is we want to build this iteratively, so we're going to use the cone team to build this thing iteratively. And the cost of each iteration is 80,000 Australian dollars. It's quite an expensive team, it's 80,000 Australian dollars. OK, so we have a look in the funding pot, Rahul? Yeah. OK, how much have we got here? 80,000 dollars. 80,000 dollars. So, if we hold that Simon and let her... Oh yeah, we need to put some goggles on. Oh, you've got glasses, you'll be OK. There we are, 80,000 dollars. Go on. So, we've just spent 80,000 dollars on building something. So, we're now going to move into iteration number two. That's another 80,000 dollars that we're going to be building some stuff. 80,000 dollars. Right, so we've just spent 80,000 dollars there. Right, so at the end of iteration number two, we have some value. We've done two iterations and we now have some value that we could potentially release to our customers and get some value return. So, what would you like to do, Rahul? What would you like to do? Would you like to release into production? No. You wouldn't like to release into production? What do you think Rahul should do? Release back into production, our value? No. Get the value back. Yeah. Well done. I'll talk about you in a minute. So, the thing is though, our Cain team, we haven't got a lot of continuous integration, we haven't got a lot of plonkic eresis, so our Cain team, we're going to have to spend some time and energy. Am I on? Yeah. You're going to have to spend some time and energy putting this into production. It's going to cost them an iteration to do that. That's another 80,000 there, is it? It is another 80,000 that we've just spent, but we're going to put that into production. I think that's a fantastic thing. Right, so now we're going to move on to iteration number four. So, iteration number four, which is, believe it or not, another 80,000 dollars. So, now we're going to start with another 90,000. That's lovely. Just spent some more money. We have a blockage in my team at the moment. It didn't happen in rehearsal. Brilliant. What's that you've got on your hand, Simon? Well, this is a bit of value that we've got back. So, we've got some value from that early release that we've done. Fantastic. Now, I'm going to put this in the enterprise value pot. Enterprise value pot. We've got some value returned from that early release. It's a good release. Iteration number five. We're now going to move on to iteration number five. That's what. Another 80,000 bucks. Iteration number five has been done. Brilliant. More value. More value coming back. That's excellent. Lovely. I'll put that in the enterprise value pot. So, we're now starting to prove that our product is returning some value. Right. So, moving on to iteration number six. Iteration number six. Normally. We've got no money. So, we've run out of money. Empty pot. So, the enterprise investment pot or the project investment pot is now empty. But hang on. I mean, we've still got some value here that we need to be building. Okay. Cool. Have we got any money over there? Can we use that? So, we do have some money being returned. Cool. But unfortunately, that's in a different pot. That's actually in the enterprise return pot. It's certainly not in the idea investment pot. So, unfortunately, we can't build this anymore. I can't continue to build this. All right. So, how do we get our hands on that money, Mike? Well, unfortunately, to be able to redo this kind of stuff, I've now got to go back through the organisational idea maze and get my approval to finish building the high value items in this product. Did you fancy that? No, I don't think so, right? So, you're telling me, right? So, we've released a load of value. We've got some money back in our investment. And to actually do anything else, we're going to have to go through that organisational idea maze. The whole says that's a bad idea. Yes. It's saying, why didn't you tell us that in the first place? It's true. Sorry about that. And maybe his answer was right. I don't know. Cheers to our whole. Thank you. Round of applause for our balloon popper. Thank you very much. So, believe it or not, this is actually based on a true event that I experienced. And I was working with a fairly mature team. And we were working closely with our customer. We had some work that we wanted to build and wanted to do. And after two iterations, the team were the ones who basically said, hang on a minute, we've got some really good value here. We've got some stuff that we can put into production and it will make a big difference to our customer experience. Big difference to our front line colleagues. So, why don't we put this into production? Stakeholder actually said no. I'd rather do it all at the end. Thank you very much. Why should I pay? Sorry. Why was that? It's a good question. His response was, why should I pay for two releases? I only want to pay for one. Because the cost of doing those two releases means that there are some features that I might not get built. So, I'd rather just do one release at the end and not worry about the value. So, my response to that is, are we more concerned with maximising the amount of features for the money that we spend? Or are we concerned with maximising the amount of value for the money that we spend? And that's the question we ask ourselves, right? When we're scaling in the enterprise, why aren't we maximising value rather than just maximising the number of features? Why aren't we focused on that? I mean, is it because we've got to negotiate that maze, right? So, once I've negotiated that maze, what am I going to do? I'm going to say, right, I've got my money and I'm going to spend that and deliver everything I can. Imagine if I've got multiple projects doing that. Man, they've got all their money and they're going to spend it on my features, on my features, on my features. So, are we sure that all those teams are working on the highest value items across the enterprise? Another good question, Simon. I always got good questions, mate. So, let's just explain this in a little bit more detail. So, remember this from the start. So, this is our single team and an idea coming through, working closely with our customers, team putting highest value items off the top. Let's look at that a little bit more detail and again, no expense spared in our PowerPoint skills. So, typically what we see when we scale is, these ideas will come through that organisational maze and what we'll do is we'll plug a, we'll form a project team, we'll form a team around a project. Generally what we normally typically do we'll resource up a project. So, we generally have one team, one project, that's how we work. And like any good team, they'll have a backlog and they'll be working closely with their customers and they'll be ordering each of their individual backlogs. A question Simon asked was, how can we be sure that we're delivering the highest value items for our customers right now across the enterprise? So, why don't we take a step back and have a look at this in a little bit more detail. So, if we actually ordered it based on value and based on what the organisation needed to deliver it for its customers right now, you get a very different picture. So, what we're saying is, is if we decouple those teams from projects, they then have the ability to form their own culture. We work closely with our customers and unpack that work and look across the enterprise at value. And we can start again in those teams to pull the highest value items off the top of the list. A bill what's needed for the customer right now and by doing that we'll take a step towards understanding the capacity and flow of the enterprise. Just like our co-team at the start. To do this though, we need to be thinking small. And if we're thinking small across the enterprise, then we can get items out the door just like we do with a single team. And just before I ask the next question, Mike, that we ask ourselves, I'm going to take my goggles off. Can I finish those? So, these are the questions that we really are asking ourselves now, is that, you know, are we really thinking small enough so that we can order items across the whole of the enterprise and we're not just ordering projects? If we're always thinking small, think about what that means to golf course to cash. If we're thinking small, I haven't got to go and get a massive amount of money for my project. I'm only asking for a very small amount. Maybe that organisational idea may as it becomes a bit easier. If we're thinking small, think about what that may mean for your pot to pot. Because now I'm always going to deliver my features, right? Because I've just got a small number. So I'm not really worried about delivering all the features of my project. I'm actually going to maximise the value across the enterprise. And if we're thinking small, all those teams stay together. We don't have to create teams around a big project. So those teams actually start to get their culture, their own identity, and they can let the right one in. Now, having said all that, we're still trying to prove this hypothesis, right? We are. And let's remind you of our hypothesis. As we scale and the simple theories applied to a single team, we'll remain the same across the enterprise. We still, Simon and I, believe, as we mentioned at the start, this hypothesis rings true. But as we found through experimenting within these ideas, that more questions and more issues are continually uncovered as we go on this journey in the enterprise. In fact, you know what? That's the one thing that we have proved beyond all doubt, right? So just in a single team, just as those problems and issues surface, they still surface as we try and do this across the enterprise. So let's leave you with a few questions that you can ask yourselves. Let's ask yourselves what experiments are you going to run to provide the right culture for teams in your organisation? Let the right one in. What experiments are you going to run to ensure that you're working closely with your customers across the enterprise? Are you thinking golf course to cash? And what experiments are you going to run to make sure that you maximise value rather than maximise features? Are you thinking pop to pop? What experiments are you going to run to ensure that you're building the highest value items for your customers across the enterprise? And here's a little bit of final advice. If you want to be successful, before running any of your own experiments, know why you're running them and what hypothesis you're trying to prove. Thank you for experimenting. There's Mike Pollard. Thank you very much. We're here, right? So if you want to come up, you can come up and do whatever.