Prioritize DevOps and Agile outcomes, not transformation

LAS VEGAS -- Digital transformation, invariably, carries some level of baggage. You can deploy different tools, but the people who follow processes are harder to change. You can't buy buy-in.

Here at the DevOps Enterprise Summit, much of the discussion relates to culture and the IT organization, from how to win the hearts and minds of executives to convincing project managers and developers to change their daily tasks. Technical team members can have a hard time seeing the forest for the trees; they focus on their individual development, test and other responsibilities rather than the concept of business value.

Jon Smart is a partner and business agility lead at Deloitte, an international management consulting firm. He has counterintuitive advice for businesses that want to scale Agile or implement an Agile transformation: Don't.

"It's a bit like an organization wants to hang a painting, [and] Agile is the drill [which creates] a hole in the wall, in order to hang the painting," Smart said. "So, if you do an Agile transformation, it's like doing a drill transformation; you end up with a wall full of holes, but no painting going up."

Smart has hands-on experience. He led the way on enterprise-wide Agile, DevOps and continuous improvement initiatives in his previous role, as head of ways of working at Barclays Group.

He recommends that development teams and project managers focus on DevOps and Agile outcomes, not process changes. With the proper guardrails in place to protect the business and a focus on key DevOps and Agile outcomes, he said, development teams are motivated in the right direction. Smart keys in on five outcomes in particular:

• better
• value
• sooner
• safer
• happier

A half-baked digital, Agile or DevOps transformation might boost one or two categories, but at the expense of others. A focus on Agile outcomes and freedom to express creativity, within boundaries, can spark the necessary technical task and process changes naturally.

Organized human endeavor needs to be good at emergence, where you don't know what you're going to build; you don't know how you're going to build it; you don't know what people want.

"You're incentivized to increase quality, flow, happiness and safety; and they balance each other out, because you can't artificially game the system," Smart said. "If you game the system, one of [those criteria] goes up and the others go down. So, they balance each other out."

In the podcast, Smart characterizes Agile outcomes as intrinsic motivation for tech teams, and empowering. He also shares how rigid, unsupportive leaders can quickly undo all the progress a high-functioning organization makes toward process improvement in a digital transformation.

"There might be someone who is quite open-minded and empowering, and [then] someone more traditional comes in, who is more command-and-control," Smart said. "Those organizations, I see them go backwards. They go backwards very, very quickly."

At its core, he argues, software development must be fluid and adaptable to meet customer needs. It's a description that dovetails well with the Agile mindset.

"We're now in the age of software and digital, where the very nature of what we produce is different every single time," he said. "This is the big shift, because organized human endeavor needs to be good at emergence, where you don't know what you're going to build; you don't know how you're going to build it; you don't know what people want."

Listen to the podcast to also hear Smart dive into how DevOps meshes with security and compliance, a growing concern in the age of increasing cyberattacks.

Editor's note: Smart spoke with site editor David Carty. The transcript has been lightly edited for clarity and brevity.

First of all, what do you hope to gain out of conferences like this? You present at shows like the DevOps Enterprise Summit, and I imagine you have a couple different objectives when you come to a show like this. So how are these types of conferences useful to you? And what do you get out of them?

Jon Smart: In short, shared learning. It's such a fantastic community for sharing learning, and it's both give and take. I think it's great to have people who step outside of the boundaries of their organizations they work at. They come and share the things that have worked, the things that haven't worked and the lessons learned. So, you're kind of being an attendee [even as a speaker]. I just love -- it's so much learning in such a short amount of time.

You get to see the patterns that repeat and the anti-patterns that repeat. The things that generally tend to work are more principle-based rather than practice-based, the types of approaches that work. The give is about sharing your own experiences as well, because otherwise you have these bubbles of learning in companies -- people are not sharing [knowledge]. There can be a bubble of awesomeness in an organization, but if people don't talk about their bubble of awesomeness, it's going to stay in the bubble -- it's a bubble effect. So, it's about it's about sharing.

