00:00:00

My name is Sharon and I work at as an agile and DevOps enterprise transformation coach at T-Mobile. As you may know, we are, uh, uh, approaching to the DevOps enterprise semi scheduled on October 13 to 15, and, uh, um, to prepare for those, we are, uh, uh, we invited the experts, speakers, and authors to answer some questions about their talk, their talk. Uh, today I have Janetta and, uh, smart, thank you very much in that Dan, for being with us today. So for those who don't know Jonatan, but I'm sure you all know him in the India trial and DevOps space. Jeanette has been leading, um, business, uh, GDT adoptions across the world for nearly 30 years. He led the new ways of working globally for Barclays bank, where John and his team won their best internal team. I try to walk in 2016 today, John leads at the Lord's business at GDT global practice, helping organizations. They give a better value, sooner, safer, happier, and based on his unique experience. John wrote a book that's coming out on November 10, sooner, safer, happier anti-patterns and patterns for business agility. And John will be speaking at the DevOps enterprise semi all October 13th, 2015, 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 organization and technology code challenges, you should definitely registered welcome John. It's an honor to have you, uh, would you like to add anything to this introduction?

00:01:50

Thank you, Sharon. Thanks for inviting me here. Um, no, I think, I think you've covered it all. Actually. I don't think there's anything, anything more to add.

00:01:57

Okay. Okay. Thank you. So today I want to focus on your new book sooner, safer, happier anti-patterns and pat for business activity. Again, it's coming out fairly soon in November 10. So this book provides an indispensable guide for leaders who wish to run an agile organizations and who wished to transition to a more agile and DevOps organization at scale, actually. And, um, I like to use, uh, to describe the book I really like to use this French expression means, well, you can't go around this book. If you 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 liked this one in particular because you introduced a lot of concepts that I haven't read about before. So, um, the first question, and to set the stage in a nutshell, what is the better value sooner, safer, happier.

00:03:05

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 batteries. Quality value is value sooner is lead time, time to market, time to learning, uh, safer is, um, things, InfoSec, cyber, GDPR, data, privacy trust, you know, not leaking customer data and PR is happier colleagues, customers, citizens, and climates, because it's not a case of, um, you know, more for less at any cost. Um, so that, and that really, that really in my experience is that the job that, you know, agile or agility or dev ops or lean is being hired to do is to get better outcomes. Um, and in my experience, those words balance each other nicely quality value flows, safety, happiness, better value, sooner, safer, happier.

00:04:09

Yeah. Thank you very much. That's very true, actually. And I love that you include the happier as well. It's becoming more, more and more important in organizations, right? To care about the wellbeing of their employees to drive engagement and happiness at work and of the customers as well, actually. So it's a mocha based on that. Quincy foods, it, despite Quincy foods and patterns are truly transformation and are principle-based the transformation more successful than a transformation based on the prescriptive methodologies or complex framework based on your experience.

00:04:49

So it's an, it's an, it's an interesting question. And you know, the book is a collection of patterns and anti-patterns, so it's worth just touching on that for a second. Um, an anti-pattern is something which is likely to give you a headwind rather than a tailwind it'll, you know, 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. You know, it's not binary. There is no best practice in the emergent domain. Um, there are patterns that are usually successful in anti-patterns that it usually make, make your life harder. Um, 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.

00:05:48

There is no, there cannot be any such thing as one size fits all because it's not, it's not a case that there's lots of, you know, identical copies of everybody doing the same thing with the same history and the same collecting identical culture and everything else. Um, so it's about, it has to be principled and it has to be about values and principles. Um, and then it's a case of taking the right approach in the right context to maximize the outcomes. You know, so it's, it's hashtag all frameworks, not hashtag no frameworks, you know, it's, it's picking, it's picking, it's having a toolbox and it's picking the right tools from the toolbox to suit the unique context.

00:06:30

