Host Intro (Gene Kim)

So the first speaker is John Smart, who has spoken at every DevOps Enterprise Summit here in London, as well as our US conference last year. He's also on our programming committee.

I first met him in 2016 when we were organizing our first conference, and he was heading up the ways of working at Barclays. He had a reputation of doing things in a way that were very different than the traditional norms inside of an organization that has one of the most highly evolved bureaucracies on the planet, having had nearly four centuries to evolve itself to perfection.

His presentation last year included the work they'd done on lean portfolio management, which changed the way that capital is allocated and released to business and software teams. And my favorite way to describe DevOps is that it is merely a better value, sooner, safer, happier. So many of the things that he utters become almost mainstream in this community, and you'll see why.

He is now Partner of Business Agility at Deloitte, and he is here to talk about seven lessons learned, both through personal experience and through the seniors. John Smart.

Jonathan Smart

Hello, London. How are you doing?

My name is David Brent. I am the Acme Walking Shoes Ultra Mountain Awesome Corporation CEO. And you are the awesome resources. How are you doing? Woo-hoo. How are you doing? Good. Even better. Well done.

I am so delighted to be here, so excited to be here for this town hall. I've got a really exciting announcement to make.

Now, it has been an annus horribilis. We've had a bad year. Market share is down, revenue is down, and profits are down ever since Yangtze Inc. released the Amazing Walking Shoe, AWS.

Change is needed, and I have a plan. And it's a Gantt chart. It's a beautiful Gantt chart. We can't fail.

"Just a perfect day." You will transform. "Drink champagne." I'm not going to change, but you will. "And then blame it..." We have an 18-month countdown. We have a program with a start date and an end date.

We're going to print out a 548-day, that's 18 months, countdown and stick it on the back wall of the offices. That's a true story. And then we will be done. We'll be magically transformed into purple flying unicorns.

It's going to be such a perfect day. And I have decided, with literally no input from any of you whatsoever, that we are going to do a skiing transformation. These Ultra Mountain Walking Shoes are no good anymore, and there's this thing called skiing, so we're going to go skiing.

And I have decided, with absolutely no input from any of you whatsoever, that we are going to adopt the Spitting Image model. Because if it works for a small Swedish company making a music streaming piece of software that has lost 2.2 billion euros in the last five years, then it must be good.

Thank you. And we're not just doing any type of skiing. We're going to do Nordic skiing, synchronized. Look, they are synchronized. You're all going to do synchronized skiing, the whole organization on the same cadence.

And because I believe in your development, you're all going to do mandatory sheep-dip training, certified ski master training, so that you can tell people what to do, and certified piste owner training, so that you can tell people what to do. No change.

And very lucky people can be certified ski master ski masters who can train the ski masters and tell the ski masters what to do.

And this skiing certification doesn't require any actual skiing, and it is renewable by reading a book, watching a video, or attending a conference.

Further, I empower you to be empowered.

Yes, Carmen?

I really think that snowmobiles will be better than skiing.

I'm not empowering you that much, Carmen. No, you can't go by snowmobile. We're doing Nordic skiing. I have decided.

So you're empowered. So long as you're a certified ski master or a certified piste owner, you're totally empowered. So long as it's Nordic skiing with synchronized iterations, you're totally empowered. I'm not quite sure where that leaves, but you're empowered.

So on Friday, the office is like this. And on Monday, after you've done your sheep-dip training, the office is going to be like this. You're going to be happy and smiling, and Christina Maslach and Nicole Forsgren and Steven Spear will be very happy.

So that's the end of the town hall. Now, get back to work.

Thank you very much. How do you feel?

Empowered.

Empowered? Nice. So not empowered.

So this is John. David has left the stage. This is John. So that was a little parody. That was a little parody of anti-patterns.

I'm going to share with you seven lessons learned. So that was a little example of maybe how not to go about change and how not to go about ways of working.

