Shaaron Alvares

My name is Shaaron Alvares, and I work as an Agile and DevOps enterprise transformation coach at T-Mobile.

As you may know, we are approaching the DevOps Enterprise Summit scheduled on October 13 through 15. And to prepare for those, we invited expert speakers and authors to answer some questions about their talk. Today I have Jonathan Smart.

Thank you very much, Jonathan, for being with us today. So for those who don't know Jonathan, but I'm sure you all know him in the Agile and DevOps space, Jonathan has been leading business agility adoptions across the world for nearly 30 years. He led the new ways of working globally for Barclays Bank, where Jon and his team won the Best Internal Team Agile Award in 2016. Today, Jon leads the Deloitte Business Agility Global Practice, helping organizations deliver better value sooner, safer, happier.

And based on his unique experience, Jon wrote a book that's coming out on November 10, Sooner, Safer, Happier: Anti-patterns and Patterns for Business Agility. And Jon will be speaking at the DevOps Enterprise Summit on October 13 through 15 about leadership and how to lead for better value sooner, safer, happier. So if you want to hear him talk about how you can tackle your organizational and technological challenges, you should definitely register.

Welcome, Jon. It's an honor to have you. Would you like to add anything to this introduction?

Jon Smart

Thank you, Shaaron. Thanks for inviting me here. No, I think you've covered it all, actually. I don't think there's anything more to add.

Shaaron Alvares

Okay. Thank you. So today I want to focus on your new book, Sooner, Safer, Happier: Anti-patterns and Patterns for Business Agility. Again, it's coming out fairly soon in November 10. So this book provides an indispensable guide for leaders who wish to run agile organizations and who wish to transition to a more agile and DevOps organization at scale, actually. And to describe the book, I really like to use this French expression: it's incontournable. And incontournable means you can't go around this book. If you're leading an agile transformation at scale, you have to read this book.

And I read a lot of books myself about agile transformation because of the work I do, but I really like this one in particular because you introduced a lot of concepts that I haven't read about before. So, the first question, and to set the stage: in a nutshell, what is better value sooner, safer, happier?

Jon Smart

So what it's about, it's about focusing on the outcomes, not on agile for agile's sake or DevOps for DevOps' sake. That's where better value sooner, safer, happier comes from. Better is quality. Value is value. Sooner is lead time, time to market, time to learning. Safer is things InfoSec, cyber, GDPR, data privacy, trust, not leaking customer data. And happier is happier colleagues, customers, citizens, and climate, because it's not a case of more for less at any cost.

So that really, in my experience, is the job that agile or agility or DevOps or Lean is being hired to do, is to get better outcomes. And in my experience, those words balance each other nicely: quality, value, flow, safety, happiness. Better value sooner, safer, happier.

Shaaron Alvares

Yeah. Thank you very much. That's very true, actually, and I love that you include happier as well. It's becoming more and more important in organizations, right, to care about the well-being of their employees to drive engagement and happiness at work, and of the customers as well, actually.

So it's a book based on principles. It describes principles and patterns to lead transformation. And are principle-based transformations more successful than a transformation based on the prescriptive methodologies or complex scaling framework, based on your experience?

Jon Smart

So that's an interesting question. And the book is a collection of patterns and anti-patterns, so it's worth just touching on that for a second. An anti-pattern is something which is likely to give you a headwind rather than a tailwind. It'll make a hard job harder. A pattern will likely give you a tailwind, and it will make a hard job ever so slightly easier. You're more likely to be successful.

But it's not black and white. It's not binary. There is no best practice in this emergent domain. There are patterns that are usually successful and anti-patterns that usually make your life harder.

In my experience, inflicting one size fits all, inflicting a prescriptive framework across an entire organization, is an anti-pattern because it's not optimizing for many unique contexts in the company, in an organization. There cannot be any such thing as one size fits all, because it's not a case that there's lots of identical copies of everybody doing the same thing with the same history and the same identical culture and everything else.

So it has to be principled. It has to be about values and principles. And then it's a case of taking the right approach in the right context to maximize the outcomes. So it's #allframeworks, not #noframeworks. It's having the toolbox, and it's picking the right tools from the toolbox to suit the unique context.