Thank you very much done. Yeah. This is where information. So in chapter two, you share scaling patterns and you say scale at GDT, not agile. And then you add vertically then sideways. I love the way you describe how to slice and scale Betsy Kelly. Can you describe what that means and how can we do that?

00:06:56

Yeah, so, so the, the, the pattern here is to D scale the work before you scale agility. So if you want to scale agile, don't, you know, my advice would be don't D scale the work first, and then scale agility rather than scale capital a agile would be my advice because it's, you know, it's a repeating pattern. It's a fractal pattern, um, in terms of, in terms of ways of working and, you know, autonomy and teams. So the scale, the work it's quite likely that in a traditional approach, you know, there's probably part of the problem is there's probably too many people for the, 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, you know, it's often what I find is five people are far more effective than a hundred people where in the traditional waterfall approach, there's kind of a hundred people working on it in a linear manner.

00:08:06

And in an agile approach, you can do more with five people. It's those kind of, so D scale the work. Um, and then, um, and then kind of scale it up from there, scale up the work from that. 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, you know, cause if it's grassroots only grassroots hits the grass ceiling, it hits a limit because you need the, the senior leaders in the organization, you will have the ability to move, move people around, move, um, you know, resourcing. I don't mean people. I mean, resourcing, I mean, money, whatever it is, you know, have the ability to make decisions to unblock impediments, prioritized stuff, getting worked on. So you have to have the senior support and also incentivization from, you know, from senior leaders, which is, yes, this is a priority.

00:09:08

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. Um, so you need that. So that the person that works here is starting with the most senior possible leadership team, ideally the executive committee or the board you'd have at least one person on there who is a sponsor, um, to, to, to kind of go first and then, you know, a 18 that person's leadership team. And ideally, you know, the structure here is, is value stream aligned, not, not roles, not role based silos, but kind of end to end value stream alignment. So then you'll have a leader, a leadership team, the next level down for the value stream, and then repeat that. And then from that team, you know, another team, um, depending on the size of the organization and the complexity, maybe there's another team down.

00:10:10

And if you can get that joined up kind of 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, common issue is if you do have the top board, you know, top leaders bought in and, and do you have team bought in is missing the middle. So you get it working like that, you know, top, middle, and bottom and go sideways. So then, you know, pick some other teams fan out, um, and generate social proof. Communicate. Yeah,

00:10:59

Yeah, no, this is fantastic, John and I very much agree with you about, um, the anti-pattern that consists of, uh, leaving out the middle management, right? It's redacted in most organizations and are selling that orderly literature that we can, uh, see about transformation. We focus, we tend to focus on leadership and on the development teams, right on the teams. And there's not enough, um, research, documentation and support, I believe for the middle management, you know, transitioning their goals, helping them to the, to the change, then the, the way they manage needs to be different. And there's not enough work on that. Yeah. That's a, that's a great point. And, um, a question that's like you related about value stream, actually talk about value stream in chapter five, you recommend to move away from local optic optimization and rather optimize for fast flow of safe value and to end. And I like what you say of safe, uh, value, uh, and to win. How do we accomplish that? And what does that mean actually a fast flow. I get it, but safe value into land. And how do we accomplish that?

00:12:11

Yeah, so there's, so there's a few things in that question. Um, so local optimization would be where there's an improvement in ways of working in one silo. So that, and that might be it. And it's, it's possible to improve delivery within it, let's say by 90% dent. However, if the process upstream the, the financial process, the PMO process, the portfolio process is, is very unmanageable. It's still going to be a very slow flow end to end through the value stream. You know, there'll still be, you know, once a year before new initiatives are decided and your work is decided and funded. Um, likewise at the backend, if, as if, um, there is a queue built up for deploying value into a production environment, you know, if, if the value is only delivered once a quarter, if there's some governance committee that only meets once a month or once a quarter, you know, 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.

00:13:20