And what I'm going to do, I'm going to share now. So those are the anti-patterns. I'm now going to share with you the patterns. And so the anti-patterns and the patterns, these are lessons learned the hard way.

I have messed up all of these personally. I've got all of these wrong, learned the hard way. And also, as Gene said, it's through the seniors. It's through awesome events like this where you just learn so much from so many people. So this is all standing on the shoulders of giants.

The first lesson learnt is focus on outcomes. So previously, I was head of Agile Transformation, and we were doing a capital A, capital T, capital D DevOps transformation. That's not very empowering because that's telling people exactly what they're going to do, exactly how they're going to work. A certified ski master or a certified piste owner, you have absolutely complete empowerment and absolutely no choice. This is how you're going to work. Capital T transformation, you have no choice. This is how you're going to have to do it, and there is no question about it.

That's not very empowering. So the learning for us, the learning in my past, is to pivot and focus on the outcomes. And for me, these outcomes and what I'm doing now, working with lots of companies, these outcomes, so far, I have yet to find a company where these outcomes fit for ways of working.

So the first one is better, and better is quality. So the one measure that matters for me on this for software is, or for product development rather, incidents in production.

The next one is value. Value is unique. These are OKRs, so objectives and key results. These are unique. They could be diversity. It could be geographical location. It could be market share. It could be revenue. That's unique to the thing that you're doing.

The next one is sooner. Sooner is, I guess, really the main part of time to learning. It's lead time, throughput, and flow efficiency. And this is how you can end up doing three times as much in a third of the time. With the other ones, it's balancing measures.

The next one is safer. Safer is continuous compliance, agile, not fragile. This is not finding your customer data on the dark Internet, needing to use the Tor browser to go and purchase customer credit card details. This is avoiding that scenario and the headlines.

And then there's happier, happier colleagues and customers. And what's fantastic is, at the DevOps Enterprise Summit, we've heard a lot about burnout. And so this is super important in terms of colleague happiness. This is a more humane way to work.

And anything you can do badly. So these things, these outcomes, these measures, they balance each other because you cannot reduce the lead time without, or it'd be very visible if quality goes down or if happiness goes down or if safety goes down. It becomes very visible. They balance each other out. And as we've seen in the State of DevOps Report, as we've seen, the mediocre performers reduced their lead time, but their quality went down because it's just pushing stuff through the system faster.

So when you focus on better, sooner, safer, happier, and customer value at the center, then it's not a case of doing one at the expense of the other.

So in my past, we pivoted the organization to focus on these words, and then people are empowered within minimal viable compliance. And a call out to Nike and the talk at the DevOps Enterprise Summit last year for minimal viable compliance. So within the guardrails, people are empowered to achieve better, sooner, safer, happier, however people want to within the guardrails so you don't fall off the edge.

And then there's intrinsic motivation then focused on these things, and it doesn't necessarily mean agile, doesn't necessarily mean DevOps. It could be funding. It could be finance. In one case, it was smaller waterfalls. That was okay.

The second lesson learnt is to achieve big through small. So there's an anti-pattern that I see, which is achieving big through big, which doesn't really have much agility to it.

So on this picture here, the very big Kubler-Ross curve, which is for those of you that are not colorblind is green. That very big curve, you get the peak of excitement, you get the trough of disillusionment, and eventually you climb your way out of that hole if you do a big bang capital T transformation at your organization. And I do see this anti-pattern a fair amount.

Time T2 there, that's probably about two years. So about two years in, you start to climb your way out of that hole. In my experience, the half-life of the CIO is somewhere around the bottom of that trough of disillusionment. So the CIO's probably lost their job before you climb out of that hole. Someone else comes along and says, "Oh, this agility, agile thing is not working. Let's go back to traditional ways of working."

Instead, take lots of little curves, lots of little change, lots of little J curves, which is that yellow line, which is the lots of little squiggly lines going up. And remarkably quickly, you're above your current performance level. So you need to apply an agile mindset. Think big, start small, learn fast.