Shaaron Alvares

Thank you very much, Jon. Yeah, this is great information.

So in chapter two, you share scaling patterns, and you say scale agility, not agile. And then you add vertically, then sideways. I love the way you describe how to slice and scale vertically. Can you describe what that means and how can we do that?

Jon Smart

Yeah. So, the pattern here is to descale the work before you scale agility. So if you want to scale agile, my advice would be: don't. Descale the work first, and then scale agility rather than scale capital-A Agile would be my advice, because it's a repeating pattern. It's a fractal pattern in terms of ways of working and autonomy and teams.

So descale the work. It's quite likely that in a traditional approach, part of the problem is there's probably too many people for the work that's being done. So you don't necessarily want to just apply an agile scaling framework on top of those existing people, because part of the problem is there's probably too many people. Often what I find is five people are far more effective than 100 people, where in a traditional waterfall approach, there's 100 people working on it in a linear manner, and in an agile approach, you can do more with five people. So descale the work, and then scale it up from there, scale up the work from there.

Now, the point around the vertical point. So in terms of business agility, not just agile at the team level, the whole enterprise, whole business agility: it can't be grassroots only, and it can't be top-down only. Because if it's grassroots only, grassroots hits a grass ceiling. It hits a limit because you need the senior leaders in the organization who have the ability to move people around, move resourcing. I don't mean people, I mean resourcing, I mean money, whatever it is. Have the ability to make decisions, to unblock impediments, prioritize stuff getting worked on. So you have to have the senior support and also incentivization from senior leaders, which is, yes, this is a priority. Yes, this is important. And yes, you will be incentivized to do something here. Because if there's no incentivization and it's not a priority, it's only ever going to be a hobby, really.

So you need that. So the pattern that works here is starting with the most senior possible leadership team, ideally the executive committee or the board. You have at least one person on there who is a sponsor to go first, and then a team, that person's leadership team, and ideally, the structure here is value-stream aligned, not role-based silos, but end-to-end value-stream alignment.

So then you'll have a leadership team at the next level down for the value stream, and then repeat that. And then from that team, another team, depending on the size of the organization and the complexity, maybe there's another team down. And if you can get that joined up, top-down meets bottom-up with the middle included, so that middle management are not left out, in my experience, that's a pattern. That will give you a tailwind.

It will help you on your journey because you haven't left out the top, you haven't left out the grassroots, you haven't inflicted change top-down, and you haven't left middle management out, which is another common issue: if you do have the top leaders bought in and you have team bought in, it's missing the middle. So you get it working like that, top, middle, and bottom, and go sideways. So then pick some other teams, fan out, and generate social proof, communicate. Yeah.

Shaaron Alvares

Yeah. No, this is fantastic, Jon, and I very much agree with you about the anti-pattern that consists of leaving out the middle management, right? It's true that in most organizations and also in all the literature that we can see about transformation, we tend to focus on leadership and on the development teams, right, on the teams. And there's not enough research, documentation, and support, I believe, for the middle management. Transitioning their roles, helping them to the change. The way they manage needs to be different, and there's not enough work on that. Yeah, that's a great point.

And a question that's likely related about value stream. Actually, you talked about value stream. In chapter five, you recommend to move away from local optimization and rather optimize for fast flow of safe value end-to-end. And I like what you say of safe value end-to-end. How do we accomplish that, and what does that mean, actually? Fast flow, I get it, but safe value end-to-end, and how do we accomplish that?

Jon Smart

Yeah. So there's a few things in that question. So local optimization would be where there's an improvement in ways of working in one silo, and that might be IT. And it's possible to improve delivery within IT, let's say, by 90%. However, if the process upstream, the financial process, the PMO process, the portfolio process is very un-agile, it's still going to be a very slow flow end-to-end through the value stream. There'll still be once a year before new initiatives are decided and new work is decided and funded.

Likewise, at the back end, if there is a queue built up for deploying value into a production environment, if value is only delivered once a quarter, if there's some governance committee that only meets once a month or once a quarter, you can have as agile as you like app dev, but very clearly there's not going to be end-to-end flow of value. So that's the local optimization point.

