Lean Business Operations - Dancing Across Silos (#21)

“You will cross some silos, stretch some rules, but in the end, you work together, have joy, and achieve greatness.” - Nikolaos Kaintantzis

In this penultimate episode of the SPCs Unleashed Competency journey, hosts Mark Richards, Nikolaos (Niko) Kaintantzis, and Stephan Neck dive into the dimension of Lean Business Operations within the SAFe competency model. The trio explores the critical role of leveraging value stream thinking to enhance flow in business operations and product development, emphasizing the symbiotic relationship.

Mark starts the discussion by addressing the often-confused concepts of the Operational Value Stream (OVS) and the Development Value Stream (DVS). He shares his experiences with value stream mapping and the challenges of simplifying these concepts for organizations. Niko brings a unique perspective by likening lean operations to Greek dancing, where collaboration and unity lead to crossing silos and achieving greatness.

Stephan and Niko share their favorite techniques for effective value stream mapping, stressing the importance of involving the right people and focusing on a customer-centric approach. They highlight strategies for extending the flow of conversation beyond technology, including starting from the customer's perspective to identify triggers for change and mapping true value streams.

The conversation delves into the challenges of integrating business and technology perspectives, especially when organizations are accustomed to operating in silos. The hosts emphasize the necessity of a holistic view and mutual understanding to drive innovation and efficiency. They also offer practical advice for SPCs, such as getting help from peers, practicing new tools personally before applying them with clients and focusing on taking actionable steps to address bottlenecks.

The episode concludes with a spirited debate on the most relevant Measure and Grow metric. While opinions differ, the consensus highlights the importance of visualizing bottlenecks and promptly addressing them rather than just identifying issues.

References:

The Lean Machine - Dantar P. Oosterwal
Lean Product and Process Development - Allen C. Ward

Transcript

Mark Richards: 0:01

You're listening to SPCs unleashed a shaping agility project that emerged from the 2023 Prague SAFe summit. The show is hosted by Swiss SPCT Stephan Neck and Niko Kaintantzis Dutch, SPCT Ali hajou and Aussie SAFe fellow, Mark Richards. We're committed to helping SPCs grow their impact and move beyond the foundations. Taught during implementing SAFe each week, we explore a dimension from the frameworks competencies. We share stories about our journeys, the secrets we found and the lessons we've learned the hard way. G'day and welcome to Episode 21 of SPC is unleashed. We are nearly at the end of our competency journey. There's a word that I always feel like I don't get to say often enough, which is penultimate. This is the penultimate dimension of the 21 dimensions of the SAFe competency model. And today we are talking about lean business operations. Now the crux of lean business operations is leveraging value stream thinking to achieve better flow in both business operations and product development and understanding the symbiotic relationship between the two. In this show, we're going to dig into two of the most powerful and also often most consumed confused concepts in SAFe the OVS and the DVS, or the operational value stream and the development value stream. And I can't tell you how many discussions I've had in rooms full of experts, where 50 people who are meant to be experts, and you have a discussion about what is an OVS and a DVS, and you get 60 different opinions. So we're going to try and simplify that a little bit. Niko and Stephan are going to share some of their pay for favorite powerful techniques for extending the flow conversation beyond technology and approaching the value stream mapping approaches that enable it. And Niko, you're just telling me in the back channel LinkedIn is not running. Yes, I think so. Oh, and I'm seeing error messages saying, check this stream on your social platforms, but it tells me it's streaming to LinkedIn. Okay, so I'm going to trust it. And if it's not there, it's not there, and we'll see what went wrong later. There's always the podcast, all right, so moving along from potential live streaming technology glitches. Niko, you joined us in the warm up before the show, and you said you weren't feeling very passionate today, Stephan, when you just think about dancing and you went, maybe I can find some passion. After all, what's your special passion in the world of leading business operations?

Nikolaos Kaintantzis: 2:52

Exactly. It was a long movie to find my passion. I really thought, am I passionate anyway at all? And then Stephan said, yes, go to your Greek roots, and you find something at the end. It's really like dancing with people at the Greek style where you hug them and you go together like this, dancing here. What happens there? You will cross some silos, you will stretch some rules or agreements in your company. But at the end, you work together, you have joy and you will achieve greatness. Greek dancing.

Mark Richards: 3:26

Stephan, top that.

Stephan Neck: 3:28

It's always hard to top a Greek who is in full swing, but I think, and it's, it's tying into what Niko said. I love Valley Stream Mapping, and I've seen people crossing those silos. Because no matter if it's a tech nerd, if it's a business people, if it's people who start talking together and surfacing assumptions and then talking about it, and probably we'll talk about that today as well.

Mark Richards: 3:58

So let's dig into Lane business operations and start to unpack obs and DVS a little bit. Now, I've loved value stream mapping as a tool for many, many years, I have been using value stream mapping techniques a long time before I ever heard the words OVS and DVS, and I forget which version of SAFe they started talking about them. It must have been back in around about SAFe three, SAFe four, maybe. And they said, Yeah, there's a book by a guy called Alan Ward lead product and process development. And I went, cool, like I read the book and try and figure out what this is all about. And I opened the book and I started reading. I went, Oh, I recognize this guy. Because years before that, we'd been talking about the lead machine, the Harley Davidson book. And in the lead machine, they kept talking about this mystery consultant who came in and said, when you apply. Playing lean to product development, it's different to applying to manufacturing. And he kept asking them all these Kelly questions. And I started reading Alan walds book, and I went, Oh, you were the mystery consultant. And as a brief book, and I absolutely fell in love with this, like, oh yes. This makes it so clear that they're different things, and it fixes a lot of the misconceptions people have when they think about, you know, the value streams we often talk about in product development blurs all these boundaries, but there's a challenge to it. And the biggest challenge I've felt leaving aside, you know, intellectual stuff, is that when you say development, value stream, most people hear technology development, and that's not at all what Alan Moore talked about. So what are some of your favorite secrets for getting to true development value streams and avoiding that trick? Niko, why don't you take us away?

Nikolaos Kaintantzis: 5:56

Yeah, even more. Mark, also, some people, when they hear operational value stream. They think it's the thing you do in the background, like technical stuff, like, like operations of DevOps, the ops part, so you have dev streams and ops streams, and they don't really realize it's a business operation. So for some people, this wording is misleading. And also development, it's not really tech development. I remember years ago, I was in a scrum master training with Jeff Sutherland in Zurich, when he was younger. He was every year in Zurich, and one of my colleagues ran class with him, and he said he's just now helping a kindergarten doing Scrum. And then I thought, Oh, that's cool, because now your development teams are teachers. Hahaha. And then I thought, oh, wait a second, development is also developing people. It's not only writing code. And sometimes I tell this story to say to the people, development isn't only coding. It's not only it and operation is the whole thing evolve about, about how the trigger from the customer until it gets the value, it's what business is doing. Sometimes in Switzerland, I say the it's the business value stream, even if it's wrong and SAFe, but it helps the people to realize, okay, now, now I got you. Development is really building something that's helping me in my steps to help the customer, and then maybe it's a whole explanation. It's not the word, I don't know. But then it helps. And the other thing, what also helps is, I tell them, the world is much more complex than just these two value streams. Usually it's a network of value streams. It's like the flight path of airplanes. But you need the first step. And this is a cool model to abstract and to do the first step. And that's the way how I try to explain. What about you,

Mark Richards: 7:47

Stephan, I've never tried the kindergarten metaphor personally, but I'm curious what yours is.

Stephan Neck: 7:53

Yeah, it's interesting listening to Niko. I always try to step back a little bit with the people talking about value streams, and at the beginning, I don't care, are they coming from a so called OVS or a DVS, or are they people talking about customers? And I tried to figure out with them, Hey guys, what's innovation and where is the source that triggers innovational work in an organization, and therefore, then you have people on board who lay on the table, for example, how are we perceived as a company by our customers? Where do these triggers start from a customer base? Or, as Jeff Bezos says, There is no technical disruption. There's a customer disruption, right? Do we understand who uses new technology or a different technology in a different way that affects us? So where's the biggest pressure for innovation? And talking on that level is is agnostic, and then you dig deeper and say, Okay, where's where are the triggers for change, and who brings in change? Because if you have a demand on your table, in your development team, most of these teams can't tell you, where does it come from? They say, Oh, we have a demand. We have some some specification we have to do work, but it's important to understand what type of change do you want, and what's the priority? And we all know we talked about it in different sessions. If everything is at the same priority, how do you focus? How do you how do you get lean over the time? And I've learned the hard way, and also by good mentors and teachers and coaches. If you can bring in this customer perspective when it comes to value streams, if you can bring in the triggers and the sources and then start sketching again on a whiteboard, what are the dependencies between. Those priorities and the customer sources, and what's the most important stuff we should do now and then start diving into okay? Is this innovation work now more affecting an obvious or a DVS or even the customer journey, how the customer perceives us and experience the touch points with us as an organization or as an enterprise. That's very helpful, and that's it. That's something we try to do, even before we go into detection of value streams. So the value stream identification, and then you bring on board all those people who have a say, who have some information about that. And that helps us a lot for value stream identification, who should be on board and talking and talk with us. And also, when we talk about value stream mapping, as you mentioned, Mark, bring those people in who have a say, who have some information, as we said last week, okay, as a VMO, bring the people together who have a say, who have some information, and then try to create what is a true value stream, no matter if it's an obvious or a DVS. In the end, it's innovation work that flows through those value streams and is very beneficial, in the end, for the customers and the users.

Nikolaos Kaintantzis: 11:25

And while listening to you, Stephan, I just realized, I think the people don't have to care. Is it obvious or devious? It's somehow a model for us to help guide them finding the way. Oh, now, Mandalorian, that's the way, but it's more for us as coaches, and the model helps, but if you find as an SPC, if you find a way explaining it, or a way to do the workshop differently but achieve the results, then they don't have to care about OVS operational value streams and DVS development value streams. It's a model for us, maybe

Stephan Neck: 11:59

although we are talking about lean business operations, it starts with value stream identification, and we've seen people struggle with which OVS Should we start with? And taking off the pressure going to Okay, customer perspective triggers for change. What's the priority? You can kind of neglect the OVS at the beginning to then find what is a good and true development value stream. There's other starting points than only OVS, right,

Mark Richards: 12:31

I think. And just listening to both of you, it resonated with me, because, let me tell you, I may have obsessed just a little bit about JBS and IVs, and I may have gotten very frustrated because I talk to other theoretical experts, and it's like, you just don't get DBS and OBS, but sometimes there's a tool that's really useful for you, as an SPC that says, Knowing this theory is going to help me ask better questions, but you don't necessarily have to teach your client that theory. And what I heard from both of you is there are different types of value streams, but the most important thing is to find your way out to the customer and start with what is value through the customer's eyes, and then understand the other types of value streams that might be related to that. And it was certainly, I know joy. Can't tell you how many times I've been teaching value stream theory in a enterprise setting, and I say, Okay, well, these two things called DVS and OVS. And, you know, OVS, you can really see it, because the trigger will usually be a customer trigger. The value will usually be customer value, and a DVS, the trigger usually is an OVS, saying, I'd like some value. And the value is the OBS being new and improved as a result of that. And that's the relationship between the two. And they go, oh yeah, I'm kind of getting that. And then I go, if you look at the SAFe big picture, every time you see a value stream. It's a DBS. They go, Oh, okay, so it's just about technology. Well, actually, the truth is that your development value streams can never, ever be useful unless they understand the operational value streams they're supporting. And so great knowledge to have for yourself, not necessarily knowledge you have to inflict on a client, but maybe,

Stephan Neck: 14:24

maybe mark, maybe mark, may I throw in it's, it's probably the challenge we have as a change agent or as an SPC, kind of conveying this, this theory about DVS and OVS, forgetting that we are not only talking about a portfolio of R and D or a portfolio of business. So I like the new patterns of having a combined portfolio view, a holistic view, which amalgamates obvious and devious in a better way. Otherwise, it's again a. The Tech keys against the business or the business against the techies, and they have different portfolio views, which doesn't ease the understanding of of the different types of value streams.

Mark Richards: 15:11

All right, so now that we've decided don't get too caught up in it, but it's useful theory to understand yourself as you know we know that there are different types of value streams. There's different types of value flowing through those value streams, once we started to find our value streams of whatever flavor, let's talk about value stream mapping. Value Stream Mapping is a hugely powerful tool when it's done well and when I wanted to learn it. There was a book called Value Stream Mapping. I think it was by osterling and and this book was basically an end to end guide. This is how you facilitate the creation of a Value Stream Map. And she literally went, these are the people you need. This is the way you set it up. This is the way you do it's a two day exercise. And you know, you need all the leaders of all the steps in the value stream to walk the value stream together. They walk the value stream from trigger to value, and then the second day they walk from value to trigger, and you build a war room representation of it as you go, was awesome. So I finished reading it, and we wanted to create a value stream map with one of my customers, and I talked about this approach, and they went, Yeah, we're too busy. Surprise, surprise. So, you know, I wound up going, all right, I'm going to walk the Value Stream Map myself, and I'll go talk to all the various people. I will build visuals, and then I'm going to plaster a wall with those visuals from my work. And if I can't get them to commit me two days, I can get them to commit to spending a couple of hours processing the value stream map when we're all together, and each person will talk to the bit of it that they were in charge of and how things flow through there. And I have to confess, I've been down that particular compromise a few times myself, but it's always more powerful when you've got the people who own the value stream actually involved in the process of building it out together. So Stephan, what are some of the favorite tricks you found to getting a great failure Stream Map identified and mapped out. It

Stephan Neck: 17:23

probably starts a bit earlier than where it is placed on the implementation roadmap. In SAFe there you say you do have your DVS, or you might have your OVS, and you do a Value Stream Mapping. I like to do it as soon as possible, as you know, we're going SAFe and even maybe before a value stream identification, because I want to detect and explore what is the real world before we dive into an adaptation with the first art, right? So there's two ways. There's bottom up and top down. Bottom up, I ask questions without sketching it, like, where is your gut feeling, or where are your real bottlenecks? And guess what? In the same pit, everyone knows something about that. And I start there bottom up, and then extending as far up the stream or down the stream from where we detect something, and then we find out who should join us. So it's it's more on an invitation based level, and it's growing incrementally over the time, and I don't like to set up in the beginning. How many workshops do we need? Start informally and then add information and structural elements, and all of a sudden, a value stream map appears, and it's only a bit or something like that. And then on top, the other way is I like to challenge leadership, showing me what they understand, what is a value stream, and normally the business has this, this is my business unit, right? And just recently, I talked to to a senior manager, and she said, This is my business unit. And while we started talking, she said, Ah, by the way, but, but outside my boundaries, I need this and that. And I said, Okay, now we talk value stream. We don't talk business unit. We talk again, from the perspective of users, employees and customers, because, like I I'm interested in a car. I want to finance my car. So for example, leasing is not a business unit. Leasing is something that I need to own a car over a certain time, and all of a sudden here, you then start talking to these guys, okay, what are the pressure points, the pain points, and what will be the ideal value stream? What will be the ideal for. Approach in your business unit, and also, if you go beyond your boundaries, hey, let's talk to your peers again. Invitational based, like you said, Mark, we like connecting people. A VMO likes connecting people. That's our job. And as change agents, bring the people together to then paint the picture. And based on that I've, I've seen a value stream identification out of something like a values kind of value stream mapping is much easier, because, again, you know the audience, you know the pressure points, you know the pain points, and that's where you start, and then you deviate away from which obvious should we start? You start where it hurts. You start where your biggest strategic initiative, or whatever is that's one of one of the hints or trips or tricks I would use, or I try to use in every new start of an implementation roadmap.

Mark Richards: 21:01

It's beautiful advice. Yeah,

Nikolaos Kaintantzis: 21:03

I'm so happy. I'm lost in this, in this question, because I thought I was really quite nervous when I brought in the preparation, what my thinking is. And I thought, you will say you're a crazy guy now, Niko, you're too crazy, but I'm happy you're doing something similar, similar things. And I remember I've wrote down, I hope Mark doesn't have a heart attack when he reads this, what I'm writing in the preparation note, so it triggers many, many new pictures. Thank you. Thank you to you both, first before I start with my story or with my how I do it, dear SPCs, we're talking about value stream mapping, not value stream identification. Some people misunderstand it. It's easy to misunderstand because there's value stream in both. And both are workshops, and both can go over days. But in this case, it's about you have your value stream, and now you have to find out the steps and and some data about it. How many, how many of the things go back again or aren't accurate, waiting times and so on and so on. So we are now in the process and try to find out how much blue does it have or not. And in my case, I do really something similar, as Stephan described, and that's also mark described. I don't care about the data in the beginning, and that's the moment where I thought, Now mark will have a heart attack, and I hope he's fine, because he's one of the persons I know who's really best in retrieving data, showing data, and making decisions and helping people make decisions about data. And in my case, I start with the gut feeling of people who are part of this value streams, who are infected, infected, who who has to work in this value stream. And usually they find very fast the bottleneck. They find very fast where the problem is. And that's good enough for the first step, because even if I had detailed data, they don't help me so much. Because when someone says the problem is here, we need two months to have a decision. You have your bottleneck, or one of the bottlenecks, so having people working in the value streams affected now have it affected by the value stream. Those people are important to be in the workshop. And then you have your first step, and it's always one step after the other. You don't have to do the perfect step, one step after the other, and having no data in the beginning and just people enduring the value stream and having problems in the value stream helps you very much. And then you go pain point by pain point, and then you have also the okay to invest in getting out the data. Let's tell you a different story. Last week, or the week before, I had an RT training and one RT, she's, I think, five years RT now, she said she's doing all the data by hand at the moment, because she want to do this workshop, and they have no chance to do it automatically. And I really ask myself, do you really want to do this every day that I need just track it by hand? I think it's a five hours work per day until she has all the data. And then I told her, maybe make sense just to do the workshop and then have the budget to adjust your tools to have the data automatically. And yeah, she wasn't. She didn't felt comfortable with that, because she's really a data person, but I think it's a good first step, and then you have also the okay for investing in having data and having better decisions, but the first but the first step is always better than no step order, waiting for the perfect step.

Mark Richards: 24:30

So I gotta tell you, Niko Kaintantzis All he's relaxed, because in the beginning, you've always just got hunches and gut feels about the data. And if you've got the right people involved in the conversation about the value stream map, you'll get reasonable guesses. One of the biggest things to me is, when you've got a good value stream map, create a kanban that looks the same as your value stream map and and I think that's a step a lot of people. Miss because they go, Oh, I've got a Kanban, and I'm using the official SAFe Kanban, or whatever the case might be, as opposed to going, well, I've got a Value Stream Map. Create a kanban that goes idea to value and has the same steps, and they'll automatically get a lot of that data from the data about flow through my Kanban. So the sorry, Stephan, looked like you were going to say something. I something.

Stephan Neck: 25:23

Yeah, it's interesting. The word data triggers always. What I've learned from Professor acoff, he said a pound, it's the other way around, a pound of information. An ounce of information is a pound of data. You need lots of data to condensate into information, right? And the next step is you need a lot of information to become knowledgeable, and you need lots of knowledge that you start understanding. And some of us might even go the last step, a lot of understanding will probably trigger some wisdom, and for me, keeping that in the back of my head when I do value stream mapping, yeah, you need data as some base. But then the discussion evolves over the time, and that triggers in what pace and what kind of steps we then come towards gaining knowledge and understanding. Because value stream is about understanding as is and also understanding what should be the future state, and not switching all the time back and forth that pays into what you you just said. Mark Right. Gut feeling is good data. That's where it really starts. Well,

Mark Richards: 26:42

so much of the value stream thinking is it's going to be iterative. You'll have a guess, and you'll dig a little bit deeper, you'll get a few more people involved, you'll you'll have a better guess, and maybe you'll put a command in place. You'll have a better guess again, because you start to see things that emerge from the K man system. Probably one other hint from me for an SPC, yeah, if you haven't tackled Value Stream Mapping before, or if you've tackled it and you've struggled, the single best way to get a value stream map is to run the SAFe DevOps. Course, if, if, if I had, like, just an easy wish, it would be rename the SAFe DevOps course to the SAFe value stream course, or something a little bit more carefully thought through than that. Yeah, yeah, yeah, because it's so beautiful to go, you know, get the right people in the room, and I will always go, I want Product Management. I want architects. I want governance people, you know, getting the right people together in the room and running that course. You get to the end of that course, you've got an as is, and a 2b value stream map, and you've got a whole bunch of Best guess data from having the right collection people in the room for the course, and and it's just like the tool that's going to help you do it. The only hurdle you have as an SPC is convincing the people that it's not just a techie thing about CICD pipelines.

Stephan Neck: 28:08

May I second that mark, probably we have to rethink the learning path of an SPC, even of an SPC, T, right? You can teach leading SAFe, if you know the context and the constraints, if you don't have a clue about the value stream people are in there, you're just teaching theory, and you can't map, you can't contextualize, and I'm fully with you. Mark SAFe DevOps course or workshop is the wrong name. We should, we should change that immediately,

Nikolaos Kaintantzis: 28:42

that bisops? No,

Stephan Neck: 28:46

it's probably the wrong discussion. But

Mark Richards: 28:49

SAFe is devsecops

Unknown: 28:54

save the world.

Mark Richards: 28:56

I mean, I, I have, I've toyed with using it as an art launch tool. I've used it a number of times to go there's an art that's stuck, and quite often an art that gets stuck gets stuck because of stuff that's outside their control, and, you know, the bits of the value stream that they don't own. And taking an art that's a little bit stuck and going, well, let's get the right extra people in the room. We'll do this DevOps course together. Often yields good breakthroughs. But every time I do that, I go this would be such a powerful way to do art design, and part of art launch would be to use it as a mobilization tool. I've just never experimented with it. So moving along, let's we've talked about value stream mapping, we've talked about OVS and we've talked about DVS. This is the lean business operations dimension, after all. Now the truth is, why God or not? I think the vast majority of SAFe implementations start in technology. SAFe, and they're technology driven. And there's this moment of LEAP where people try and go, well, let's escape the boundaries of technology. But when they start in technology incredibly often, the perception of why is SAFe here what is Lean and Agile about? It's about fixing technology. They're slow, they're inefficient, they cost too much, make them better, and that's what SAFe or lean and agile. Therefore, when you cross that chasm, to use an overused word, and you start to move into lean business operations, it inevitably means you're going to start fixing the business as well as fixing technology, and hopefully starting to fix the business and technology together. And that can be pretty uncomfortable, very uncomfortable when technology people turn up and go, Hey, it's not us, it's you, as I've seen happen, also potentially very uncomfortable because technology has been a great excuse for business for years. You know, we're not hitting our targets because tech are too slow and expensive. So if you think about leaning into that discomfort and getting to the for me, it's much more about getting to the system's thinking view it was going there are many things working together, and we're going to shift the frame and the size the system in pursuit of new opportunity. Niko, what are your favorite ways for leaning into that? Now we're going to talk about both.

Nikolaos Kaintantzis: 31:29

Yeah, the problem is this us and you. So you have two groups through frontiers, two islands, or whatever, this us and you thinking, and I know how is with you, but usually when I go to my clients business and IT are in separate floors, in one case, they had said separate buildings, the new one for business and the old one for it, because they're in order there, because the computer, the server is there. So and then you have also a distance, and this distance is really a huge problem. So one question will be, how can you now lost my thread. Sorry, I have to start new something beeped, and then I lost my thread. So this us and you this distance you have. How can you merge them to one team? One Yeah, one team is the big the big question. In my case, what I'm doing is I try to have a cross functional release, so there's people who are driving the transformation are from every island you have in your company, so that at least you have some somebody you know, somebody you trust, in this environment. And that's what I try to do regularly. And the other thing you said, Mark, I completely agree with that. The feeling of it was the bad child. It is the one who gets orders you have to do this. And yes, I have to do now. Here's your order. Please do it until then. And then, this is a must date. Please do it until then. And then. It really feels strange when it starts telling you what you have to do. And sometimes it feels like with the kids, when they are young, you tell them, this is the way you have to do, band, your shoes, brush your teeth. And at some point there, get adults, and they try to teach you back and try to explain new things. And for some people, it's It feels strange. For other it's the normal way of going. But yeah, you can just go away from this you and or me and you, or we and you, by just creating a team who speak both languages and have team members you trust. And that's the only way I've seen it works, because when I was a young SPC, I really had problems talking with business people, because I was different dressed. And even if I changed my dress to a nice costume, I still smelled like an IT guy. I had different vocabulary, even if I tried to use the vocabulary, and I was great with business people who originally came from engineer backgrounds or had the engineer background. Meanwhile, I can also talk to banks and insurances, and it doesn't look like an alien just dressed like a finance guy, because I know now much more about finance and their business domain, but I think the tip for an SPC would be maybe we talk later about this, but this really have This cross functional lace team, where everybody speak every language you need in the company. And if it's a team who's saying it, it's not the day, it's just we together. This,

Stephan Neck: 34:29

this highly resonates with my experience. The lace place crucial function, or is a base for a lot of good stuff. And preparing this, this dimension, in this core competency, felt like a bit, oh, we are talking about the broom truck, right? We're picking up bits and pieces of different episodes, and now trying to tie the knots into what lean business operations is. And it. It leads me back to end of 2016 after we launched an art in an enterprise. HR guys showed up and said, Hey, we want to, we want to become agile. Can we start in January? And I said, Yes, but first we have our Christmas holidays, and then let's start. No, no, we want to do pi planning in HR, and that led to an HR art, right? Interesting. So business becoming lean. And I asked them the question, guys, why do you want to do that? It's mainly for tech. Guys, it's mainly for development. And they said, Hey, we are developing stuff that is beneficial for the whole organization, because at the moment, the organization tells us you are skilled, you are good people, but when you show up, you either show up at the wrong time, at the wrong place, or you show up with stuff that is not suitable at that moment. Okay, so how do you how do you tackle that? Again, it's not only technology, slow and expensive or whatever. Bring the people together who have pain points. And I, again, I try to start with what's innovation worth for the business. For example, if the business says we need this and that, then you kind of omit this. Oh, but you're expensive. If you want it, let's invest right? And it's we, as you said, Niko, it's not us. We tell them what to do, but do it for small bucks, right? No, it's worth what it's worth. And this triggers, then again, a discussion, discussion about an end to end life cycle. Thinking, just yesterday, I was in a meeting. We talked about projects and initiatives. We ended up with, Hey, what is total cost of ownership? Do we consider that? Right? So again, that brings together those two different perspectives. In the end, you might find a consensus, okay, what should we do? How do we invest? And we are not talking again about, oh, these tech people are too expensive. We should reduce them and stuff like that. And one of the approaches I'm applying at the moment, and that has, I've learned it also the hard way over the years, is and it stems from those new patterns that we have in the SAFe framework. I'm holding workshops with executives and senior management simply talking about, you want to go Lean and Agile. You have existing boards and meetings and committees. How do we map that? How do we dissolve certain certain boards or meetings, or how do we play certain points or parts of what you should collaborate and talk about into new events, existing stuff? And it's interesting that, again, broadens the view. Like I'm working in government at the moment, there are certain boards. You can't neglect them. You have to participate. You have to play a role. But there's an interface to how we get more lean and agile over the time, even in the government business as a government office, and it's interesting. It's leading to new parts. In the end, yes, again, we talk about OVS and devious and what should we do? Which are to launch first stuff like that, but first do the work in a more holistic way, and and moving away from those finger pointing statements, you are too expensive, you're not on time, you're too late, stuff like that. That will be my advice for for us as change agents.

Mark Richards: 38:54

Ah. So staying with the advice, though, if you think about this dimension as a whole, lean business operations. Well, what have we talked about? Well, we've talked about you need to be able to identify multiple different types of value streams. You need to be able to think about networks and interconnections between value streams. You potentially need to be able to at least understand operational and development value streams, even if you don't try and make your clients understand them, you need to be good at getting people together to do value stream mapping, and you need to be able to go and help business operations who've got nothing to do with building software, apply lean ideas to improve flow, and You're a young SPC, hopefully that huge list of things you have to do for this dimension didn't completely overwhelm you, because it's actually in its potential impact on an organization. It's unbelievably big. So Stephan young, SPC, first stepping into this. To mention, how do you begin to take your first steps of being confident to step into using these kinds of tools and techniques?

Stephan Neck: 40:07

One thing that helped me in those discussions and finding the starting point, are we talking about small innovation on a daily basis in existing value streams, or are we talking big leap innovation, right? Let me start with the small innovation along existing processes, lifecycle and again, customer centricity. It's on the big picture, right? Start with the customer, user journey. Where are the pressure points? Where's the need they trigger, how an OVS should adapt, and then if the OVS adapts, they come up and say, Hey, our digital services or tools are not up to speed. So that's the first advice I would give for small, daily, incremental innovation. And again, starting on the customer and user journey is helpful if you don't feel proficient with that, as we said last time, go to the VMO, go to the operational people and listen, listen, to understand, not to respond, and then you start acting as a change agent. And the big leap innovation, I always, and that's really helpful, bringing in all the design and technical authorities like architects engineering, start with the existing IT landscape. Yes, sometimes we forget that. And what I've learned those guys have awesome Enterprise Architect tools or management tools. And one of our clients, he showed or they showed me, the connections between the existing solutions, like they already did the groundwork, and said, Okay, if we change this one, it has a huge impact on these other solutions. And that also helped us to immediately see clusters of collaboration from a technical viewpoint. So as a young SPC try to find out who has information hidden in certain cupboards or wherever it is, get to these people go into a communication, find out what they already have, and try to find this holistic picture, and then setting your starting point. It might be on a DVS, it might be on an obvious it might even be on a customer or user journey to understand, are we, as Mark said, Do we have the right true value streams, and that affects, then the need what to do and what to initiate and to spark.

Nikolaos Kaintantzis: 42:50

I would like to zoom into one, one sentence you just said, it's a get help. Get help by VMO, by other people. And then when I look back even to my studies, there were two kind of teachers, coaches, consultants. The one type was people who, when they realized they have no idea, they just invented stuff. And people, when they realized they have no idea, they just said, I have no idea. I need to find it out and get help. And I would really, really suggest, dear SPCs, be honest, be yourself, and don't make things up. If you don't have a map, don't, don't design a one map, because the map is always a map of the reality. If you try to, yeah, to make things up, you will get just a Mickey Mouse map and will not help you. So with this, it's for me, important. Know your strengths. Where are they know where your knowledge ends. If you realize, oh gosh, there's also an OVS and DVS. I never read about it, then just admit it, go to a senior coach or hire one, or go to a colleague and get help. So it's really overwhelming this whole value stream discussions, because we have also the business agility. Value stream is also a third one we never mentioned here, because the part of this of this dimension or about this competency. So know where you are, get help from your peers, learn with your clients, learn and experiment by doing the first step and experiment and learn by observing senior consultants. You're not finished after four days training, you really have to learn, learn and learn, so

Mark Richards: 44:26

I gotta add one more, and it really comes beautifully off the back of niko's advice. I always find when I find a new tool or a new technique, is there some way I can practice with it on myself before I'm inflicted on a customer. It's like when I started playing with OKRs. Let me try personal OKRs. If I come across a cool new canvas, I go, can I use that Canvas for something in my own business? Because you learn by using things. And we did a podcast episode on our portfolio podcast with a guy called Casco. Gotten recorded it last week, and he's an expert in strategy deployment, aka ocean can re using the x matrix. And if you've never been near an X matrix, hugely powerful thing, also hugely complex thing. And we're talking with him about how he uses it. And you know it's you need a very big mandate to use it the way it's intended. And he said, Actually, every time I walk into a new consulting gig, I use the x matrix as a diagnostic for myself, as I'm learning about the context, I just fill it in, because it helps me understand and visualize the way the world's working, and it helps me to shape my conversations. And I think that'd be maybe one of the biggest hints I give somebody, if you're new to value streams, if you're new to value stream mapping, everything else, you could maybe just start building these maps as a way of synthesizing your understanding of the system. You don't even have to share them with anyone. They will show you new things, and you can start to ask questions and make provocations based off the insights they reveal to you. And it's a great way to build some comfort with the way they work. And I've seen a couple of people do that. And not long after they start asking questions, people start saying to them, how on earth did you know to ask that question? And they go, Oh, I've got this thing I built. So it's nothing like a practice field to give you SAFety to learn.

Nikolaos Kaintantzis: 46:29

When I when I was a young developer, I was really on the edge on new technologies, and there always tried it for myself first, before I went to the client. And the funny thing was, I only had a knowledge advantage of four hours, so whenever the client came and asked me, How can you do this? So, oh, it's easy. It's that and that and that. And they really thought I invented this technology, just because I tried it out before, and they had the same questions before, and that was really my advantage. It just by doing it myself before, and that's okay now we can do it with the client, and he had the same questions I had the last day. So do it. Exercises with your own context helps you a lot and not do it. It's on without knowledge, just with the client together. Thank you,

Mark Richards: 47:16

Mark. It's time for us to argue about measuring cry.

Stephan Neck: 47:21

Hooray. What do we

Mark Richards: 47:25

got? I think we had about 11 or 12 to choose between today. Stephan, why don't you fix into gear with your selection?

Stephan Neck: 47:36

Okay, we have three clusters in that measurement grow. One is value streams, one is visualization, and one is dev teams. I choose value streams, and within this one process times and delays are made visible and measured, because that's, again, what I mentioned before, from Professor akov. You need data, you need the visualization. You need that data, and for me, then everything follows, but it's dependent on how clever we use the data.

Mark Richards: 48:09

Okay, interesting. I must confess, I had a tough time picking and I didn't go and go, what's the metric? I would have written myself, but I really, I've looked at everything I went really can't decide on one. I chose in the end, bottlenecks, delays and impediments are addressed quickly. And what drove me there was, it's easy to get into a habit of problem admiring. And the question is, with the new things that the value stream view of the world is showing you, are you taking action on them? And it was a bit of kind of chicken and egg in terms of, well, if you're not getting the data, you're not going to have something to act on. But at the end of the day, I've seen a lot of people produce a lot of value stream maps and then never do anything with them. So I entered towards action. What about you? Niko, you went a very different way. Yeah,

Nikolaos Kaintantzis: 49:05

I want to say and the best comes at the end, but I think it's the collection of every every three answers. So I had the same struggles. I want people to address things, but I think they're first to see the things and the easiest way to see so I agree with Stephan, Process Time delays are very important. But I think if you just say this is the one thing you measure, people will say and what's that? How do I measure? And I think mine, it's easier to measure, but it's also easier to ignore. So it's a carbon systems help visualize and limit work in process. VIP showing this is the first step, and then you need more metrics. So I started with getting data, getting feelings, because you see, also, without data, something is wrong in this board, but then it's really important what Mark said, you then have to start doing it. And I'll just say, Oh, we have always a bottleneck here, whining, whining, whining. So no, it's really. Doing also. But then I said, I start with the first step. It's to a freaking Kanban. And visual and limited.

Mark Richards: 50:11

I saw that vote, and to be honest, if the wording on it was a little bit different, I would have gone straight there. Yeah.

Nikolaos Kaintantzis: 50:18

But what wording Do you miss? Yeah, well,

Mark Richards: 50:21

I wouldn't have gone help visualize and limit work in progress. I would have gone help visualize flow through value streams and produce actionable insights.

Stephan Neck: 50:33

Ah, yep. And I think that's the difference between a Kanban board and a Kanban board. Some are just a 90 degree turned to list looks nice. We're busy. And the other one is showing where are the parking lots, the hidden gems that we can improve over the time. And that triggers a team sync, that triggers an alt sync, that triggers a portfolio sync.

Nikolaos Kaintantzis: 51:04

And for me, by not being native English speaking, I don't see these big differences that Mark sees. That's why it was okay for me. But I'm with you. When you explain it, I see why you want to have a difference. For me, it just was okay.

Mark Richards: 51:17

And just while we're on measure and grow, and when I looked at the measure and grows here, I almost just sent an email to the framework team we mentioned at the start of this that many people get confused about operational and development value streams. And actually, if you look at the third cluster here, you see why, because it talks about dev teams as opposed to development value streams. And development value streams have an awful lot more than just dev teams in them. So, you know, traps for the IRS PC don't fall for the common mistakes that even people clever enough to define, measure and grow make. But I'll

Nikolaos Kaintantzis: 51:57

go here with Jeff Sutherland. Development team could also be a bunch of kindergarten teachers. They don't have to be coding people. Development means development and not coding. But then different of a discussion, I think a young SPC don't think about development, not so coding, so that I'm with you

Mark Richards: 52:16

now, Stephan, you actually put pen to paper about a measure that was missing.

Stephan Neck: 52:20

Yeah, it ties into what you just said. It's kind of a conclusion for me, and we hear that quite often. How do we measure maturity? And I say guys, get rid of that maturity thinking we are here and we are done. So we talked about values G mapping and the SAFe DevOps course, which we would like to rename, reveals after two days, a long list of improvement items. And for me, this is how short does it get. Over the time shows how mature you are, like you said, Mark addressing the pain points, the delays and the bottlenecks get into action, otherwise, your value stream mapping is zero. Nicely, we talked about it, but there's no actionable items. There's no action

Mark Richards: 53:10

that's an interesting one, because there's another piece of that, which is actually thinking about your action on improvements as being a value stream in itself. And you could start to put flow and throughput metrics around improvement actions, but then which

Stephan Neck: 53:27

context? Yeah, which contextualizes and and keeps you focused and not just doing improvement, but focused improvement.

Mark Richards: 53:36

All right? So just one sentence, Niko, take us away.

Nikolaos Kaintantzis: 53:42

Yeah, doing a small step, a small step forward, is more important than doing the perfect step toward the perfect direction. It's one step for human No, for me, but a big step for humankind, something like that. Do the small step. Okay? Stephan,

Stephan Neck: 53:57

in summary, lean business operations needs a holistic view of customer journeys, obs and DVS, but not for the sake of doing it, but to create a culture of efficiency and innovation.

Mark Richards: 54:10

Nice. So that concludes episode 21 and our final dimension to talk about is strategy agility. And if you've ever looked at the strategy agility, you will see a very long list of things that get piled into strategy agility. And in fact, we had some jokes between us this week about what were all of the important things to talk about that didn't fit anywhere else. So it's a very broad, ranging dimension in terms of its topics, and we felt, obviously, Ali has been away this week, and last week he's been off on holiday, and then Niko is off on holiday next weekend. But we felt, for the last dimension that we really wanted to have all four of us, so please join us in two weeks for. Got episode 22 where we will discuss strategy, agility, and then we'll start thinking about what we do now that we're done with competencies, and we can start to get probably, into some of the topics we're super passionate about that don't turn up as a dimension or a competency. So we'll see you soon.