When you zoom out of that yellow line and you look over a five-to-seven-year timeline, it should be an S curve is my learning. In the past, we have tried to do too much too soon. We tried to encourage more of the organization to adopt new ways of working than the organization was ready for. So a personal learning for me is an S-curve profile to adopting change in an organization.

You have to keep the gradient low to start with. So when I'm talking to leadership teams, I try to really manage down expectations for the first 12 months. Typically, people are incentivized with bonus payments for 12 months. So typically, there's a desire to like, "We want 80% of the organization, these new ways of working by the end of the year." No, it won't work.

Humans have a limited velocity to unlearn and relearn. You can't force the pace of unlearning. So it's an S-curve profile.

The third lesson learned is to invite change over inflicting change. Whenever I hear anyone use the word resistance or convince, I know that that's going about change the wrong way. There shouldn't need to be a case of convincing anybody or there being any resistance.

So this is the diffusion of innovation curve from Everett Rogers in 1962. You've got the innovators, the early adopters, the early majority, the late majority, and the laggards.

So the innovators, and it's a normal distribution across a large population of people, the innovators are motivated by scarcity, so the first one to have an electric car, even if it's got a range of 10 miles. Innovators have a growth mindset, are not risk-averse, and again, are motivated by scarcity, the first to have something new. The early majority and the late majority are motivated by social proof.

And so for this, every organization is unique, complex adaptive systems, and everyone is special. We're special. So it doesn't matter what other companies have done, and you can hear talks at this conference about what other companies have done, and they're very inspirational and they're good data points. However, for most people in your companies, it's what have we done here at our company in our context? So the majority need social proof. So your communication strategy and the way you deal with change needs to be two-pronged.

You need to appeal to the scarcity for the innovators, and you need to provide social proof for the early majority. So you have to start small, run experiments with the natural innovators. Then what happens is, as you get into the early majority, and I saw this happen, the innovators no longer had scarcity and were starting to get disengaged. So then you need to keep the innovators at the bleeding edge. New processes, new tools, new things, external speakers. We organized an exemplar club. You didn't need to be an exemplar to join, but you needed to commit to be exemplary to be in the club. And we organized special speakers, the first to try new processes. Basically, the innovators on the left-hand side.

And then you get into the laggards. They're just like, "No." Grumpy cat. "Nope, over my dead body." People have said that to me. "Over my dead body." So that's fine. Just ignore them. Leave them alone. Don't spend any time on the critics.

But typically, in my experience, people fall into these three categories: the champions, the fence sitters, and the critics. And what I've learnt the hard way is focus on the champions. You end up with a vacuum. The fence sitters come off the fence, they become champions.

And this happened. Eventually, what happens is the laggards become the odd ones out. So as the rest of the organization has moved or adopted a new technology or moved to new ways of working, the laggards become the odd ones out, and that's the last thing that a laggard wants to be. The last thing they want is scarcity and to be the odd one out, and then they join. And that's exactly what happened at my previous place of work.

You've got crossing of the chasm from scarcity to social proof. And again, this is where communication strategy and data, those two things, emotion and hard data, because different people are motivated by different things, are super important for change at scale in large organizations.

And then I had this epiphany as I was putting this presentation together. The normal distribution, the diffusion of innovation curve is a probability distribution. It is a normally distributed probability distribution. When you draw that as a cumulative probability distribution, it's an S curve. And I was like, "Oh my God," because I've been talking about S curves for a while, and I've learnt S curves the hard way by trying to do too much too soon. This is just physics. Well, it's not. It's humans. It's people.

I had this massive light bulb moment where it's a cumulative probability distribution. This is how humans adopt change. So the S curve for me, this just reinforced the whole S curve thing. It's a cumulative probability distribution.

So if there's one word I want you to remember for these three days, it's this word. And Dave Van Herpen. Where's Dave? Is Dave in the room? Yes. Thank you, Dave. Everyone say thank you, Dave.

