Claudio Perrone
Transcript
Thanks for being here. Not that you had a lot of options. You're kind of forced, aren't you? I love options. But anyways, my name is Claudio, Claudio Perone, as you can see there. I'm Italian, but for the last 15 years I've been living in Ireland, and I'm not quite Irish assimilated yet, but if you see kind of a mix of accents, that's the problem. So anyways, like every single person in this room, I have some superpower. And one of them is that I can draw. So you'll stop asking, you know, but did he actually draw that? Yes.
Yeah, I like storytelling, I like drawing. And I've been involved in building essentially this idea, and I would like to share it with you. So let's start. So we have Houston. Let's see. Houston, we have a problem. What's the problem? The problem is, as Jack Welsh put it, if the rate of change on the outside exceeds the rate of change on the inside, do you know that?
Yeah, the end is near. Right? And unfortunately what I see though is that sadly companies, they go through a lot of change but they don't change anything. They stay the same. Right? So it starts from the very top. This is the organizational chart. I think some of you will relate to that. I actually call it the blame flow. Starts from the very top. You have God. Then you have God. The rule makers, you have the controllers, you have the enforcers. Who's left? There we go, yeah? The losers.
Are you a loser? There we go, right? So, fair enough. But actually, you know, the thing is, like, I actually think that every single person there, they're victims. They're all losers in a way, right? They're victims of a system. This is what we learn at school. You go to management school, this is what you learn. You have to tell people what to do. You have to have everything figured out, right? I don't know if you have the apprentice here. There's a program in Ireland, in the US, in the UK, where essentially there is a, it's a reality show, right? And you have a big boss. You don't have it here, right? You don't. So the big boss, essentially very command and control, really autocratic. Every single week, there's people fighting for the position of become the apprentice. And the thing is, like, every single week, somebody will be fired, right? You're fired, you know? For dramatic purposes, of course, the program kind of highlights all of this. And it highlights this mentality as well of scarcity mentality. For me to become the apprentice, guys, sorry, you have to lose. So there's only so much space as opposed to abundance. There's space for everything. So anyways, organizations change nothing. They just reshuffle. This is my observation. At least a lot of them. Is that something maybe in France you don't have? You're all great organizations, yeah? No command and control, no, I've never heard. Okay, cool. So meanwhile, here's the problem that technology and society are evolving faster than most company abilities to adopt. Essentially, it's changing much, much faster than anybody. Okay, so let me give you some examples. These are literally on top of my head. You know, you think you're doing what you're doing and then you have turbulence on the outside, right? Think about what happens on the outside. We have new technology discoveries all the time, regulations, new regulations, new technology developments, new trends. Global competition, increasing business and consumer sophistication. Yeah? Do you believe me? I mean, I was in Spotify just last week. And that's real. You know, you can see them like growing, learning, whatever. But, you know, it's tough out there. Yeah, you can see how the scenery can evolve really, really quickly. Okay, so this though makes me wonder, how can organizations build fast, learn faster, and thrive in the current market space? Yeah, build fast, learn fast, thrive. How can we do this?
So you see, the thing is like, we want to improve, Who doesn't want to improve? Some people don't want to improve. That's kind of...
Okay, that's my assumption, right? So some of us want to improve, but improvement without change is impossible. This is hardly quotable, really. I mean, it's... It's self-evident, right? You want to improve, but if you're not prepared to change, you can't improve.
Unfortunately, what happens here is that when we think about change, we think about change as big, slow, and scary. It's Godzilla, right? So we think about these big programs, big transformations, right? There's always an end somewhere, right? All that kind of stuff. And so very often we don't change in the end, right? Because it's too big. We really perceive that as huge, and very often it is. And so I started actually thinking, but what if we could make it instead infinitely small?
Right? How small? Well, what if we learned actually to evolve fast, almost as fast as a virus?
Like viruses, microorganisms in general, I learned some of them, like they evolve, they have a new generation every 15 minutes. They're damn resilient. You know what I mean? Like you try any drug after a while, generation after generation, a lot of it is mutation, right? It's not necessarily improvement, it's change. But some of it will bring to a level of evolution that actually will make and build that kind of resilience, by design essentially. That's an interesting thought, right? So these guys are there saying, seriously? Can we really do that? And so here's a mad thought. This can't possibly work, right? So principle number one in a method that I call Papacon Flow. If change is hard, make it continuous.
Okay? So think about this. Think about who is the developer here?
Shame on you. No, I'm just kidding. Who's not a developer? Shame on you. All right. The thing is, right, if we talk about continuous integration, you remember how integration was in the old days? I'm old enough, I guess. Like, we used to build, right, for six months, a year, big projects. And then at the end, we would integrate. And that usually was a bloodbath. Because effectively, we were free for months and months to introduce all our bugs. Then we integrate all the modules together. Bugs intersect with other bugs. I mean, it's just a disaster. And then you try to keep fixing stuff and you do triages and whatever to prioritize all these problems and whatever. And then somebody said, you know what, if it's so hard, why don't we integrate a little bit more often? Every quarter? Every month? So we had monthly builds. And then how about, oh, these monthly builds, it's not too bad because we don't have time to introduce many bugs, right? So how about we integrate every week? And so we started having weekly builds. How about we integrate every night, nightly builds? And now we have continuous builds, continuous deployments. So think about that. Could we actually do something similar? We change. Why don't we do that? Some of you, our developers, will probably think it's self-evident. If it's hard, let's do that more often.
And when I started actually thinking about this principle here, what I had in mind was, You know, extreme programming, can't back. Had this kind of idea of the knob going to 10, so that's it, right? Can't back. Then of course, because really that's what I was thinking, was actually if I pull the knob to 10, maximum volume, what's going to happen there? And then of course somebody said, oh, you're not a fan of spinal tap, are you?
Yeah, there you go. So, yes.
Spinal tap. And then I said, you know what? F this. I can do 12. Let's do 12. That's the parkour flow level, all right? Just to play with things. So the thing is like, trying to re-brain, the human brain is very difficult to rewire it. It's very difficult. Because otherwise I could live right now. That's it. That's all you need to know. That's the principle. Just follow that principle. And unfortunately it's hard to change in that sense. And so there's no point of actually saying, guys, you should continuously change. That's not enough. It's like change culture. Or I like this, become a servant leader. We tell things to people, but we don't give them any mean, I guess, to get there. Any feasible mean. So how about, so the better option there is to act on the system, I believe. That is the environment in which decisions are made. Yeah, I think there's been references before in terms of systems. Not all problems are the same, and a lot of these problems are actually an outcome of the systems, of sometimes the processes, the environment, whatever produces that. that kind of outcome, right? So rather than just fix the issue, you fix on something that produces that. It's like to say rather than changing culture, maybe you add on some procedures or some activities that let the, or you change the environment in a way that let the particular culture emerge. I believe this is the same with happiness, by the way.
Can you tackle happiness by tackling it directly? It's totally debatable, of course, but I think we can do that in different ways. So the question is how?
And so let me tell you a story again, which is a while ago, I worked with a team who had not deployed software in months. And that was a big problem for that company. This project actually was really, really struggling. And so with the motto, Soft on people and hard on systems, which is essentially a Toyota motto. You know, if you understand that a lot of our problems are not because of people, are because of where we are plugged in, let's change the plug, right? Let's change the environment. So to me, it's a no-brainer. You know, you don't blame people. You blame how we're working and maybe modify how we're working. So that was our motto, of course. We built it in. So anyways, we use the common method, right? So here is how we are creating value for the customer or whatever. And, you know, there's a lot of observations that you make from observing these boards.
But the common board essentially capture what we call in Lean typically value stream. How you create value from concept to cash. But that to me in a way, the board at least, only reflects the outcome of our thinking. It's not the thinking. Yeah, there is a story of a It's an urban legend, actually, never happened. But let's pretend, right? I didn't tell you. So some journalists went to a Toyota plant and interviewed the manager in Toyota, and they said, why do you allow all your competitors to come to your plants and copy all your tools, you know, like value stream mapping, Kanban, 5S, you know, whatever? And the manager said, what they need to see is not visible.
When we go there and we copy Kanban, or at least a board like this, what we copy is the outcome of the thinking. That's not the thinking. In Toyota, they had problems, and Kanban is one of the countermeasures that they used to address some of the problems. Really clever countermeasure. So what do you want to do? Do you want to copy the snapshot of yesterday's thinking of somebody else, or do you want to understand the thinking? Now, of course, when I talk about Kanban from the physical side is one thing. When we talk about Kanban as, say, the Kanban method, we are talking essentially about a very different thing. There's a lot of thinking behind, right? So we make observations. Our goal, perhaps, is to improve flow, operational excellence from that point of view. And so we use Kanban and all the various principles and whatever to... To go there and improve that, okay? But when I see a command board like this, to me it's capturing the value stream, okay?
So you see, I like to quote myself. I'm very quotable.
I do that all the time.
It's not what you do, but rather what you learn by doing it that matters. Okay, so think about this. It's not just what you do, it's what you learn by doing it that matters. So, our real secret?
Was this kind of rapid stream of traceable change experiments. I'll go through this relatively quickly, we will revisit it, don't worry. But essentially we went through steps. How do we solve this? How do we run experiments and whatever? So it starts from problems and observations.
which leads to options. Then we have possible experiments to explore those options. Then we have committed, we commit to certain options. We say, okay, from a backlog of possible experiments, which one are we going to do now? Ongoing review next. The beginning of each single word in its step happens to make the word popcorn, hence the name Popcorn Flow.
Now, this is the steps. Remember, I introduced the principle as well. So there's principles and actions and practices. If all you learn is the practice, you're a slave of the practice. If you understand the principles, you're free to choose whatever works for you. So I expect this to evolve over time. Anyway, popcorn flow. So let's try it. So what we did was we created a parallel board. Okay, so the parallel board and essentially what is capturing here is what I call a learning stream. So we had the value stream, now we have the learning stream. The value stream is how we make money. Yeah, how we create value and the learning stream is what we learn as we do this work. Okay, so that's the learning that we are going to capture through this kind of experimentation, learning, observations and whatever. So we created a parallel board, an extra board. And so let's visit it. So it starts with problems and observations. Okay, so what could be a problem? There's many problems. Who doesn't have problems? Okay, cool. Some people are... Really problem-free. I see Cyril there. Must be an awesome... It is actually an awesome company. Very good. Anyway.
And so let's start with the problem. I may actually come to a team, for example, and say, as I said in the past, or some members could actually say, the quality of our code sucks. Now, as you see, it's actually, you know what, it's a very opinionated opinion, as I call it.
It's not really a problem. What it is, is my opinion that this is a problem, that others agree that it is a problem, and that they want to do something about it. So what could be a problem? There's many problems. Who doesn't have problems? Okay, cool. Some people are really problem-free. I see Cyril there. Must be an awesome... It is actually an awesome company. Very good. Anyway, so let's start with the problem. I may actually come to a team, for example, and say, as I said in the past, or some members could actually say, the quality of our code sucks. Now, as you see, it's actually, you know what, is a very opinionated opinion, as I call it.
It's not really a problem. What it is, is my opinion that this is a problem, that others agree that it is a problem, and that they want to do something about it. So I'm putting my name there. Essentially, it's me, because I'm entitled to my own opinion. You see that the problem is our enemy is inertia. So inertia is the tendency of do nothing or remain unchanged. When we think about big change, it's so big that we never change. But when we start to say, so the problem is inertia. People don't change. Companies don't change. Teams don't change. We talk about change resistance. Of course, if you look about this kind of big change, there's a lot of resistance. How about we start talking about reaction maybe? Reaction to change? So if we make it small, maybe it could work. You know? So, but anyways, the point being is inertia is our enemy. And so I'm happy to make progress even with imperfect information. So as a consequence, principle number two.
is entitled to their own opinion, including myself, but a shared opinion is a fact. Essentially what I'm saying is, you know, the code sucks. And guys, if you all agree, let's treat it as a fact. We might be wrong or whatever, but let's treat it as such. Otherwise, what happens is we spend a lot of time in analysis, this and that and whatever. I'm just, as they say, probing the disposition of the system, if you're into complexity or whatever, right? We have a complex adaptive system. It's our team. We don't know how people react. It's territory of extreme uncertainty. So what I'm saying is, my opinion is that. Do you guys agree? Yes, we all get the agreement. So if that is the case, and that's why it's a principle, because it's a first-class citizen, is opinions, like subjective understanding. So that's my ticket, the one I put on the board. You see, I had my avatar. What I do now is I just cross it, because we all agree, or I just take it off. And from now on, we'll treat it as a fact. I'm giving myself permission to be wrong. Maybe not for this, for other things. But the thing is, even if you're wrong, we will experiment and eventually converge to something that might be right. But I'm giving myself permission to be wrong there. But we're all wrong, at least here, as a team. So here's there. And then I use shared observations.
Yeah, and problems and observations to create an illicit option. So the first thing I would say is, guys, in the team, I elicit first, ask first, and then I propose. I use my models, experience, and options to maybe introduce something that people may not have thought about. So in this case, the quality of our code sucks. Any ideas? How can we address it? What options would we have? Ideas? Developers here? Okay, test-driven development, code review, you know, that kind of stuff, right? So these are typical things you will think. And maybe a third one is, I don't know, pair programming. Yeah? So there we go. Typically, you have the team lead that says, from now on, we're going to do pair programming until death will separate us. What do you think? That's resistance to change, right? You would expect that. But I think it's more a reflection of how stupid we are on introducing change with people. You know what I mean? So in this case, instead, what we're saying is, you know what? Can we explore one or more of these options? How can we explore them? We explore them with actions or experiments, actually. But in this case, at this stage, it's kind of not a fully dressed experiment. Perhaps, you know, we don't know, as a team, we don't know much about test-driven development. Let's do a research. Books that we may read. Or maybe I'll read a book. I'll take that. And another one could be, how about we pair program, but only for three days? In fact, I like to run a real experiment. Yeah, Cyril was lying before, so actually he's got this problem here. And so let's make an experiment. Yeah, I know you're not too sure about pair programming, may or may not. not work, you know. But you know what? Let's explore it. What do you have to lose? It's only three days. Yeah, but let's make it an experiment. So the experiment has got this action, it's got the reason, which is the problem why we're doing it, and we all agree with that, by the way. We have that problem. And the expectation then, because it's an expectation, is that, Cyril, how about... Here's the expectation I would write. I like it, you like it, our perception is that the code at the end of the three days will be better, and that we want to continue moving forward to do that. Would you agree to do that? It's only three days, but you have to move. I promise, it may or may not work, but at the end of the three days, we will review it. I never say we roll back. There's reasons why, because sometimes it's not an option to roll back. We are different. We change with the system, right? We co-evolve, it turns out. So my understanding of what would happen may change as I do this experiment, right? And his perception as well will change. But the thing is, rolling back is only one option. There's a number of other options we may consider once we get to the end of the three days. In any case, that's the action. So let's write the experiment. Experiments that we commit to pursue have action, reason, expectation, and review date. Probably more than expectation, I should call it anticipation. This is what I anticipate will happen, okay? Because sometimes expectation seems like this is absolutely what will happen. I think this is what will happen. So let's start programming. Why? Code quality sucks, the expectation. Our perception is the code is better. You see there's a lot of qualitative stuff, but I can measure it. I can actually ask Cyril, what do you think? Did it work?
Okay, so let's take some real examples from real teams. I just reward it simply for the slide, but that's the core of the experiment. Like in this case, for example, is fix as you go. I know David Anderson was talking about triage before. Like in this case, their problem was, you know, we're doing triages, but there's too much bureaucracy for small bugs. And the way it worked was, they had this team, new people came in in the team. New people more aggressive, old team more conservative. You know what I mean? You know, that kind of mindset of, if it works, don't touch it. Yes, but it's called bug because it doesn't work. You know, that kind of stuff, right? So you can see there are two different schools of thought. What the guys were saying was, look, here's what we propose. If we see a bug, let's just fix it. Let's not go through all this kind of thing. If we're creating a feature, we find a bug, let's just go for it. And this could have gone on and on in endless discussions because it's philosophical. What they ended up doing was, how about we experiment with that? Let's do that for a short amount of time. Two, three weeks, whatever. Yeah, and here's the expectation. And so they did. Okay, because it was a short experiment. Relatively speaking, it was a short experiment. And now let's fast forward a few weeks later.
Here's the next experiment. This is the same team, okay? So they actually started pairing on just-in-time analysis. You see, they found that it was painful to do those kind of spring planning and all that kind of stuff. And they said, you know what? Our product owner is actually there all the time. We may just as well ask when we are available, when we have capacity to work, just in time, right? How about we experiment with that? And that's exactly what they did. Now, can you imagine if you're in a conservative team? To do that straight away? Possibly not. I actually believe that in a way there's a link between going a little bit further outside slightly their comfort zone on the first experiment and getting used to launch experiments and at this point this is what happened. Okay? And so they did. And then so they move into this kind of continuous flow and then a product owner a few weeks later starts saying, well you know what, before we had point estimation, now I have no idea on how to have a sense of roadmap, right? A sense of predictability. And, you know, of course you can use things like no estimates, for example, but so how do you do that? So in this case, the next experiment was something around the lines of let's review the analytics of the tool that we're using and so let's do a meeting and my expectation is that everybody will be happy with that kind of form of estimation and predictability. And they did. Okay, so real experiments. So how do we do this? So essentially we have a backlog of possible experiments. You say, which one are we going to commit for starting tomorrow? or next week or whatever. So it moves into committed. When I say committed, I don't mean committed like this. What I mean is we'll commit to make it work. I would rather not commit to do anything. Let's spare program for three days. That's fine. But if we do it, let's do it for real. Let's try to make it work. Let's not find excuses. Let's not nod now and then find excuses why it wouldn't work or boycott it along the way. If we try, let's try for real. Our best. That's the kind of commitment. So it moves into ongoing. And then at the end of the expiry date, or I tend to do a lot of weekly retrospectives, so like you use PowerPoint Flow essentially to do retrospectives on a weekly basis. On a weekly basis, we look at reviewing the experiments that we launched. And there's a kata there. There's a routine, essentially a set of questions that happen absolutely all the time. So you move it to review, and those are the questions. What experiments did we agree to do? Which ones? So you see, like, what did we agree to do? Which ones did we actually do? What was their expectation? What's reality? You see this kind of gap? And based on that, what did we learn? And then we move to the next column to make sure that we do it. Based on what we learned, what are we going to do next? Yeah, so when I say, yeah, so that's what we try. And I actually like to think in terms of this as we're not really trying to falsify hypothesis. This is not about running experiments to prove that a hypothesis is right or wrong. It's to explore it. It really is, right? It's to explore a hypothesis. So it looks like the scientific method. It ain't the scientific method. I talked to a scientist, actually, I was here in Paris last year at Uzi. And so I spoke there and I was talking about scientific method as we all like to talk about. And I modeled it after the scientific method. But then I talked to a Swiss scientist who actually was a keynote speaker in the end keynote. And he works on the brain. And he would say, you know, Claudia, we were at dinner. He said, I love what you were talking about. Which didn't have a name yet, I mean it was slightly different, but the point being is, you know, like we like to do things, we are experiments that are isolated and repeatable and all that kind of stuff. You don't understand, I'm not trying to move human knowledge forward, I'm trying to outlearn a competition and continuously change and beat inertia. So it's not so much the scientific method in a very strict way we can look at it, I think this is complexity at work. We're talking about multiple experiments in parallel, we're talking about opinions as subjectivity, as first class citizens, we're talking about co-evolution, we're talking about a lot of stuff. And I suddenly realized, hold on a second, I thought I was doing systems thinking and complexity is kind of... The Kinevin model, and I'm thinking maybe the Kinevin model is trying to say something else that I kind of missed. There is a different... between systems thinking and complexity thinking. So this is what we're looking at. In territory of extreme uncertainty, we are in complexity, we are not in control of all the variables. So we're doing this experience to explore a particular way where I constantly have hypotheses. When I present a problem to the team, it's an hypothesis. Really is, right? It's a chance. I'm chancing it and see how the system reacts to that. It's something to think about, I think, in there. Because we're moving outside from a few guys who, from the very theoretical point of view, have a truth and sometimes it's cryptic, to actually say, well, with this we can do it, possibly. Possibly. I don't know. It's something I'm working on. Anyway. So some people fear failure and they say, you know, Claudio, the difference between expectation and reality is frustration. Why do you set an expectation, right? We are setting ourselves for failure. But I actually think that we fail when we limit our opportunities to learn. It's actually rather than expectation, as I said before, probably I should call it anticipation. This is what I anticipate. And the gap between the two things, it's learning.
Cyril, our pair programming sucked, you know, the two of us. But you know that at the end of the three days. You know, some people get frustrated. I kind of say, but that's when you start asking why. What didn't work? That's the learning. In fact, very often, I have a lot of stories where we were really good. We launched a lot of experiments. They all... pass and the only one who wasn't happy was me, right? Because actually, what did we learn? We did things we knew already in some way, right? Did we push enough? That's the idea, okay? So, and just to make my point, I guess, can you really pretend that you will never fall or fail? If life was... Like living in a skateboard. Who has ever done skateboarding?
Well, that's awesome. I've never seen so many skateboarders. Great, guys. So you know what I'm talking about. This is growth, okay? The only ones who never fall are the ones sitting on the bench, looking at their life passing by, okay? They'll never fall. But if you start thinking about what if life was like being on a skateboard? You want to learn? Try. But you need to be prepared to fall. I was in a company and there was a guy actually who started a 10-week boxing sort of thing, which was cool. And he said, yeah, that's exactly like boxing. You have to be ready to take a punch to learn how to box, of course. And so I put actually the next slide and say, you know, learn fast, Roger, you know, with him and photoshopped with a picture of a boxer there. We had a great laugh, I guess. But that's really the idea, right? If you're not prepared to take a punch, you'll never learn or you'll never learn as fast. That's for sure. So you see, and that's the third and last principle to date, is it's not fail fast, fail often, as we say in Lean Startup. It's learn fast. Fast, learn, often. Skateboard the principle. Okay? So three principles, seven steps.
Learn fast, learn often. Okay, so right from the beginning, I knew that this was different because the team could actually easily handle five to 10 change experiments each week. FAT and rapidly enabling them to deliver multiple times a day. Yeah, for no deployment in months, Experiments, experiments, experiments. Now they can deliver multiple times a day. A while ago I looked back, they had 172 experiments, count in. Okay, keep going. The rate is more about the five, lower five actually right now. So they slow down in terms of the number of experiments, but that's really the amount of experiments they've been doing. Fast, learn, often. Skateboard the principle. Okay? So three principles, seven steps.
Learn fast, learn often. Okay, so right from the beginning, I knew that this was different because the team could actually easily handle five to 10 change experiments each week, FAT, and rapidly enabling them to deliver multiple times a day. Yeah, for no deployment in months, Experiments, experiments, experiments. Now they can deliver multiple times a day. A while ago I looked back, they had 172 experiments, count in. Okay, keep going. The rate is more about the five, lower five actually right now. So they slow down in terms of the number of experiments, but that's really the amount of experiments they've been doing. And then it's spread. See, what happens is I don't care about problems and options. I throw them away. I'm Italian. I treat them like mozzarella. You know, they take too much estate. I don't want to handle. Then what I do keep, though, are the experiments. The experiments that they do, right? Pass or fail. To be honest, in the beginning, we didn't even mark them. Now we do mark them. But the point is we trace them all. And you can see the reason why we were doing the experiments. Sometimes the options we evaluate, probably we should write that down as well. But certainly the action, the reason, and the expectation. Okay, and you can imagine when you see like tons of these experiments That's what I like to think is leave a trail behind. Yeah, that's there That's the learning stream that they produce. There's a learning throughput. When CEOs ask me, are these guys agile? I learned recently that question is the equivalent of your wife saying, is my bomb too big? You know, like you shouldn't answer that question in the first place.
Am I too big in this? Yeah, no. So am I agile? You know, it's kind of ridiculous. Like, you even give those kind of ideas of, yeah, because they're agile, because my opinion as an expert is they're doing so many stand-up meetings or whatever. That's theater, right? The thing is, when you start actually looking at this kind of learning throughput, you have actually an indication of actually saying, you know, Agile is about adapting to change. These guys are learning.
If we had the perfect systems, you don't need Agile at all. Why do you use Agile? Keep the perfect system. Actually, put it in Visio. In Agile, we inspect and adapt all the time. So here's the thing, but then it's spread, right? Because you have that kind of visibility, other teams copy. Is there anything in these problems that is specific to software development? No. Does marketing have problems? Yes. Do sales have problems? So I started actually working with sales as well.
How do they upsell? They have a number of services. I was telling a story. They sold one product and they wanted to upsell other products. How do we do that? Well, let's start making observations on how you're doing that with clients and based on that, what options do we have? And based on that, what experiments do we have? Can we run? Let's do an experiment with a subset of your clients. Let's see how, if we move the needle or not.
So it kept spreading and I call this terraforming. This is terraforming organizations. It's like Total Recall, remember? The oxygen from Mars. Yeah, we're creating a habitable planet. So that's popcorn there coming, right? These are the experiments. Imagine having that. So really, imagine a continuous flow of experiments to accelerate the rate of change in every corner of your organization. I would say dramatically even. But how far would you go? If that happened, how far would you go? So today, Balcon Flow is entering more organizations. And it was designed to quickly introduce, sustain, and accelerate change. That's really how I designed it. It was actually to capture my experience on how I deal actually with teams. I'm an independent consultant. I work with a lot of teams and whatever. So that was the initial idea. Then I discovered actually it seems like to match well with what some guys are talking about these days on complexity and it seems like, okay, let's develop that because in a way this theory that is backing up why this is working, I guess, or why it might be working in certain contexts at least. But then I started actually wondering what jobs are other people hiring Popcorn Flow for?
I'm using this terminology, some of you may or may not be familiar with that. So I know why I designed it, but I don't know why people are using it.
do products, I suggest you call back your customers, not to say what's your experience with that, would you recommend? It's actually how did you get there in the first place? What are you trying to solve? What jobs did you have? So specifically there is a theory called jobs to be done that says from Clayton Christensen and some researchers. Anyways, people encounter situations that drive the need to accomplish a job. And what they do is they hire and fire a product or service to get the job done. Okay, so there's a lot of bull about personas and whatever. This guy's got three dogs and whatever. There's maybe some correlation, it's not causation. That doesn't cause them to buy or to hire your product or service. So what we do instead is we analyze the jobs and we say, what jobs are these people trying to do? And then we analyze actually this job to actually say, well, What's important to get the job done, but it's poorly served by the market. These are how I can disrupt the number of companies, because I actually, you get those kind of level of insights. That's what we look at, for example, and say, let's experiment in that direction. Yeah? Important to get the job done, poorly served by the market.
Okay, so some teams, so let's look at this job. Some teams hire Popcorn Flow, how I designed it, I guess, to continuously improve the way they work. So either through weekly retrospectives or also just in time. This is, for example, at the top here, what we see is rather than having two, separate boards, this team created the same board, just split it in half. The top part is a common board, value stream. The bottom part is power and flow. Yeah, and they actually, when they set it up, they started actually laughing and say, this should go 80% up, you know, because it's becoming so important. And the way they're doing this now is just in time. So they look at the common board, they make observations, impediments to flow, and then they add essentially five minutes to their stand-up meeting, and what they do is they review experiments or they create new experiments or they discuss those experiments between themselves.
Some managers hire it to reach wider consensus and take better decisions. So as a visual communication or mentoring tool.
This is a friend of mine who actually posed for the picture. So it's totally made up.
He was actually telling on what just happened to him. But it proves a job that I see over and over. That is, even in very traditional companies, with very traditional command and control project managers, very often I go there and say, how about you set up a board? You don't even have to explain this theory. You just go there, you set up a board, and you say, what problems do we have? Yeah? You want to introduce change? Here's a tip. Don't start with your problems. Start with their problems. I don't care if they like or don't like Agile or Lean or whatever. What problems do you have? Yeah?
As a consultant, this is what I say. We bring models. experience and options. Okay, so I go there and say what problems you have. I may introduce my own, but the point being is that when we talk about options, they may think about a number of those options. I could introduce more options myself. What you do when you hire a consultant, I'm talking for all the consultants out there, you're buying options. Different external view of potentially how to look at the problem. But, so this is what I see essentially is managers who have it in their board, sorry, in their room. They have a pop-up flow. And rather than telling people what to do, they start actually selling it, sharing. Or maybe they ask and say, I see this as a problem. What do you think? That's very powerful because we're moving from just a telling to more sophisticated levels as well of involvement, engagement, delegation. There are different levels of delegation. If you're familiar with Jürgen Appel, you can actually think into Jürgen and so many others anyway. But if you look at those levels, you can actually consider that that's a way to involve people rather than just telling.
And the other thing that happens is that copper boardrooms use it for strategic decision making. So the one before is more tactical, get people in the room and just discuss. This is more strategic. What we do there is we use, for example, real options. Why? Real options, do you remember it? Yeah, so options. Yeah, these people are nodding. You're lying. You don't know anything about it. Real options. Well, anyway, I'm just kidding. So there's a lot of real options coming from the financial services, and then Chris Matt and Olaf Massen.
Extruded pretty much the core things that we could understand, I guess, from all those formulas, essentially, which are essentially two observations and a strategy. The observations are that options have value, options expire, and the strategy is never commit to an option unless you know why. So delay options. So the way you look at this is actually to say the options that we have there, we can call them strategies. Problems and observations are essentially problems and opportunities. New technology comes in, there's potentially an opportunity. What strategies can we consider here?
Discovering these strategies and then rather than as many companies do commit to one in a territory of extreme uncertainty when everything can change all the time unless you guys can predict how Wall Street is going to change in the next hour or so things can change all the time right there's a lot of stuff that we have no variable no control you can analyze all all you want you're just fooling yourself right so at that point we say okay so this is our number of strategies but let's not commit to these strategies let's explore them so this is what they're doing they're essentially they're exploring different strategies
Maybe some of them are competing between each other, others may be more closely related. But they are not committing to them, they are exploring them by running experiments. So at strategic level. Yeah, and then it can use real options to try to extend options, do other kind of work and whatever.
Others, and I like this, I use it a lot, is they use it instead to reach product market fit and outlearn the competition, right? So who's familiar with Lean Startup? Who's familiar with innovation accounting?
Last, who is familiar with pirate metrics? Okay, so in Lean Startup, right, so there is this idea of experimentation. Now in Lean Startup, what happens is we tend to prove and disprove hypotheses. Here, as I said before, we're just exploring things, right? But what kind of problems would I put in Popcorn Flow? I use innovation accounting. In a typical startup, or a startup again, it's not just the one in the garage, it could be within your company, it could be new products, new markets that you want to explore. At the beginning, you have a customer and you have a product, except you don't have a customer and your product is probably crappy. So the first thing you do is not you get as many customers as I can in my crappy product. First thing you focus on is, for example, activation. To make it simple, if I have a simple page, I have visitors coming in, of the few, not a million, of the few actually come, how many of them are doing anything with it? How many of them are signing in? Or if they sign in, how many are doing something? something useful with it. You know, they go maybe to my platform and do something. That would be activation. You do activation well before getting a lot of customers, because otherwise what you do is you spend a lot of money, maybe on Google AdWords, in acquisition, you acquire a lot of customers, right? They all come there to your page, but it's so bad that they just flow away.
What you want to do here is you focus on activation. You focus on, so here's a problem that I might write in Popcorn Flow is improve whatever activation means in the specific app or whatever is improve activation rates, say, from 5% to 10%. If 100 customers come to my page, only 5% are doing something with it right now. Let's bump it up. It doesn't matter if you have 100 customers or a million customers. You still have that ratio that you want to improve as a product. How about to improve retention? Do they come back? Yeah, they go to my page. Will they come again back? You want that kind of information, right? If they never come back, that's a bad sign.
And finally, for now, is the referral. Are they talking about this to others, to their friends? Are they, you know, do we have signals? Can we see anything in a social network or whatever? Why? Because we work on this, we focus on this matrix. On Popcom Flow, essentially what we do is we put those kind of ideas as problems, and then we think in terms of implementation options. Yeah? That's what product managers should be doing. Why do we focus on the wrong stuff? I want a longer antenna. is in the solution space, it's not in the problem space. What are the customer needs and how do we change those needles in terms of making a difference? So product managers or marketing or whatever, they can focus on a certain area and then they talk to the team to actually say, what options do we have here? To improve this. Once you get these three things done extremely well, what you have is stickiness. You have a product that sticks. If a few customers come to my product, they will stay with that, they will come back and whatever. And then, and only then, is the time to do two things. Which is to focus on acquisition. So let's acquire my customers through Google and whatever. That's probably actually when you need investor money. That's to grow. If you get investor money too early, you focus on stickiness and the guys are looking at the last part, which is this one, revenue. And unfortunately, trying to get revenue too early means that you have a crappy product, you will spend a lot of money to acquire them, and they will fly away. So that's how you die. So at least at that point, what you have is when you engage with investors at that point, your goals are aligned. First, you reach product market fit, and then you focus on growth, if you have that opportunity. Anyways, so that's a way of actually looking before, like we power from flow with teams, if the stated or unstated goal is to improve flow and anything that is an impediment to flow, we want to remove it. So it's kind of the second learning loop where we're kind of thinking on how we're doing the work and modify our processes, whatever. In this case, it's straight on the job, right? We are really looking at what features are we going to build in order to build this product. Okay, so Papcom Flow is touching lives even outside the business world. For example, families. This is my son. He was five years old there. He's now six. This is Park and Flow.
Actually, this is all I just wanted to show. This is how, you know, so we have problems in the family. You know, problems are, there's a number of them. Some are made up. So the problem is,
Actually, yeah, the problem may be totally made up. Move it. So it's kind of the second learning loop where we're kind of thinking on how we're doing the work and modify our processes, whatever. In this case, it's straight on the job, right? We're really looking at what features are we going to build in order to build this product. Okay, so Papcon Flow is touching lives even outside the business world. For example, families. This is my son. He was five years old there. He's now six. This is Park and Flow.
Actually, this is all I just wanted to show. This is how, you know, so we have problems in the family. You know, problems are, there's a number of them. Some are made up. So the problem is,
Actually, yeah, the problem may be totally made up. Like say, okay, three options that we can build using this sellotape. So the sellotape is the problem. The problem is we have a sellotape, we need to create three games. What options do we have? And we start thinking together, right? So totally made up. Others are, you know, one day he found an acorn, you know, an acorn to plant. So his problem was he found an acorn. He wanted to plant a tree in the garden, an oak tree, you can imagine. And he said, so my problem is I don't know how to do this. I said, okay, let's write it down. What options do we have? I suggested one and said, how about let's just do it. Make a hole, throw the acorn down, cover, put some water, pray. Yeah, that's my just do it. Mami was there and she said, well, how about we ask Sarah? Sarah is a friend of ours. She knows everything about gardening. We'll ask her. She'll definitely know how to do this. Option number two, call a friend, right?
Option number three was how about we go to the library, you know? We get the book, we'll tell us all about gardening. In the end, we went with Matteo's option, which happens very often actually, which was, he said, five, let's just Google it. It was just, damn it. So I said, okay, okay, but let's make it an experiment, right? And the experiment there was, if we Google it, my expectation is that we will find a video. Within 10 minutes and that video will tell us exactly what to do. Okay, I just maybe was a bit You know, it doesn't matter a bit I can't find the term anyways doesn't matter. So we so we run that we did it We found the video but the video told us straight away before you do anything Check if the acorn is good and the way to do that is you put the acorn in a glass full of water If it floats is not good means it's damaged has been eaten by a bug whatever So we said, okay, let's do that. Seems good. So we run that. We put the acorn on the glass full of water and the acorn floated. So failed. My son was like, he started crying and all that kind of stuff. I said, okay, hold on, hold on. Let's review this. What was the experiment actually? We said, okay, we will find the video, we found it. Our expectation was that we will find and we'll tell us what to do. And, you know, serendipity or whatever, sometimes you don't know what to expect. Whatever happens, happens. And we found out actually a really rapid way to find that the acorn wasn't good. Had we begun with my option, let's do it, we would have waited for a year. Right? We should celebrate this, right? And so he kind of agreed and he said, okay, what are we going to do next? And of course you have options, right? So when things don't work as you expect, you have always options. Like an option could be that we persist. Any experiment you try, per programming, persist. Maybe we don't know enough, let's keep doing it and see more. It could be that you re-evaluate the options that you considered. It could be that maybe you explore something different or you evaluate the options. Or you evaluate the problem in itself. Or maybe if it worked, maybe you decide to commit, whatever that is. And of course you can share your findings and whatever, but you see you always have options. At any single stage there we have options. So in that particular case we had at least a couple of options. In the end we went with one which was, let's bring the glass full of water in the place where we found the acorn in the first place. So we literally went to the park with the glass to try all the acorns we could find. Yes, right away, on place. So you see how this works? Now one thing that I want to show though is, this is going to schools.
I started actually with Matteo and I realized, you know what, it works if I'm coaching him.
So if I'm facilitating this, because it doesn't get concepts like experiments quite yet. But the concept that he understands are problems, options, ongoing, done. I tested it. So what we did, this doesn't show that. Maybe tomorrow there's a mini workshop or maybe we can play. It's not really a formal workshop. We can play. You can bring your problems and try to run experiments together. There's an hour slot tomorrow.
But the thing is, like, we said, let's redo a different board, a different Power and Flow board. Which is reduced. So I called it Power and Flow Light, essentially level one. My goal is to help him reach full autonomy without me, okay? And I know I will see that when I'm not in the room and he starts putting problems in working out options. So that's what we did. We did a board together. Actually, I created some stickers and I said, okay, put the stickers there. Yeah, and we designed the board together, we put it again in the room, so the room that we have now in our sitting room is actually simplified. So it literally has got problems, options, ongoing, done. And I actually published a couple of videos, we probably don't have time, maybe tomorrow we'll show that, but how he's explaining it to the guys out there. And it's really explaining, you know, the problem he had the other day, and then we captured, we created video, was I actually saw him on the sofa and he was bored, right? He said, oh, I'm... I'm bored. I said, well, why are you bored? And he said, yeah, I'm bored because I don't know what to build in Minecraft.
Looks like a problem for me, so that's what we did. We draw it, and then we said, okay, what options do we have? And then we started working together the options. Beautiful, you know, stuff you can do on a daily base. Because as you see, like when we talk about agility, agile for families,
What I see all the time is, okay, we're creating nice team players and working bees, right? But we are in the creative economy, right? Being a working bee is part of the thing. I'm not saying that I would diss that. But what time after is to actually to build young, bright thinkers. Yeah, and can better cope with all the stuff on the outside, the turbulence on the outside. So this is what I'm building. And in the video, we'll explain actually, you know, and this is level one. And it's funny, actually, said, and when I go to level two, that they will introduce another sticker. And let me show you the sticker, and it shows the next step is review, because I want to say, okay, he's doing this without experiments, without review, without next, and whatever, just the minimum. It shows the review sticker, and it says, and this sticker says review. What does review mean, daddy? You know, what does it mean, daddy? So that's the thing, right? You want to introduce that very incrementally. Now let's move on, right? So we are introducing this with schools. Just last thing I didn't... say is my son is Asperger, is autistic actually, he's very high IQ, it makes it for the perfect project manager because he needs to be in control of everything, yeah, it works really well with things, not so well with people, right? So that's why I'm experimenting with him and one thing I realized is, you know what, when we have a problem and a solution, we always think like that, right? We're capable of brilliant thinking but we don't think very much very often, that's the problem, right? So we always have a solution, a problem and a solution. And all the time I start thinking, what options do you have? You know, you think like my son, what options do you have? And this is what I found, that when we co-design or we even present options, it's not anymore about I'll do this or I don't do this, it's which one.
So, Pumpkin Flow is even part of a proposal to foster innovation in the public sector in Ireland. Three months ago I was in the House of Parliament. I can tell you for sure this will never work.
Okay, you want to talk about limits, there's no silver bullet. That's not going to work there. I doubt. I mean, it's talking about theater, you know. Anyway, Papcon Flow actually is also getting traction at a personal level. So this is actually a friend of mine who works in Ericsson's in Italy and Francesco and he keeps saying he sends me tweets every week and he says you know this week I run so many kilometers another successful path and flow story, right? And 44 kilometers, there was 50, there was more. At some point he sent a tweet saying, so far I've run a thousand kilometers, Park and Flow story, so it's halfway to Ireland at this point. What I'm kind of afraid with this one is that if he dies of a heart attack, it will be my fault, right? So, but somewhat he finds it, that it motivates him. Anyway.
But what I'm saying there is that's him. That's me as well, right? There's a number of other people out there. This is becoming a way of living. It's a way of life. Every single week, I'm five experiments older. I said to a CEO who actually saw the result on a team, I said, you don't understand. Every single week, I'm five experiments older than you.
When you die, how old do you want to be? Two experiments old or 20,000? Yeah, that's what I said. So you see that? So this is kind of early days and whatever. This is a throughput. This is a burn-up chart of experiments. It's not the value stream. It's the learning stream. This is my learning. And here's the failure rate, you see there? Like, this is the good. The failure rate is actually pretty consistent. Sometimes it's higher, I guess. But the point being is, at that point, that was 30% of my experiments failed to meet my own expectations. I'm learning for all of them. It's like the acorn story, really, okay?
So there's many projects, initiatives that are in active development. So there will be more to come and whatever. I'm actually, by the way, I'm doing a workshop in March here in Paris.
But in any case, if you're interested, come over tomorrow, actually. We can play together, I guess, with a couple of these things. But the project I'm actually more interested in at this point is this one. I'm writing a book.
And if you're interested, please join the early notification list, so popcornflow.com slash book.
And I'm aiming at going live in March.
Final thoughts. Final thoughts are the following.
Let me try this, okay? It may not work. No, I'm just kidding.
But you see this, you see a lot of us, you see it here. We talk a lot about innovations, ideas, yeah? And there's these people out there, if you're here, it means you care about this stuff, and then there's people out there. They don't like change, right?
They don't like change. They cling to the things they are familiar with, all that kind of stuff, their routines. But you may consider that more often than not, them, it's us. We cling to our routines, right? We cling to everything that we're familiar with. We create boxes for ourselves and others. Yeah, we are very often the, you know, you kind of serve. with the brands we buy, everything we do, the routines we use, the methods we use.
Meanwhile, everything is on the move. Everything is on the move, is the turbulence outside, right? So we act as if everything was static, but everything is really moving. And I was telling my son, actually, at some point it was into space, and everything to space, yeah, and I was telling him, you know, there's Earth rotating around the sun, the sun around the galaxy, you know that, right? And the galaxy is moving right now, as I'm speaking, we're all moving 1.4 million kilometers an hour towards another galaxy, Andromeda. And I was telling him, in 40 billion years, we will crash against Andromeda. And Matteo was really upset about that. And I said, don't be upset, because only in 4 billion years, the sun will become a supernova. We'll burn in hell a lot earlier than that, right? So don't worry about that. But the thing is, like, really, everything is on the move, and it's beautiful chaos. It's beautiful chaos, right? So you find things here like popcorn flow that actually gives this idea, these are not forces of nature. A lot of the systems we meet are processes, procedures, and rules and regulations. They've been created by humans, and by humans shall be destroyed if they don't fit. If they're not fit for purpose anymore. So think about power and flow and this idea that we can change, we can evolve, we can help others evolve, and evolve fast, almost as fast as a virus. Okay? So the last thing I want to say there is, what about you? What are you waiting for? There is a world out there that needs to be changed, but it's a world that needs you to change. Okay? Thank you.
One second.
Just the last thing I want to add is, if you remember, I like to quote myself, right? So here's my quote back. It's not what you do, but rather what you learn by doing it that matters. But that's part of the story. But then, it's not what you learn, but rather what you do with what you learn that matters. Okay? So what we learn? Apply it. So I'm not saying, Carl was saying, listen to what we say, don't follow. What I'm saying is, listen and experiment with it. Try it. I don't have to bring case studies or whatever. If you think it might work, try. Try a park and flow for a number of weeks. My expectation is that you will like it.