So that's the local optimization point. So don't, don't optimize locally. You got to optimize end to end from, from, uh, needs identified to needs met, um, theory of constraints applies tier. 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 chain, there's no point to continue strengthening it cause it's not gonna, it's not gonna help. So, um, once it's no longer the biggest impediment, the biggest impediment, it's just moved, identify where it is, alleviate it. And repeat for infinity, your question around the word safe in the, in the fast flow of safe value. Um, that again is referring to information security, cyber data, privacy, um, GDPR compliance, you know, so there are there's there's regulation that has to be complied to, um, in financial services, the PSD two directive, um, for example, there's PCI for anyone who processes credit card information.

00:14:29

So there's the, the there's regulatory bodies, um, where there's regulation that needs to be complied to, but then there's also a company policy and company standards. So on top of the regulation, you know, there's organizations own regulation. Um, so that's what, that's what I mean by safe. Uh, the fast flow is safe. Value is making sure in control, you know, it's speed and control. Um, there is also, there's also a 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 the team's gonna experiment, you know, and teams are more likely to improve.

00:15:14

Right. And I think I did not enter genomic, right, uh, compliance safety in terms of security and compliance and then psychological securing, securing both are almost related. Right. I think it's important for developers to and organizations to know that we working on those both aspects at the same time and one created the other, right. When we work on the security compliance, we actually create psychological safety in development as well. So I have, um, I have a question on, uh, the rules that you, you did mention that, uh, something that's really important according to me, and that we don't talk about enough, uh, about roles. Uh, we need to look at long lead roles. Uh, would you describe, and you identified three of them actually. Would you describe maybe a touch on the three roles and would you describe one of them?

00:16:09

Sure. So, um, three roles at every level, it's the pattern, um, the value outcome lead also known as a product owner. However, I prefer the term value out of lead because that's, you know, I think we've moved, we've moved on from the 1990s. It's not about I own this goddamn product. It's, you know, I'm accountable for value. So it's the value of outcome lead. Um, 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. Um, the scrum master with the scrubbed slaves. This is the team outcome leads in that, you know, and that person is there to help servant leader improve the system of work and, and improve the help, support the team to collectively better team outcomes, for example, better value, sooner, safer, happier, and then there's the architecture outcome lead.

00:17:09

And that person is, um, has the accountability in case of it development, um, has the accountability around the technical excellence and the technical agility, you know, high cohesion, low coupling coding standards, um, extreme programming type, um, principles and practices, um, and technical excellence. So, um, so I think I've described all three of them. Um, you know, just, just to, just to maybe describe the value outcome lead a bit more, you know, that that person should be looking at the leading indicators and the lagging indicators on the quarterly business outcomes or OKR objectives and key results. So, you know, 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, and that helps build the agility. And because, you know, does it look like we're on the right path that, you know, are we seeing the leading indicators move in the right direction if we are carry on, if we're not let's pivot.

00:18:24

Oh, thank you very much. Uh, so, um, that's great. I want to touch on that. What you just stayed on the indicators, right? Leading indicators and measurement. I had the question between the would get back to me. So I love, uh, the measure for learning concept that you introduced in chapter eight and you introduced the measure for learning Anjuna, it's a beautiful graph by the way. Uh, could you tell us more about that concept?

00:18:56

Um, pause, pause, the recording.

00:19:05

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

00:19:15

Sure. So with this, um, measure for learning onion at the center, you've got the data itself, ideally also auto harvested. The next layer around that is you've got metrics. So now your turning that data into 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 the feedback loop. The next level of learning measure for learning onion is, is analytics. Um, 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 insight can you generate from the trend?

00:20:11

And so, and this is where, you know, with agility and quick time to learning the engine to reaction so you can determine causality. So that's that, that's the analytics layer. The next layer is, um, visualization. So this is for example, having some form of dashboard where you can visualize the, uh, the correlations, the trends, uh, where you can mine, the data you can drill in, you can drill left right up down. Um, you can see you teams that are really good at this, or they also really good at this. And what is it that these teams who are got a really short lead time? What is it they're doing that teams with a long lead time are not doing? Um, so that's the visualization layer. And then the outside layer of the onion is, uh, is a, uh, 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, you know, drives your experiments that you run.