Thank you, Dave.

You're welcome.

So I was running Lean Coffee. I was doing a Lean Coffee session on day one. Dave was in the Lean Coffee, and we were talking about fake agile, and we were talking about leadership behavior. And Dave mentioned this word.

Who here is a German speaker? Okay, a few hands going up. So what does that mean?

Fake agile.

Fake agile, yeah. Anyone else who's a German speaker?

It's a fake rail movement.

Fake rail movement. Railway fake movement. Yes. Thank you. So this is that effect where you're sitting on a train at a station, there's another train on the other line next to you, and either you or that other train starts moving, but you're not sure which. You know that? Do you know what I mean? Yeah.

So is it that train that started pulling away or have you started pulling away? So credit to Dave. There's a German single word for this. Eisenbahnscheinbewegung. I practiced that. Sorry. Actually, I apologize. That's terrible to get applause for saying one word in German when we've had so many foreign language speakers here speaking fluently in English. That's terrible. Eisenbahnscheinbewegung.

So it's this symptom of you're in an organization and you see movement and you're not sure, is it you? Is it them? Is it other people who are doing stuff? Am I moving or is it because now we're calling everything sprints and stand-ups, and we've got scrum masters and product owners and Post-it notes. Does that mean we're making forward progress? It's like railway fake movement.

And what I have observed is, back to this point around invite over inflict, when you inflict change, you get railway fake movement. Actually, you get #nochange. You get the new labels on top, but the same old behaviors underneath if you do it too quickly. I'm seeing some nods in the audience. It's fake change. So you cannot force the pace of change with people.

Lesson number four: leadership behavior will make it or break it. The leadership team is team number one.

Often what I have observed, and I have made this mistake, we have made this mistake, is you start at the team level and you try to work your way up. So limited success. If you start at the grassroots, you'll hit a grass ceiling. There is a grass ceiling you can't break past and you'll have bubbles of agility and bubbles of new ways of working in a sea of waterfall.

You have to start with a leadership team because if the leadership team and ideally the most senior possible leadership team are not supportive of new ways of working, then as an organization, there is not much chance of success. There'll be pockets of success and pockets of betterness, but it will be a local optimization. So leadership team need to keep the elastic band stretched, need to keep pressure on the organization in a very positive way, in a very empowering, and this is a priority for the firm for you to be spending time on this kind of way, not in a dictatorial infliction kind of way.

Psychological safety, super important because people need to experiment. People need to fail. It's learning through failing, through safe-to-fail experiments, through improving. So there absolutely has to be psychological safety. Gene was talking about generative culture, Westrum culture types. There has to be a generative culture.

And intent-based leadership in terms of pushing decision-making down to those with the information rather than pushing all of the decision-making up to the few in positions of authority. And a good example here is David Marquet, Turn the Ship Around!, US commander of a Navy submarine. Turned it around from the worst-performing to the best-performing in 12 months and didn't issue a single command in a subsequent 12-month time period.

Lesson learned number five is to build the right thing. So an anti-pattern I see here is I see teams who are exhibiting a lot of agility and have reduced their lead time but are disconnected from the rest of the company. The headless chicken syndrome. There are teams who are running around like headless chickens, and it's a self-fulfilling prophecy of backlog replenishment and product owners and it's like in a traditional way of working where software 75% of all of the features in software is rarely or never used. You can have the same thing with agility where teams just keep replenishing their backlog and just keep producing stuff disconnected from strategy and what the firm is trying to achieve. And I am seeing this quite a lot right now.

So this is the pivot from project to product. This is the pivot to long-lived teams on long-lived value streams. Typically in my experience, 80% of the value streams are customer-facing, and about 20% of them are internal.