You're a member of the DevOps Enterprise Summit programming committee as well, right? How do you go about trying to assess DevOps trends and cultivate a curriculum around that? And how do you basically cull it all down into something that's understandable for attendees and useful for them?

Smart: So, Gene [Kim, founder of IT Revolution], comes up with some themes, and, as a programming committee, we discuss and agree on the themes each year. We try to have some variety in the topics, the types of talks. As Gene spoke about in the opening on day one, Gene shared the percentage of talks per topic. We tried to make sure there's a good balance between ops, biz-tech divide, leadership and so on -- and repeat talks as well. I think repeat talks are important because you get to follow organizations on the multi-year journey. In my personal experience, a lot of the learnings come in year three and year four and year five -- not in year one and year two. We try to make sure there's a balance, we try very hard to have as much diversity as possible in the speakers -- we look out for that. Increasingly, [we're] trying to get new people up on the main stage who haven't spoken on the main stage before. So, now, some of the repeat speakers are speaking in breakouts [sessions], trying to get some new storytelling happening at the conference. It's a super hard job because the quality of all the submissions is so high, and there were so many of them. It's a really good problem to have. It's great to see the DevOps Enterprise Summit getting bigger and bigger and bigger each year. It's a really great community.

It speaks to the ubiquity of DevOps now, and how some of these success stories are emerging out of the show and becoming full circle and coming back to inform other success stories, right? What were some emergent themes that came up in your talks with Gene around developing the curriculum for this show? Were there any topics in there or trends that were surprising to you, or particularly interesting to you?

Smart: A couple come to mind. Spanning the biz-tech divide is, really, [one topic] I feel quite strongly about, because this is not something that one should be doing in isolation in information technology. It's our business. It's not the business; it's our business. It's working together in multidisciplinary teams where your tribal identity is the value you're producing. Your tribal identity is not your job role -- that's the old way of working where your tribal identity is, 'I am IT.' The modern way of working is, 'My tribal identity is mortgages, savings, helicopter engines, hotels, whatever it is the company does.' So, that's that's one.

The other thing I'm quite interested in at the moment, and I spoke about yesterday at the DevOps Enterprise Summit, is around risk and control and compliance -- GRC, [meaning] governance, risk and control. Increasingly, I'm seeing conversations and an awareness that compliance needs to change as well. There's been lots of well-publicized examples recently: British Airways, Marriott, Experian, Capital One. [There was also] the NotPetya virus in 2017 that took out Maersk, Merck, four hospitals, six power stations, 300 companies, 22 banks -- ATMs weren't working; your credit card wasn't working.

So the implications of cyberattacks are clearly getting higher and higher every day, as companies more and more become information technology companies. The need for a mindset shift in compliance is super important, because it isn't about just trying to keep people out to the perimeter. You've got to assume that the attackers will get in, past the perimeter, and it's then being able to identify that, lock it down [and] minimize the damage when someone gets in.

You've worked in the fintech space, you understand the needs of some of these customers, you work with them. Now, they're clients for you. Can you explain what they need out of a DevOps implementation or methodology? What are some of their needs in this space in particular that might differ from, say, a startup or somebody that doesn't have that kind of regulation around their business?

Smart: My personal view is that every company is a regulated company, unless you don't have any client data whatsoever, and you have no credit card details. If you don't have customers, then you're probably not regulated, but then you're probably not in business. So, every company is regulated. My personal view is it's the same. It doesn't matter whether you are an organization of 10 people or 300,000 people, you still have a responsibility around the personal data that you have, and the fines are getting bigger and bigger. The GDPR legislation in Europe affects all companies globally, if you have European customer data. British Airways was fined 183 million pounds recently for a breach of customer data.

Obviously, the larger the company gets, the more people are involved. In my experience, there is more bureaucracy. There are more years where the controls have just accumulated over time, where you've got 100 years or 300 years of audit points, and each time someone satisfies an audit point, it introduces a new control. The landscape does get quite complex and complicated, and it tends to be a culture of compliance over risk, risk appetite. So, what I mean by that is, check box -- just basically following the list, tick box approach, without actually having a risk appetite conversation. Especially for larger firms, it's important to not take a one-size-fits-all approach.

It's a difficult task to scale Agile in an enterprise, you were just talking about that a little bit. There are all these different Agile scaling frameworks. There are all these different books and podcasts and techniques, what have you; yet it's something you were able to manage quite well at Barclays Group, a huge global organization. Everyone's journey, everyone's needs are going to differ. No one-size-fits-all approach, as you mentioned. But what would you try to impart on an enterprise struggling to scale Agile to that level?

Smart: Two things. If you want to scale Agile, don't. Descale the work first. Nail it before you scale it -- get it working in the small, and then repeat. It's an S curve adoption over a multi-year time period; it's not linear. You have to keep the gradient low to change to start with, because you have the most impediments: the most inertia, the fewest people that understand it. It gets exponentially easier as time goes by, because you've created social proof; you've created proof points in your organization.

The second thought is, if you want to do an Agile transformation, don't. Focus on: better, value, sooner, safer and happier, because that's the job you're hiring -- Agile, agility, DevOps, systems thinking, theory of constraints, design thinking, etc., etc. That's the job you're hiring [them] to do. It's a bit like an organization wants to hang a painting, [and] Agile is the drill [which creates] a hole in the wall, in order to hang the painting. So, if you do an Agile transformation, it's like doing a drill transformation; you end up with a wall full of holes, but no painting going up. An example of that is Nokia Mobile: they were scoring 99% on their 'How Agile are we?' test, and it didn't help Symbian, [their mobile OS]. It didn't help Nokia Mobile. I've made this mistake in the past as well, where a particular part of the business was Agile, but it wasn't having a material impact on the end-to-end customer experience and time-to-value, because of blockages elsewhere.

So, in my experience, the pivot here is when you focus on the outcomes that you're trying to achieve -- 'better' is quality; 'value' is value; 'sooner' is throughput, lead time and flow efficiency; time-to-learning is 'sooner;' 'safer' is control, compliance -- Agile, not frAgile; and 'happier' is happier colleagues, customers, citizens and climate, because it's not at any cost to society or the planet or to colleagues. Organizations that [don't do this] well, as the State of DevOps Report shows, they reduce their lead time; however, quality goes down and happiness goes down.

That tells the story right there. I imagine focusing on the [Agile] outcomes like you're talking about, it sends a clear message to the workers too, right? It's not, 'Hey, we're adopting this Agile methodology or this DevOps methodology that has all of these different ideas and concepts around them,' but [instead], 'Here, we're going to focus on these specific areas that deliver value to the business and help clarify your work a little bit.'

Smart: Yes, and you're empowering people to use their own brains to figure out how to improve on better, value, sooner, safer, happier. So, actually … this is where happiness goes up. As your engagement levels go up and you have a more rewarding -- you have a more humane existence, because it's not all the giver, all the taker and follow the process. What it is, is within guardrails so that you don't fall off the edge and you don't leak customer data and whatever else, you're empowered. In fact, you're incentivized to increase quality, flow, happiness and safety; and they balance each other out, because you can't artificially game the system, because, if you game the system, one of [those criteria] goes up and the others go down. So, they balance each other out. Then, what I've found is, that's super empowering. You have intrinsic motivation, because you're intrinsically motivated to choose for yourself, how you learn to improve on those things.

One particular example, it wasn't about Agile at all. What worked for the culture and the history for this particular business area was smaller Waterfalls, because there was baggage around the A word: Agile. There'd been three previous failed attempts of trying to inflict capital A, Agile -- very prescriptive, Scrum master product owner, stand-ups, retrospectives. Typically, what happens is, the new labels are used, but it's the same old behavior underneath. People are still doing five iterations of analysis, and five iterations of development, and five iterations of testing, and calling each other Scrum masters and product owners. So, instead, focus on the outcomes. In that particular case, it was smaller Waterfalls. Eventually, it got to what you might call Agile, but without coming at it from a lack of intrinsic motivation, infliction of Agile.

And without giving the workers those nightmares of remembering how it didn't work the first time around. One word I've heard in several conversations here at the conference so far is: trust. It's a central DevOps concept, trust between the business side and the tech side, workers across different spectrums. It's a central DevOps concept that comes up in employee Net Promoter Scores, the Westrum Typology model, and even in Gene Kim's new book; it comes up in The Unicorn Project. We've talked about the ideas of DevOps and Agile on a massive scale, but how do you specifically address the issue of improving trust with IT personnel?

Smart: Does it need to be only IT personnel?

Well, I suppose it's across the business.

Smart: In terms of terms of organizations delivering value, better, sooner, safer, happier, I would say it's just people. So, on trust, I think this comes back to the guardrails. So, you have to have this kind of minimal viable compliance -- #MVC. The better those guardrails are -- and they're right-sized, they're not one-size-fits-all, they're context sensitive. It's about people over process over tooling. It's about conversation. When you've got those guardrails in place, then that gives teams more freedom, and there can be more trust, because it's hard to fall off the edge.

This is something obviously, financial services, like a lot of industries, is purely based on trust. We are trusting an organization with our money, which is no longer physical, it's ones and zeros on the disk somewhere. We're trusting, you know, just like paper money is still trust -- In God We Trust -- and being able to turn up to a central bank and redeem it for gold -- except you can't. So therefore, you've got to have those guardrails.

In my personal experience, the more you give trust, the more people behave with trust. People raise their bar. ... 'If this is a nanny state, and, you know, I can't do this, this and this without asking permission, or I'm not going to be trusted.' -- people don't raise their game so much as when they are trusted. Obviously, there will occasionally be someone malicious. So, again, it's about, as I was saying earlier, expecting failure or expecting a criminal attack or malicious activity, and then being able to identify it quickly and deal with it gracefully.

For mature DevOps adopters or high-performing DevOps adopters, based on the trends you see, how do you advise those clients? How do they continue to optimize and accelerate in a way that maintains these values that we've talked about?

Smart: Again, focus on the outcomes you're trying to achieve. In my experience, across a number of companies, the words better, value, sooner, safer, happier, clearly apply in every context. So for an organization, feel free to use whatever words work. However, quality, value, flow, safety and happiness I've yet to find -- you wouldn't drop one of those. I haven't found one yet that's been missing. Maybe, in a year's time, they'll be another word there, I'm not sure. That's a never-ending journey. When you focus on those things around quality, flow, safety, happiness, when you focus on those things, it's a never-ending journey. You're never done; it's continuous improvement, like Toyota [is] extremely good at. It's continuous improvement.

Human systems, entropy, as soon as you take the foot off the gas, the controls come back in, the bureaucracy comes back in, it's just human nature. It's a bit like gardening. If you stop weeding your garden, the weeds will grow. In the past, what we've done is, we've let the weeds grow, and we've had to do a slash-and-burn type approach, where we then slash and burn the garden. I spent a load of money on a really large program to do a great big -- capital T -- 'Transformation Program,' and then we leave it again. It surprises me, how few organizations have people whose job it is to continually be a servant leader, to support improving the system of work -- which is what I do -- and help organizations with this. To have a relatively small number of people who are the servant [leaders] is to support teams, people who are trying to get stuff done.

Some of the impediments are bigger than teams can deal with. There might be organizational impediments, like the change lifecycle, for example, like compliance, that bubbled up, and there are some people who, in a certain manner, will take that on, work with the right people, get the sponsorship from the executive committee and clear those impediments. The lead of it is leaning on better, value, sooner, safer, happier. It's leaning on the latest insights and learning from other companies around ways of working. So, I think it's super important to have a relatively small number of people whose job it is to do that.

And is this what you're seeing the high-performing DevOps adopters are doing generally?

Smart: Absolutely, and I think combine that with a leadership culture of encouraging experimentation -- and there's no such thing as a failed experiment; it's just learning. Even if the experiment doesn't go the way you thought it was going to go, you've learned a lot from that. So, it's having leaders with that mentality and also safe-to-fail experiments -- you don't want to bet your company on an experiment. To quote Frederic Laloux, he wrote Reinventing Organizations, 'The consciousness of an organization cannot exceed the consciousness of its leader.' I see this a lot, where there are leaders who are encouraging that right culture of experimentation and improvement, and that's all it takes. All it takes is setting that tone of, 'We will recognize you for stepping out of your comfort zone and going for continuous improvement.'

Also, what I see a lot, is organizations where there's a change in leadership, and there might be someone who is quite open minded and empowering, and [then] someone more traditional comes in, who is more command-and-control, less empowering, more, 'Do what I say.' And then those organizations, I see them go backwards. They go backwards very, very quickly. It takes a long time to move forwards, and it doesn't take very long to go back again.

Can you train up the command-and-control people? Is that something that's inherent within them if they just receive so much negative training over the years that it sticks with them? Or can they progress to a spot where they get it, and they adapt their behavior?

Smart: I think humans have a limited velocity to unlearn. People have a limited speed to unlearn. Some people unlearn quicker than others. I think it's not so much about negative training. It's about what has led certain people to be successful and get to where they got to. Certain people in certain organizations where the cultural norm is a certain cultural norm -- for example, command-and-control -- that maybe has enabled some people who've been recognized and rewarded and promoted based on, 'I get stuff done.' However, [they] get stuff done at any cost; typically, any human cost. And if there are other, more senior leaders who are of the same mindset, then maybe that goes  unchecked, or it's like, 'Well done, the dead wood are leaving the firm,' or whatever it is. So, it's hard for a leopard to change its spots, and there is a limited velocity to unlearn and relearn. My view is, it's not about 'resistance' or 'convincing' -- those words should not enter the vocabulary. It should be 'invite' over 'inflict.' It should be about inviting change. So, from my perspective, if a senior leader doesn't want to change, or doesn't want to change the culture, or better, [value], sooner, safer, happier -- then that's fine. We don't need to talk. If, at some point, you do want to deliver better, [value], sooner, safer, happier, across all of those measures, not just one of them, then let's have a conversation. And, dear leader, you might be part of the problem. But, I guess, it has to be invited. Coaching has to be invited. That's a precondition. That can't be inflicted.

Yeah, you can't force that upon anybody. Are we at least seeing fewer leopards?

Smart: I think -- are we seeing fewer leopards? We're seeing, in terms of the leopard changing its spots, we're seeing more and more organizations who are on the path to continuous improvement. We definitely are either on, or gone past, the tipping point now, where now it's just the norm, new ways of working -- Agile, DevOps, digital transformation -- because, at a macroeconomic level, we've gone [past] the age of oil and mass production, where humans had a competence in mass producing the same thing 100,000 times.

We're now in the age of software and digital, where the very nature of what we produce is different every single time. This is the big shift, because organized human endeavor needs to be good at emergence, where you don't know what you're going to build; you don't know how you're going to build it; you don't know what people want. So, it's not like building 100,000 Ford Model Ts; it's emergent. There is definitely -- we're on or past the tipping point. I think we're probably -- we're way past the early adopters and the early majority. I think we're into the late majority -- we're definitely into the late majority now. There's still a long runway of organizations who are firmly in the late majority and the laggards in the diffusion of innovation curve. It's kind of becoming table stakes now.