So if it's not the weakest link in the chain, don't strengthen it. Work out where the weakest link in the chain is, strengthen it, and when it's no longer the weakest link, there's no point to continue strengthening it, because it's not going to help. So, once it's no longer the biggest impediment, the biggest impediment has just moved. Identify where it is, alleviate it, and repeat for infinity.

Your question around the word safe in the fast flow of safe value: that again is referring to information security, cyber, data privacy, GDPR compliance. So there's regulation that has to be complied to. In financial services, the PSD2 directive. For example, there's PCI for anyone who processes credit card information. So there's regulatory bodies where there's regulation that needs to be complied to, but then there's also company policy and company standards. So on top of the regulation, there's organization's own regulation. So that's what I mean by safe. The fast flow of safe value is making sure it's in control. It's speed and control.

There's also psychological safety in that word as well. So in terms of leadership, culture, the fast flow of safe value can also be interpreted to mean with psychological safety, which means that teams can experiment, and teams are more likely to improve.

Shaaron Alvares

Right. And I think they're not antonymic, right? Compliance, safety in terms of security and compliance, and then psychological safety, both are almost related, right? I think it's important for developers and organizations to know that we're working on those both aspects at the same time, and one creates the other, right? When we work on security compliance, we actually create a psychological safety in development as well.

So I have a question on the roles. You did mention something that's really important, according to me, and that we don't talk about enough, about roles. We need to look at long-lived roles. Would you describe, and you identified three of them actually. Would you describe, maybe touch on the three roles, and would you describe one of them?

Jon Smart

Sure. So, three roles at every level is the pattern: the value outcome lead, also known as a product owner. However, I prefer the term value outcome lead because I think we've moved on from the 1990s. It's not about I own this goddamn product. It's, I'm accountable for value.

So it's the value outcome lead. And then there's the team outcome lead, also known as the scrum master. However, not everyone does scrum. And again, we've moved on from the 1990s. It's not about being the master, the scrum master with the scrum slaves. This is the team outcome lead, and that person is there to help, servant-leader, improve the system of work and help support the team to collectively have better team outcomes. For example, better value, sooner, safer, happier.

And then there's the architecture outcome lead, and that person has the accountability, in the case of IT development, has the accountability around the technical excellence and the technical agility. High cohesion, low coupling, coding standards, extreme programming-type principles and practices, and technical excellence. So, I think I've described all three of them.

Just to maybe describe the value outcome lead a bit more: that person should be looking at the leading indicators and the lagging indicators on the quarterly business outcomes or OKRs, objectives and key results. So, the pivot from project to product, the pivot from output to outcomes. Teams should be working on quarterly outcome hypotheses. And the value outcome lead is really focused on the KR in OKR, the key results. Leading indicators and lagging indicators of value. And that helps build the agility in because does it look like we're on the right path? Are we seeing the leading indicators move in the right direction? If we are, carry on. If we're not, let's pivot.

Shaaron Alvares

Oh, thank you very much. So, that's great. I want to touch on what you just said on the indicators, leading indicators and measurement. I had a question between, but we'll get back to it.

So I love the measure for learning concept that you introduced in chapter eight, and you introduced the measure for learning onion. It's a beautiful graph, by the way. Could you tell us more about that concept?

Pause. Pause the recording.

I love the measure for learning concept and onion you introduced in chapter eight. Could you tell us more about that?

Jon Smart

Sure. So with this measure for learning onion, at the center, you've got the data itself, ideally auto-harvested. The next layer around that is you've got metrics. So now you're turning that data into some information, and your metrics, for example, could be along the lines of better value, sooner, safer, happier: quality, value, flow, safety and happiness. So now you've got some metrics coming in. You've got a feedback loop.

The next level of the measure for learning onion is analytics, and this is looking at the trends. This is looking at the trend over time of the metrics. This is looking at causality. It's looking at correlations. It's looking at patterns, diagnostics and insights. So what insights can you generate from the trend and causality? And this is where with agility and quick time to learning, then to reaction so you can determine causality. So that's the analytics layer.