And then the work, which is nested outcome hypotheses. So this is this pivot from a predictive solution to outcome hypotheses to bets. And this is from last year's talk, so there's more on that. This really for me, what I'm seeing, a pattern I'm seeing across companies is this is the key that unlocks the door. This is super fundamental. This is changing how people are organized, how people work, and how the work is organized. This is the pivot from predictive solutions to outcome hypotheses and experiments.

The sixth lesson learnt is build the thing right. So this is the word safe. And I mean SAFeR as in compliance, as in continuous compliance. So speed and control, not speed without control, not control without speed.

So this illustrates a process that has worked at scale, that works at scale. This is something that we've done and we're doing with organizations. So business outcomes come in on the left-hand side. The unit of conversation is a quarterly business outcome.

There are two verification points. There's an engage point, which is: Is this in line with company strategy? Is this what we want to be doing? Is this the right kind of work? And have we done sufficient envisaging, which could be a photo of a whiteboard sketch.

And then there's a validate stage, which is the mandatory data encryption, GDPR, the absolute must-have control requirements, compliance requirements have been implemented and tested, and then that could be 100 deploys a day after that.

So then within that circle, there are the product teams. There could be one, there could be 100. And there's a multidisciplinary control team. Now, this language might not work for your company. It works in some companies. And this is information security, data privacy, fraud, anti-money laundering. These are people who previously were organized into role-based silos and now in a multidisciplinary compliance team aligned to the value stream. So it could be mortgages, savings, it could be luxury bags.

Whatever your business does, the identity is I am mortgages, I am savings, I am luxury bags rather than I am information security. And then you can start innovating and use biometric authentication. You kind of understand the unarticulated needs of the customer.

The risk stories we went through previously, over 300 standards. We codified the risk stories into a format, into a language, and we set up the tooling to be able to insert them into Jira or whatever tooling teams are using, so the actions are all in one place. And again, credits to Nike for this term, minimal viable compliance.

So it's not one size fits all. So if it's a restaurant menu application, then there's hardly any controls. Who cares if that's hacked? We know what we're having for dinner on Friday. If it's a payment processing system, internet facing, then the level of compliance is much higher.

And then finally, lesson learned number seven, go slower to go faster, or you will end up going slower. And you're never done improving. So it's not a program with a start date and an end date in terms of ways of working.

This is the Toyota Improvement Kata. Number one, get the direction or challenge. For example, better, sooner, safer, happier. Number two, grasp your current condition. Where are you now? Number three, establish your next target condition. This typically is in about three months' time. This typically is an outcome hypothesis. For example, an OKR. It should be beyond your knowledge threshold, so you're not sure how to get there. And number four, you conduct experiments to get there.

And you need to be failing, because if you're not failing, and these are safe-to-fail experiments, then that means you're not trying hard enough. And importantly, it is not a straight line from number two to number three. It's a wiggly line, and you don't lock down that line in advance. You don't determine the predetermined route from A to B. You experiment your way from A to B with some hypotheses.

And a saying which really resonates for me is, "Impediments are not in the path. Impediments are the path." Theory of constraints, Eli Goldratt, it's going from constraint to constraint to constraint, from bottleneck to bottleneck to bottleneck, and you are alleviating those bottlenecks, and you are never done on that. Back to the point around it's not a program with a start date and an end date.

Human systems entropy. Soon as you take your foot off the pedal, it all starts growing back again. The processes come back. The controls come back. Things slow down again. Human systems entropy.

My personal belief is you've got to always have people in organizations whose job it is to keep that entropy at bay and have ownership of the system of work and clearing impediments from the path of people. And then engagement goes up because people are actually able to do their jobs.

So to recap, first of all, focus on outcomes, better value sooner, safer, happier. Number two, achieve big through small. Think big, start small, learn fast. Number three, invite change rather than inflict change. Number four, the leadership team are team number one. Number five, build the right thing, lean portfolio management. Number six, build the thing right, minimal viable compliance, speed and control. And then number seven, you're never done improving. It's continuous improvement. It's not a program with a start date and an end date.

Thank you.