Mike Burrows
Transcript
Each of you has a very different context. I can't predict until I get to know you what your specific challenges are, what particular obstacles you would most likely to overcome, what would happen if we overcame those obstacles, and what would then happen subsequently
as we start to make progress. So perhaps in the terms of Daniel that I used yesterday, I made an invitation. I give you an invitation to consider what it might be like. For some people, it's a cathartic experience to be able to imagine this.
I worked with a well-known nonprofit, very motivated organization. They're very clear about what their purpose is.
But their working practices didn't actually work very well. And there were people that felt overburdened, people that complained about silo boundaries and all this kind of thing. And suddenly they were given the permission to think about a better way of working. That didn't involve prescribing practices or anything else, but suddenly their eyes are open. They actually asked for more time than I was willing to give them, than I initially gave them for this exercise. They wanted 40 minutes instead of 20 to consider what this could be like and what obstacles they needed to overcome. So powerful stuff. Stuff that many of us take for granted. We've been immersed in Lean and Agile for some time. But here we are with a statement that people can sign up to.
without the training. That's interesting. Where do we normally start? We normally start with telling people what to do, telling people what practices to use, giving people a list of training courses to go on, and so on. So that's kind of giving you a preview of the punchline of this talk. The main talk, I'm actually going to present an idealized 21st century change process. And it actually looks like a delivery process. It's got discovery at the beginning, exploration, mapping, elaboration, and then operation at the end. I mean, some of you who worked in digital projects, for example, might recognize this as kind of the way that you work. In your delivery. Now I'm going to do a lean trick. And the lean trick is to start at the right hand side. Start with what we want to achieve and work backwards. And that's a very good way of checking that the activities before give the activities that are later what they need, rather than just thinking of all the things that we could do and hope that it's going to be valuable somewhere down the line. So we're going to start with operation. And for each of these, we'll focus, we're not going to have time to explore the whole of operation or the whole of these other categories, but we'll look at a modern tool, think about some of the lessons of that modern tool, and in some cases, apply a health warning.
In terms of older ways of thinking. So operation, organizing for clarity. and speed of decision making is the modern lesson here. And I'm going to take a combination of Lean Startup and Kanban here. Many of you will recognize the Venn diagram on the left from Lean Startup. Valuable, feasible, usable. And on the right, I've got a Kanban system, a visualization of a process for delivering things that are valuable, feasible, and usable. What we want to end up with... Is in the adopted column, changes or features, and it applies to both, that are all three of those things. And we want to reject items, whether they're organizational changes, process changes, or product ideas that fail on one of those counts. So here's a simple way of organizing it. We start with the prioritization process, and we ask, what's the most valuable thing that we can do? I use those words advisedly.
20Th century prioritization, stage gate processes, for example. Let's look at this thing on its own merits and decide whether it's a good idea or not. And then without thought to all the other things that we could be doing or our capacity to deliver it, say, yes, that sounds like a fantastic idea. Go away and do it. And then they wonder why all their systems are overburdened with too many projects, people too busy, nothing getting finished, and so on. So we've got to start making some hard choices. And if our idea... is never likely to make it to the top of the pile any time soon. It might just as well go in the bin. Storing it in a backlog doesn't actually really give us any value at all. So let's stick it in the rejected column. Then we negotiate the details of the change with the people that are impacted by it, the people that are going to do the work, the customers of the change, other stakeholders who care about how things are done. And again, we've got two choices. We can either let it advance to the next stage, or we can reject it if we can't come up with a solution that is technically feasible and acceptable to the parties involved. Validated option. The question we're asking here is, will it stick? If the thing's not usable, if the ergonomics aren't right, if this fantastic process idea that's going to improve our quality actually involves several hours more work that nobody wants to do, there's a good chance that it won't stick. So let's try it for a while. Let's see if it actually helps. Let's see if it's comfortable. Let's see if it makes the environment better, as well as delivering the quality benefits that we want.
And if it doesn't, Rejected. Back to the drawing board. Finally, verify performance. Did it deliver the value that we expected when we started this at the beginning? This can be something where you have very explicit criteria for whether it's successful or not that you decide at the beginning. Or it can be that you use your judgment at the end as to whether you want to keep it or whether you want to roll it back to how it was. things were before.
Simple idea.
The point here isn't actually about whether you use that particular Kanban board design, but the idea is your process designed to throw up the right questions at the right time so that you don't overinvest in ideas that are going to fail and instead concentrating on deliver things that are going to succeed. And each time something does fail, each time it turns out not to be usable, each time it turns out not to deliver the benefits that we hoped for, we can ask, did our process make those decisions, make those facts apparent at the right time? And if it didn't, we change our process. So we're learning about our customers, we're learning about our process, learning about our users as we make these experiments. We're also learning about whether our process for delivering these things is optimized for learning. It's a very powerful idea.
I call this reject fast. That's just being very aware that every stage of the process, we are willing and ready to put things in the reject bin. If we want to avoid wasting time on something that's not going to work.
So organize for clarity and speed of decision making. A little bit of Lean Start, a little bit of Kanban. The next one is going to be even more Lean Startup, and then we'll go into some traditional Lean as well. Who's seen this kind of hypothesis template before?
A few of you. So for those of you who have seen it before, I'll share my example I always use, and you feel free to steal it if you haven't. It's my explanation. Who remembers two or three years ago when we were told that Facebook were going to introduce a dislike button? Remember the dislike button? Shock, horror. Facebook's meant to be a happy place. Thumbs up. All of a sudden, thumbs down. Very controversial idea. You can imagine this being the pitch from the product owner or the executive inside Facebook. We believe that if we introduce a dislike button, we'll see more engagement in Facebook. We'll see more likes and dislikes. As a result, people will be encouraged to post more. People will be encouraged to comment more. That means more time in Facebook, more eyeballs seeing adverts, more money for the company. So that's the hypothesis. Simple hypothesis. They begin to test it. They refine their ideas. And after a few iterations, what do we get? We get the reactions feature that we have now. So we have like, dislike, wow, crying face, all those different reactions. I wasn't there at Facebook. But I do know that a wide range of organizations, it was pioneered in the fast-moving internet-based organizations, but I've used this in government.
UK Government Digital has been mentioned a few times at this conference. I've done two six-month stints in UK Government Digital, and it's turned out to be an awesome place to work. And they're doing some amazing things.
And they are very user-focused. Start with needs is like the slogan for government digital services in the UK. And if you can't demonstrate that you're committed to meeting needs, if you can't demonstrate that your solutions are meeting needs, if you're not putting up these kinds of hypotheses and then validating them afterwards, you stand a very real chance of the funding for your project being cut. So this is a strategic commitment to needs. And it's really exciting to see in a world that we all saw as slow and lumbering, the government sector, adopting these kinds of ideas and actually putting many private sector companies to shame in their commitment to users. So that's the basic initial hypothesis.
That's actually an old idea that goes back to the 20th century. Who remembers PDCA and Deming and so on? So we're talking, you know, when Deming's like mid-20th century, the people before him as well, Stewart, for example, The idea of change as an experiment. Here's a 20th century tool, the A3, which is a Toyota idea. If you can't explain your project with an A3, just no more than an A3 sheet of paper, you don't understand it well enough. You don't prove your understanding by the thickness of your documentation. You prove your understanding by being crystal clear. And you develop that understanding. standing, first by writing it down, and then by having your thinking challenged by other people. Great little idea, very efficient tool. We put a slightly 21st century spin on it. We've got our 21st century lean startup style hypothesis.
Assumption dependencies, that's actually very traditional. The definition we have for those is we could have taken them straight out of the PMBOK, for example. Risks, a little bit 21st century, upside risk as well as downside risk. Now, the concept of upside risk is a bit unfamiliar to many people. It was familiar to me, my background in banking.
But this is something you can explain with an example that anyone from the UK will recognize. Maybe you'll recognize this in France as well. When you see an advert for an investment in the UK, there's some small print at the bottom. The values of investments can go down as well as up. So that's the consumer warning on an investment. You can turn that around. The value of investments can go up as well as down. So risk is actually about uncertainty. And uncertainty can go both ways. Things can turn out worse than we expected. Things can turn out better than we expected. And if we start to think about how they might be better than we expected, we can keep our eyes open. We can think about watering the green shoots, transplanting good ideas from one place to another, and so on. So that's why we look at... Upside risk as well as downside risk. Pilot experiments. So a pilot experiment is just a way of testing our assumptions or meeting a dependency or addressing a risk in a way that helps us make progress and is faster, safer, cheaper than the experiment as a whole. Lean Startup, in a way, is making progress by testing our assumptions, and we're doing it relentlessly. We're doing it all the time. And these pilot experiments are a way of breaking down the big experiment, the big assumption, and breaking those down into manageable pieces that we can test very quickly.
The next box is people. Lots of technical stuff, you know, risks, assumptions, hypotheses, all sounds very exciting. But forget that it's about people and you are doomed. So when we do this in workshops, if it's a public workshop, people write the general generic role names of people, of the kinds of people they should talk to. If I do this in a private workshop, I ask them to put actual names to those roles. These are people they are going to talk to.
Think about who the veto holders are in the change. Who will actually stop you? Then you have to make a choice. Is it better to ask for permission or to seek forgiveness? In the words of Admiral Grace Hopper.
Lastly, insights. Now, insights are where your learning gets written down afterwards. There's a little trick for you. If you're doing an experiment, when you've designed your experiment, Think about the insights you would like to capture. Just imagine being at the end of the experiments and all these great learnings, all these great insights you've got written down.
Then ask yourself, is my experiment actually capable of delivering those insights?
Nine times out of ten, if not more, when I've asked that question, people have then found a gap in their experiment design. So it's a nice little trick for you. It only takes a minute or two. It might save you actually quite a lot of time and money. So it's frame and refine changes as experiments. Now there's a 20th century trap. And that's selling your favorite practice as the best practice.
And actually, what practice works in one context or with one kind of problem doesn't necessarily work in a different context or with a different kind of problem. Some problems you can express the problem on a post-it note. And everyone in the room will know exactly what to do. Now, in that situation, do you tell somebody to go and write a project plan? So it's a nice little trick for you. It only takes a minute or two. It might save you actually quite a lot of time and money. So that's frame and refine changes as experiments. Now there's a 20th century trap, and that's selling your favorite practice as the best practice.
And actually, what practice works in one context or with one kind of problem doesn't necessarily work in a different context or with a different kind of problem. Some problems, you can express the problem on a post-it note. And everyone in the room will know exactly what to do. Now, in that situation, do you tell somebody to go and write a project plan? Do you tell somebody to write an A3?
You're actually burdening that idea with bureaucracy by doing that. So if something is, you know, if you can quickly get agreement on it, and the culture is right, you can just do it. There is a time for linear plans, doing some analysis, coming up with a plan, executing it diligently, and so on. There are things that are solved problems, and to reinvent the wheel would be a mistake.
Some examples of that, and you can probably think of good examples of your own, where We've iterated our way to a beautiful product. With each iteration, it's got more refined, more polished. And then it's launched. And on the day it's launched, it turns out you don't have the capacity rights or the security is wrong. Or there are legal problems. And suddenly the project, which looked wonderful, is suddenly a disaster the day it goes live. There is no excuse for not doing the due diligence on things that are solved problems. There is definitely a place for experimentation. A good test is if you ask 10 different experts how you would do it, You would get 20 different answers. And not only that, none of the answers would take you the whole way to the solution. Or the whole way to the outcome that you want. The fact that you don't get the whole outcome in one go is the clue that you're going to have to iterate. You're going to have to experiment. You're going to get closer and closer to your outcome, but you're not going to achieve it in one go. So there's a 20th century hangover. Beware of consultants selling you one tool and telling you that it will solve all your problems. Very unlikely to be true.
So one tool we use to help get people to get their head around this, because this is a bit radical for some organizations, some people, we use, I call it the exercise that dare not speak its name, because actually telling people what you're doing spoils the exercise. But this is the Kenevan four points exercise. Many of you have played it or at least be familiar with the Kenevan model behind it. But we're getting people... with their own outcomes, with things that they themselves would like to achieve, not things that I have given them. Things that they themselves would like to achieve, they're acknowledging that some of it is obvious.
Just delegate it to someone, they'll know what to do, it'll get done. Delegate someone to analyse, come up with a plan, and execute it, you could be pretty sure of getting the right outcome. Things we're going to have to iterate on, do some different experiments and so on. Areas where we might, our best hope in the short term is symptomatic fixes until we understand what's going on, stem the fire, put out the bleeding, and so on. And you start to reveal organizations'comfort zones when you do this exercise.
Some organizations think that everything is a plan.
One financial organization I worked with, they would outsource the development of new products, and they would spend a lot of money on developing a new product before they had tested whether anyone would ever buy it.
That's a very expensive way of doing product development.
As I mentioned before, you can iterate and polish a perfect product that falls flat on its face when you go live. But also, some of us who are most comfortable in the complex zone, most comfortable with experimentation, how much effort do we waste? By reinventing the wheel. Or how much effort do we waste taking an iterative approach on something that's already a solved problem? So it gets very expensive when you start to use an inappropriate approach.
Next lesson, and possibly the most important lesson, visualize outcomes, not solutions. I call this a transformation map. It's essentially a story map.
The stickies here, instead of being user stories, they are outcomes. That's actually quite a good fit. What's the last part of a user story? It's the so that outcome. So if the user story is a placeholder for a conversation, these outcomes are placeholders for placeholders for conversations. But conversations about change to the organization. We've got narrative flow across the top. We've got prioritization going up. So all the classic features of story mapping going on. But the actual tool involved isn't the important bit. Now, this is the important bit. We could have used impact maps, X matrices, whatever your favorite plan for organizing outcomes might be. Everything after this and everything we've talked about so far is the how.
But we fall into our own trap here. We in IT, we're great at delivering solutions. We're great at coming up with requirements, ticking them off, chucking the thing over the wall, and assuming that once all our requirements are ticked off, that needs will be met. And very often we don't check afterwards. And it's one of the reasons why there are so many mediocre systems out there. These are systems that check off their requirements but don't meet needs.
In a similar vein, we sometimes think that every time we solve a problem, we've achieved a meaningful outcome.
We just get so used to patting ourselves on the back for the requirement delivered or the problem solved, we forget that we haven't actually achieved anything for the customer.
When we're talking about changing organizations, this is just detail. We know how to do most of this stuff. There's a whole range of frameworks out there with different techniques that you can use. We might need to innovate a solution from time to time, but we know how to do that. We're smart people. Our problem is that we haven't agreed on the outcomes that we want to achieve. If you've got agreements and outcomes,
Everything else is details. There's one thing you take away from the talk.
Just watching Daniel trip over the camera.
When you've got agreement and outcomes, everything else is details. The question is, how do we agree on outcomes? So I'm going to show you now some different tools that we use to do that. And you're going to experience some of them if we have the time. I'm going to check. Yes, we do.
So agree on outcomes, then generatively. Generatively is just a posh way of saying, I'm going to give you a structure that's going to encourage you to generate ideas, in this case, generate outcomes that I haven't previously thought about. And it's just a great way of very quickly generating the kind of detail that we want. And the tool we use is a game. It's called 15-Minute Photo, or One Element is a game. And this is open sourced. If you go to agendashift.com slash resources, you can download PDF of the cue card. It's a cue card that holds these questions. And a deck for facilitators to use when they're playing the game. These are clean questions. You saw a couple of these at the beginning. What would you like to have happen? Then what happens? And so on.
And we play this in the role of, we have people in the roles of coach and client, or the coachee. A scribe writing outcomes down, and an observer making sure the process is working, that people feel safe, and so on. Now, the clever thing about these... questions, if you stick to them, they force you or they prevent you from judging, making assumptions and so on. You ask a question to which you don't know the answer. It's encouraging curiosity, you could say.
We asked, what would you like to have happen about an obstacle? We'll get an outcome. If we ask them what happens about an outcome, we'll get another outcome. We can ask them what happens again and get yet another outcome. And very quickly, we're generating a whole landscape of them. And we can dig into them with some of the other kind of questions. I've got a very abstract outcome, collaboration, for example. I will say, is there anything else about collaboration? Is there anything else about, sorry, what kind of collaboration? What kind of collaboration at a distance, for example, to go back to an outcome we had over there? Second tool is an assessment tool. Now, I'm not going to ask you to do an assessment. I'm not going to ask you to give yourself a score. On these prompts. But I'm going to give you a minute, a minute and a half actually. People sometimes ask me for more time. I'm going to give a minute and a half
to choose just one prompt, one of these six prompts.
I'm not even going to tell you how to choose one of those six prompts. I just want you to choose one of them.
One minute to go.
Right, I'm stopping the clock there. If you haven't already chose one, chose one at random or just choose the first one. Make it nice and simple. Right, now with your neighbour,
What's that like? So if this prompt, which is actually an outcome, as you can see, is realized in full, what's that like? And what's different compared to now? So I'll give you a minute to think about that, to discuss that with your neighbor.
Half a minute.
Right, I'm going to stop it there. Who would like to share which prompts they chose and would like to say something about what that's like or what it would be like?
You chose the sixth one, so I'll read it out. Yeah, so together we strive to meet customer needs, improve our delivery systems, and develop new capabilities. In all three pursuits, we are appropriately recognized, supported, and rewarded. Okay, so what would that be like?
It feels good. Okay. How would that be different to how things are now?
Better. Okay.
There'd be a new set of rules in place because it says we are appropriately recognized, supported, and rewarded, which is almost never true.
So if you didn't hear that, and for the sake of the recording, so Daniel's saying there'll be a new set of rules in place. Because it's very rarely explicitly the way things work in most organizations. So that's great. Right, so you probably can guess what's coming now. So now another minute with your neighbours, what obstacles are in your way to the realisation of that prompt that you imagined?
Right, I'll stop it there. So who would like to share an obstacle to whichever prompt they chose?
Somebody like to share an obstacle?
No? Oh, yes.
Organizational structure, and that's an obstacle to what?
Which prompt? Right, I'll stop it there. So who would like to share an obstacle to whichever prompt they chose?
Somebody like to share an obstacle?
No? Oh, yes.
Organizational structure, and that's an obstacle to what? Which prompt?
All of them, Daniel says. All of them. Fair enough. Right, so another minute on what would you like to have happen?
I'll be easy on you next time. I'll just ask you for the outcome that you arrive at.
So this is relative to the obstacle that you identified.
Who would like to share an outcome? Just put a hand up.
One more question and then I'll ask again. So next question, then what happens? So you've got your obstacle, you've thought about the outcome that's hiding behind that obstacle. Now, then what happens? What's that now enabling?
Right, I'll stop it there. Who would like to share one outcome? I'm not going to ask you how you arrived at it. Just imagine that you wrote an outcome down on a sticky note. What would you write down?
Quick hand up from somebody.
Before I pick on Daniel.
Pick on Daniel.
All our competitors want to work for us and with us.
Oh, that's excellent. All our competitors want to work for us and with us. I'm not going to ask Daniel how he got to that. But I'm sure you understand that that's an outcome I couldn't have predicted.
From the way I set up the exercise. Each of you will come up with outcomes that I couldn't have predicted. This is a generative process. This is a process that encourages creativity, honest reflection on what the obstacles are, and then imagination on what outcomes might be hiding behind those obstacles, and further imagination on what might then be created in the longer term. In the longer version of the exercise, we'll spend just 15 minutes, maybe 20 minutes on this. And with the input of a list of obstacles, we can generate 20, 30, 40 outcomes. That's a wall full of sticky notes with very little effort, very little time. So it's a very powerful little exercise.
Right, lastly, discovery. Discovery is about painting a picture about where we'd like to get to. I'm just going to drill down into that a little bit. Discovery is about needs, unmet needs. Some of the talks this week have talked about understanding what unmet needs we have with our customers or in our organizations and starting to think about how we bridge the gap.
Where are the opportunities for change?
Change is much more likely to be successful if you change a part of the system that wants to be changed. Has a problem it wants solved, has an outcome it wants to achieve, and so on. When I say a system, I'm talking, of course, about the people in the system, willing people in the system wanting change.
I'll also talk about ambition as well.
One of the 20th century hangovers is an apparent dichotomy between top-down and bottom-up change.
Top-down change comes from the guy at the top, and it's imposed on us.
But it's imposed on us, or the justification for that is the vision of the leader, this amazing outcome that we're going to achieve, possibly a hubristic vision. But the vision of the leader is the impetus for change. Now, understandably... We react against that. No one likes to have change imposed on them. It causes all sorts of negative consequences, as Daniel spoke about yesterday. So an understandable reaction to that is to think that change should always be bottom-up. The trouble with bottom-up change is it's very hard to sustain. Unless the organization has mechanisms in place that help to sustain it. And many of us will recognize this problem. Who's seen retrospectives happening religiously every two weeks for the first few sprints for a project? Then they become monthly. Then they become quarterly. And then if they have them at all, they achieve nothing meaningful. They're just a chance to get the team together. Who's seen that? Yeah. Some of you have seen that.
Whether you call it inspect and adapt, Kaizen, continuous, improvements. These are wonderful things.
But they don't happen on their own. They need to be sustained. They need to be energized. You need to have an organization that wants it to happen, wills it to happen, expects it to happen. And we instead make change. We make improvements. We make continuous improvement, Kaizen, kind of like a hobby. For people to do that's not real work, and that's something that we need to change. Now, the way to resolve the dichotomy between top-down and bottom-up is to start getting agreement, agreement on outcomes. And that doesn't come from the bottom or come from the top. It comes from getting the right people into the room. Getting lots of people into the room. And using these generative tools to themselves generate the things they want to achieve, the outcomes they want to achieve. Some of those things they want to achieve will be hard.
They're ambitious things, aspirational things.
But if you've got broad agreements that we want to go after this hard thing, that's a great thing to have at the beginning of your process. So the tools that we use, you've seen one of them already on the right, the True North exercise. So this is my version or my attempt at a lean, agile True North without mentioning lean, without mentioning agile. Describe where it is we could get to if we tried hard. hard enough, hadn't had enough time to do it.
Toyota has a true north that's taken them perhaps 70 years to pursue, and they'll need another 70 years before they still won't reach there. But it's great to have an ambitious ambition to strive towards. The first exercise is very simple. It's one of those time travel exercises. You imagine yourself a few months in the future celebrating some spectacular success. You've overachieved as a team. You've overachieved as an organization. And then you just capture the who, what, when, where, and why. Of that celebration. And in doing so, you're actually exploring the business context that you're operating in. You're understanding what needs to be done in terms of what needs to be delivered, for example. You get a feel for who's involved, not just the teams, but their supporting teams, suppliers, customers, other stakeholders, and so on. Sometimes people will include their families. In the celebration.
You know, if my company was going to have a celebration, it would be my wife and I in the quiet corner of a restaurant. You know, I'm self-employed. When I worked at UBS, my department would hire a nightclub. You know, that's the kind of size of venue, a large nightclub. That's how big a venue we would need. To celebrate together. For the whole company to celebrate, we would need to hire Wembley Stadium. If we were going to celebrate with our families, and I know that our families sometimes bear a lot of pain when we're struggling through our work, what kind of venue would we need? We'd be hiring a national park or something.
We've got these challenges to, you know, this challenging work to achieve, these challenging outcomes to achieve, a time of struggle in front of us. And I give people two choices then.
They can work 20-hour days. They can live on pizza, heroic quantities of black coffee. They can sleep under their desk.
Or, and it's in many ways the more radical option, they can find a way for everyone to work at their best or to be able to work at their best.
Right conversations, needs met, and so on. And that's like the setup for the rest of the day. So they're buying into... That true north, that expression of lean and agile outcomes as a possible way of achieving what they already know they need to achieve.
Those two exercises don't do the whole work of the day, but they do set things up in a very positive way without necessarily needing to explain what any of these concepts are. It's something that people with a background in technology, a background in Agile can relate to. It's a people that from a... a non-profit, non-technology world can come and engage with too. The two simple but powerful exercises. What you've seen is what I call the agenda shift process, this discovery to operations process. We went through it backwards. You can't read the text, but a number of bodies of knowledge acknowledged on this slide. Lean, Lean Startup, Kanban, Scrum. Kenevan, clean language, and so on. I took, obviously, from SAFE, I took the need for a poster as being essential to any framework.
The outcome is so outcome-centric, outcome-oriented. Everything I've highlighted in what's meant to be yellow, but not come out on the projector, is an outcome of some sort.
So here's the punchline. How should we be introducing Agile into organizations? Should it be through the project, or should it be through continuous transformation? So the 20th century change projects, you've all been on one. You've all at least been at the receiving end of one. Someone states a business case that justifies the solution they've already chosen. You endure a long and painful implementation, and then you live with the consequences. The pain that's left over, the debt of missed expectations. And the dawning realization that in all these months, or years that you've been pursuing this project, the rest of the world has already moved on, and you've got to go through this pain all over again.
Or instead, a process that's based on needs and outcomes, continuously discovering needs, getting agreement on outcomes, making the agenda for change visible through a process of agreement, Managing our options, testing our assumptions. Remember that lean startup slide we talked about. That organizing for clarity, speed, and mutual accountability. When I ask someone to do something, I'm also taking responsibility for their capability to do it. The organization supports not just delivery, but change to the organization and so on. And it starts to become built into the design of the organization that we will continue to evolve, continue to pursue our long-term cultural objectives as well as our delivery objectives. That's the main part of the talk. And as I mentioned, there are some resources you can download. I've open sourced a number of tools. The A3 template that you saw, the game is open source. Many of you have played FeatureBan here or at other conferences or at meetups. That's available from the same place. There's a lean startup version of FeatureBan called ChangeBan, which I haven't yet tested, but I've already released, hoping that someone else will test it. before I do. So a number of resources like that. There's a recommended reading list, which actually consists of all the books that I referenced in the new Agenda Shift book, which is available on LeanPub. There's LinkedIn groups and Slack groups. The LinkedIn group's up to nearly 900 people. The Slack group's up approaching 400. And been a great place. Quite, you know, very constructive conversations in there. And lastly, for access to the workshop materials, we have the partner program. I think that was my last slide. Do I have time for questions? I've put my phone in the wrong pocket.