00:21:29

Thank you. Uh, thank you very much, John. Um, that's a great, uh, concept, lots of great practices. And I really like what you did with the learning for measure onion graph. It's really a very valuable graph. So maybe the last question, um, I liked what you, you mentioned about, uh, leadership and, uh, the concept of go slower, you know, do to go faster. So I very much agree with that, but, um, in most organizations and transformation, it's really difficult, um, to, uh, for leadership to understand that and to generally want to go faster, why do more and go faster? So how can we educate, uh, leaders to understand that it's really important to invest in a developers for the TBT infrastructure and giving them an investing in giving them the tools that they need to be more effective? How can we better educate, uh, leaders to understand that?

00:22:26

Yeah, so, so the go ghost go slower to go. Faster point is, um, where teams are just going, trying to go faster. And it's just a feature factory. And the focus is on velocity and, you know, churning out features and output. And, um, not surprisingly what happens is that technical debt starts to increase when, when the focus is done, 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, you know, 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. Um, however, it needs to be intentional, not unintentional and often it's unintentional because sometimes some leaders are, you know, cracking the whip, which is kind of like the, a agile done badly around velocity and a feature factory.

00:23:32

Um, so this is the point where it's, it's, you know, 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. Um, you've got new features, you've got failure demand, you've got risks stories, um, and you've got improvement work or tech that remediation continuous improvement. Um, Mik Kersten talks about this as well in his flow framework. Um, uh, Dominica DeGrandis talks about this as well. So if you, if you've visualized the different types of work, and if, if, and you use different colors, assuming you're not color blind, you use different colors. You know, if for every time period, it's always one color, which means all you're doing is feature, feature, feature, feature, feature, feature. Eventually you'll, you'll start to see that, um, there's fewer features getting done and I'll be more defect.

00:24:28

So it won't be blue, blue, blue, cause then you'll start getting some defects coming in and there'll be more time spent supporting in the case of software, supporting it, fixing defects. Um, and, and the, the, it will, it will just take longer. So one way to do it. So visualizing using color and ideally, you know, what you're looking for here is you're looking for, for a little bit of all of the colors all of the time, you know, you're, you know, you're constantly improving, know you're doing some new features, you're doing some risk stories. Um, you know, ideally you're looking for not, not so much failure demand. Um, so visualizing it visualizing what's going on deliberately trying to make themes go slower. So when you show this, it's like, oh my God. Yeah, I see now, you know, 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.

00:25:28

Improving daily work is as important as the daily work. That's one way to do it. Um, the other way to do it is, um, throw examples, you know, examples of teams that are, that have incurred a lot of technical debt and haven't paid it off. Um, Shayna shining a light on that showing leaders that, um, is another way of doing it. And, and again, also I think it needs to be a grownup conversation where it is about business risk. You know, again, there are, there are sometimes there are legitimate reasons to incur technical debt, um, for time to market for learning quick time, quick time to data, quick time to feedback, as long as there is, there's a conscious decision to also pay it off again at some point in the future.

00:26:16

Yeah. Thank you, John. Um, I like a grownup conversation. That's really good. So thank you so much, John, for this sec. I really appreciate your time. And, uh, so again, John John's book is coming out on November 10 and he will be talking at the dev center by send me the schedule between October 13 and 15. So it's coming really soon. So, and he's going to be talking about, uh, leadership and how you do scan a deeper, better, uh, 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 sites. So look for them. He has some wonderful videos and talks and also a lightning talks that are really insightful. So thank you, John. Thank you so much. And I'm looking forward to seeing you at the DevOps enterprise summit. Thank you. Bye.