The next layer is visualization. So this is, for example, having some form of dashboard where you can visualize the correlations, the trends, where you can mine the data, you can drill in, you can drill left, right, up, down. You can see teams that are really good at this. Are they also really good at this? And what is it that these teams who have got a really short lead time, what is it they're doing that teams with a long lead time are not doing? So that's the visualization layer.

And then the outside layer of the onion is a data-led experimental mindset. So this is having a mindset around really deliberately, consciously using data as your feedback loop, as you should do, to drive experimentation. And that drives your actions. It drives exactly what you do. It drives the experiments that you run.

Shaaron Alvares

Thank you very much, Jon. That's a great concept and lots of great practices, and I really like what you did with the measure for learning onion graph. It's really a very valuable graph.

So maybe the last question. I like what you mentioned about leadership and the concept of go slower in order to go faster. So I very much agree with that. But in most organizations and transformation, it's really difficult for leadership to understand that, and they generally want to go faster: why do more and go faster? So how can we educate leaders to understand that it's really important to invest in developers' productivity, the infrastructure, and invest in giving them the tools that they need to be more effective? How can we better educate leaders to understand that?

Jon Smart

Yeah. So, the go slower to go faster point is where teams are just trying to go faster, and it's just a feature factory, and the focus is on velocity and churning out features and output. And not surprisingly, what happens is that technical debt starts to increase when the focus is on just churning stuff out. Corners are cut, and there's no time to go back and continuously improve, and there's no time to go back and pay off the technical debt.

Sometimes it's a business risk decision. Sometimes technical debt is deliberately incurred, and it's the right thing to do in terms of quick time to market. However, it needs to be intentional, not unintentional. And often it's unintentional because sometimes some leaders are cracking the whip, which is kind of like the agile done badly around velocity and a feature factory.

So this is the point where it's go slower to go faster, or you will just end up going slower anyway. So one way to do this is visualization. You've got different types of work that you're working on. You've got new features, you've got failure demand, you've got risk stories, and you've got improvement work or tech debt remediation, continuous improvement.

Mik Kersten talks about this as well in his Flow Framework. Dominica DeGrandis talks about this as well. So if you visualize the different types of work, and you use different colors, assuming you're not color blind, you use different colors. If for every time period it's always one color, which means all you're doing is feature, eventually you'll start to see that there's fewer features getting done, and there'll be more defects. So it won't be blue because then you'll start getting some defects coming in, and there'll be more time spent, in the case of software, supporting it, fixing defects. And it will just take longer. So one way to do it is through visualizing using color.

And ideally, what you're looking for here is you're looking for a little bit of all of the colors all of the time. You're constantly improving. You're doing some new features. You're doing some risk stories. Ideally, you're looking for not so much failure demand. So visualizing it, visualizing what's going on.

Deliberately trying to make teams go slower. So when you show this, it's like, "Oh my God, yeah, I see now. I see we're spending all of this time on failure demand and just pumping out features, and we're not actually improving the system of work." Improving daily work is as important as the daily work. That's one way to do it.

The other way to do it is through examples. Examples of teams that have incurred a lot of technical debt, haven't paid it off. Shining a light on that, showing leaders that, is another way of doing it. And again, also, I think it needs to be a grown-up conversation where it is about business risk.

Again, sometimes there are legitimate reasons to incur technical debt. For time to market, for learning, quick time to data, quick time to feedback, so long as there's a conscious decision to also pay it off again at some point in the future.

Shaaron Alvares

Yeah. Thank you, Jon. I like a grown-up conversation. That's really good.

So thank you so much, Jon, for this Q&A. I really appreciate your time. And so again, Jon's book is coming out on November 10, and he will be talking at the DevOps Enterprise Summit, scheduled between October 13 and 15. So it's coming really soon. And he's going to be talking about leadership and how leaders can deliver better value sooner, safer, and happier. So please register if you want to hear him talk.

And then he has also several videos that I highly recommend you to watch on the IT Revolution YouTube site. So look for them. He has some wonderful videos and talks and also lightning talks that are really insightful.

So thank you, Jon. Thank you so much, and I'm looking forward to seeing you at the DevOps Enterprise Summit.

Jon Smart

Thank you, Shaaron.

Shaaron Alvares

Thank you. Bye-bye.