The DevOps Conference pregame: Helen Beal

[Helen] (0:00 - 1:14)

Werner Vogel said it, “In DevOps, you build it, you run it.” I prefer, “We build it. We own it.” Because that shows more autonomy.

[Marc] (0:14 - 0:28)

Welcome to the DevOps Sauna, the podcast where we dive deep into the world where software, security and platform engineering converge with the principles of DevOps.

[Darren](0:29 - 0:32)

Enjoy some steam and let's forge some new ideas together.

[Marc] (0:34 - 1:10)

We are back in the DevOps Sauna. It's Marc again and I'm so happy to have, I think I could say, one of my heroes or at least somebody that's inspired me a great deal. This is a pregame podcast for the DevOps Conference, which is coming to Scandinavia.

It's going to be in Copenhagen on November the 5th and Stockholm on November the 7th. But we have one of our keynote speakers, Helen Beal, is in the sauna with us today. Hello, Helen.

[Helen](1:10 - 1:14)

Hi, I'm so happy to be in the sauna. Thank you for inviting me

[Marc] (1:14 - 2:03)

Right. Welcome. And I have my lovely and talented cohort, Mr. Darren Richardson in the sauna as well. Hello, Darren. Afternoon, Marc. Good afternoon

So, Helen, I became aware of your work when I learned about value stream mapping and value stream management and started applying those to help my customers identify where their bottlenecks are, understand where waste is produced in their organization, and help them understand that if they are going to work on a transformation or try to make things more efficient within their organization, that they first need to understand really what are they doing to create value and what are all of the steps involved.

And, could you please tell us what is value stream mapping? What's the difference between that and value stream management? And, you know, give us a baseline to start the conversation today.

[Helen](2:03 - 4:16)

I'd be delighted to do that. So, value stream mapping has its roots in information and materials flow diagrams. So, some people trace it back as far as the 1400s into the Venetian arsenal, but more commonly we track it back to Ford and then Toyota with the TPS, Toyota Production System and the advent of lean in the 1950s in Japan.

And that's where the mapping part of it started. But what happened in the 90s, 1990s, is a gentleman called James Martin wrote a book called The Great Transition. And he started to talk about a set of practices of which one was mapping, where an organization would use the value stream concept and think their organizations of value streams and actively on a day to day basis manage their organization as value streams.

And then what's happened since then is we've had DevOps and we've had 15 beautiful years of DevOps and we've achieved ever such a lot, but in many respects we also have quite a long way to go. And some of the data from things like the state of DevOps reports from Puppet, I think it was 2021, was showing us kind of a little bit of stagnation in terms of organizations' ability to get from the medium levels of performance to the higher levels of performance. So, value stream management is having what we often term a renaissance because we've done all this stuff in DevOps.

In particular, we've created DevOps toolchains and they've become fairly mainstream now and fairly well established in many organizations. And what they're effectively doing is providing telemetry across the digital value stream. So, they're making our digital value streams visible in a way that we weren't able to ever do so before.

So, the difference between mapping and management is mapping is a component part of management. It is one of the practices within management. Other practices include continuous inspection and adaptation, the ability to organize around value streams, the ability to assess value stream capabilities.

So, if people were to go to the value stream management consortium website, they would see a resource there, which we call the value stream management implementation roadmap. And that quite nicely sets out these different practices that we use. So, in your experience, what was the trigger that got organizations wanting to map their value streams?

[Marc] (4:17 - 7:19)

I'll tell you about my recent experience after I learned about value stream management properly was that I had customers that were looking to not only improve the efficiency of their software development, but they wanted to start doing things like implementing strategic configuration management, such that instead of being able to deliver into a single product or do a single market, they wanted to be able to have variations of that product and teams deliver a product into multiple markets.

And I started looking around for tools to help understand what are the parts that need to change in order to be able to have a core product with different types of variants. And I came upon value stream mapping and applied it kind of immediately because what I did is I took typical DevOps toolchain type of steps, and I looked at you have different types of customer input that you might be getting from the field and you might be getting from product management and you might be getting from partners. You need to process those steps.

You need to value them. You need to look at different types of, you know, is it customer journey or what type of customer value there is, get some type of forecast of the return on investment, get it through all of the different steps of going through refining the ideas in backlogs, getting them into sprints, testing them, delivering them, getting all of the different types of compliance issues like scanning and things like that, and then being able to deliver as a baseline so that the company would first understand how are they delivering software today before that they could start to look at how are they going to deliver software tomorrow when they have more complexity and more variants. And I said, aha, value stream mapping tells me a process for looking at those different types of steps. And then I started to understand, okay, some of the steps are taking longer than others.

Some of them involve handovers. Some of them involve lean wastes. Some of them are creating value where some of them are just having great wait times for approvals or things like this.

So it was like I had a customer need, which wasn't even completely directly related, but then applying value stream mapping, I was able to put all of those steps into place. And then on the management side, what's interesting to me is like if I take a step back and think of the way that you framed the problem space that or the opportunity space that DevOps has provided these integrated toolchains now. So we can essentially put markers or metrics points within the toolchain in order for us to understand in an actionable real time basis, where are the longest times happening within, you know, like the Dora metrics, for example, if we're looking at, you know, cycle time, or if we're looking at lead time, which part of lead time takes the longest?

What if it's just getting out of product management that takes the longest? Or what if it's getting it refined that takes the longest? Those would be the areas that we would need to focus on.

[Helen](7:19 - 9:38)

It's such an important point you're making as well, that we have these different points that we can measure to and from. In our first year of our state of VSM research at the Value Stream Management Consortium, we've done three years to date. In our first year, one of the things we tried to tackle that year during or through some micro research was the variation in the market on definitions of lead and cycle time.

Because Dora chose the definition, and you can read all about it in Accelerate, I'm sure you have, but the audience can read all about it in Accelerate, that they chose the definition of lead time to be from co-commit to production, specifically because they knew that the fuzzy front end was very difficult to measure. But when we have, and that's kind of like our standard DevOps definition of lead time. But when I've been working with the Value Stream Management Consortium, I've met a whole cohort of our community that come from a very strong lean background, and they have a different definition of lead time and a different definition of cycle time.

So it gets quite complicated. Because some people say, well, cycle times, from the moment we have an idea to when it's delivered to a customer, and you can get different practitioners arguing with each other over those definitions, which isn't particularly helpful for anybody. So one of the things that we've tried to do at the consortium is do and visualize exactly what you've just described, that when we see something as a value stream, and we know we have all these different steps, you can actually start and stop the measurement from wherever you want.

And this means that the definitions of lead and cycle time no longer become important, because what you're saying is, I want to measure from the change approval board number one, and then I want to measure how long it takes me to get to the sprint cycle three, if people are working in those kind of like iterative sprint cycles. So it's a really important point. And I think something that we can only really discover when we start understanding that value streams exist and being able to see them and have the tools to measure them.

But I wanted to ask you a question relating to this, based on a conversation I was just having with a client in Germany before we got together today, which was they were saying that they don't have value streams. What I was trying to explain to them is that everybody has value streams. It's really a matter of whether you've learned to see them yet or not.

So I wondered if that was your opinion also, and if so, how you would help somebody identify or describe what a value stream is and how you would help them see them in that case?

[Marc] (9:38 - 10:35)

What a wonderful question. Thank you. The idea here to me is when I always start with the operational value stream, and I think that that's, you know, when you go back to the 1400s, I don't remember exactly what it was.

I can see the illustrations from the book, but I think we were actually talking about operational value streams in the earliest idea. And that is the Venetian arsenal. Yeah, exactly.

So what are you selling? And what are you taking from raw materials and putting together into something that has greater value? So the operational value stream in software, selling licenses, selling services, in selling insurance, in insurance companies, setting up bank accounts, being able to send out bills for things, shipping beer across the world, whatever those are, those are the operational value streams.

And if we can identify what the business is, then it's oftentimes one or more is a product line of value stream.

[Helen](10:35 - 10:40)

For me, a value stream is anything that has a customer. So anything that delivers a product or a service.

[Marc] (10:41 - 11:30)

Absolutely. So great. So when we identify we have a customer and we are delivering something that they are paying for, then there's our operational value streams.

And how do our development value streams feed that? Are we making better beer? Are we making a different type of insurance policy that covers things in a different way?

Or are we opening up a channel so that a customer, maybe car dealers would be able to sell insurance more easily from the, or policies more easily from the desk of the car seller to the insurance company, like opening up a new channel. That's a new operational value stream. And the development activity of that is the development value stream.

And anytime we're introducing a new product, that was a development value stream.

[Helen](11:30 - 15:08)

Yeah, we have quite a lot of debates actually about the way to classify different types of value streams and whether developmental and operational is obviously very popular, particularly with some of the agile at scale frameworks. I think some of the issue that I have around splitting value streams into development and operation relate back to, in my heart, I am DevOps. So I want to connect development operations.

So I feel sort of intrinsically uncomfortable when we try and separate those two things. So in the foundation course, there's a really nice slide that we have actually, and it's not quite talking about development and operation, but it is talking about the concept of having an idea and developing a concept of products and then putting it into production. So the example we always use is Heinz tomato ketchup.

So the idea is you define a recipe, you test it out. You say, this is the perfect tomato sauce and you design a bottle and a label, and now you've got your product. So that's your design.

And now you put it into delivery. So with Heinz tomato ketchup, you're now producing thousands, millions, billions of that instances of that exact same product. And that's how traditional manufacturing has worked.

But there's something quite different in the software world in that we have what we call long lived products. And I'm doing some research at the moment with the state of project or the state of the industry from project to product. And the world is moving from waterfall to agile.

The world is moving from project towards product. And this idea of having long lived products, when we have a long lived product, what we're actually doing is enhancing it. So every time we do something, it's different.

We might make a billion changes, but we're not making a billion exact same bottles of Heinz ketchup every time we do something that's different. So in software, it looks different. And when we do these enhancements, the amount of time we spend on design then becomes that much bigger compared to the proportional time that we spend in production, because we're redesigning it every time.

And also we've invented DevOps toolchains. So we've got continuous delivery. So we've shortened that, putting it into production time.

So it does look quite different in the digital world. And this is one of the things we get challenged at quite a lot of consortium actually. People say, well, you're really focused on digital value streams.

And a lot of our value streams aren't digital. And I say, yes, but we live in a digital economy. If you want to strategically differentiate yourself in a digital economy, you need to focus on those digital value streams.

They've got to be the strategic part of your business, which leads me to my preferred way of classifying value streams, which is as core and supporting. So in my idealistic utopian world, I like to inhabit my core value stream is one that is delivering to the ultimate customer that is paying for my service. So if that's Netflix, that's your TV viewer.

If you're a bank, it is your customer, whether that's an individual buying a mortgage or whether it's a company investing in your company vehicles that help people make money through investment vehicles. And then your supporting value streams are the value streams that are supporting your core value streams. So that could be, for example, if you've got a cloud infrastructure platform team, that would be a supporting value stream.

If you've got a DevOps toolchain team or a DevOps toolchain, a DevOps team that is supporting multiple teams, that would be your supporting value stream. Marketing, HR, finance, also probably supporting value streams in the wider organization. And this is one of the big challenges I think we have in value stream management and as a whole in the digital economy is recognizing the relationship between our digital teams and the rest of the organizations that we've traditionally kept quite separate.

So I think I'd like to ask you what you think my typology of value streams into core and supporting.

[Marc] (15:09 - 16:17)

This is a wonderful conversation because I felt for a moment that I was in fear of actively arguing against DevOps for a moment, because still the core value stream, you came around and you labeled this beautifully, the ultimate value stream that customer is buying your service from. I paraphrase it just a little bit. And when you described supporting, the cloud info, the DevOps toolchain, marketing, HR, we can talk about the digital sales channels.

That's cool. What I didn't find was where's the enhancement part that we talked about before? What I called in, I think this was not my idea, operational versus development value stream.

The development value stream would be trying new versions of the recipe, doing canary releases on that or focus groups or whatever, putting the new version of the recipe into production, maybe understanding how well it can be produced in many different markets, because there could be different things with the supply chains or something like that. So where does the enhancement part of the value stream management fit within core value stream or supporting value stream?

[Helen](16:18 - 17:34)

It's in either or both of them. So they're in DevOps. We, Werner Vogel said it, you build it, you run it.

I prefer we build it, we own it, because that's more, shows more autonomy over the product. And it's a bit more end to end in my mind than just running it, doing quite a lot more. So the core value stream is responsible for all the ideation.

So it's responsible for those MVPs, those experiments, and it's responsible for the day to day operations of its value stream. The same for the supporting value stream, but they're different products in the business. One is a product that is end user or consumer facing or external customer facing.

And the supporting value stream is the internal customer facing value stream, but they're still responsible for the MVP, the experimentation and the day to day running. Now this aligns quite nicely actually to my very good friends, Matthew and Manuel's team topologies work. So they talk about their different types of team topologies and they have the stream aligned team.

Now their stream aligned team is the equivalent of my core value stream. But I just talk about supporting value streams and they talk about complex subsystem teams and platform teams and different types of team topologies that way. I imagine you're a pretty big fan of team topologies as well.

I think most of us in the industry are.

[Marc] (17:35 - 19:43)

Absolutely. Matthew was on the stage with us in London actually a few months ago. Yeah.

I completely get it. I really like this idea that the thing that I'm still kind of struggling with in DevOps, like we had a conversation today with a customer and it's how do we transform a company to understand that you build it, you run it is taking the, or we build it, we own it is now taking the responsibility for actually ensuring that the customer is receiving the value through something that, and I'm not talking about operationally keeping the servers running and operationally answering the phone when something's broken at three in the morning, but understanding the customer experience, understanding the commerce flow of the customer journey and getting a team that might be a complicated subsystem team to understand how they fit within a core value stream now and kind of make that leap in transition. If somebody suggests something simple, like you start giving people, putting people on call for when the systems are having trouble, but that's such a small part of it.

And I think a lot of the times when we talk about, you build it, you run it, it's about just making sure the cloud infrastructure is there and it's still working. And if I break something in production, I have to fix it, but it's not including the actual, the front end of the customer journey and how the customer actually is receiving their value. And are the teams actually getting telemetry that lets them understand, are the customers behaving in the way that the user story suggested that they should, and the design tried to get them to do, but the customers just are ignoring the feature or they're not getting the telemetry to be able to take that.

So I think this is one of the things that we're facing with customers a lot is how to get the teams beyond the, we build it, we own it, and into the, we actually understand the whole journey and are able to add the value we have as domain experts into creating more value for our customers in the core value stream that the customer is actually journeying through.

[Helen](19:44 - 25:43)

So there's a few different things going on in this conversation. One, I'd like to dwell for a few minutes on the difference between a customer journey and a value stream. And then the other, I'd like to talk about the duality of a value stream from a flow and value realization perspective, and then the kind of behaviors that help us understand end to end what value realization looks like.

So for this first part there, let's talk about customer journeys and value streams. So one of my very close friends and one of the value stream management consortium's board of directors, Steve Pereira, I believe is also joining us at these events. Steve and I started a series of blogs a few years ago now with the consortium, which we lovingly called, is this a value stream?

And I think we started with release management and it's like, we go, is release management a value stream? Is incident management a value stream? Is onboarding a value stream?

And one of the ones we did was, is a customer journey a value stream? They're very, very similar. And I absolutely think all organizations should understand the discipline of mapping and understanding both their customer journeys and their value streams, but they are different things.

Your customer journey is like an external in view of how your customer finds you, falls in love with you, buys your product and builds a long lasting relationship with you. Your value stream is your internal view of how you do work and how you deliver the best experience to that customer to make them fall in love with you. So they are different things, but they are intrinsically important to get both of them right to be a successful business.

So when I talk about the duality of value streams or value stream management, and I talk about flow and value realization, I'm talking about efficiency and effectiveness. So what I'm saying is that we need to get our customer the thing they want as quickly as possible in order to compete effectively. So we have to be able to beat our competition.

We have to disrupt and not be disrupted. So we have to have speed. We have to accelerate our delivery, but we also have to make sure that our customer is getting the right thing because time to market isn't very important.

If we're pushing stuff out the door, like a feature factory, but it isn't stuff that anybody ever wanted or likes or finds useful, then we're wasting everybody's time. So the value realization part is so important to make sure that we're delivering the right things, that we're delivering that excellent customer experience, not just delivering stuff at speed, but it's the right thing. So when we talk about value realization, and then this is like not the core topic often that people talk about with value stream management.

It's something I'm trying to encourage people to talk about more. And it's something we study extensively in our annual research because we ask people things like, when do they start defining value in their products? That conversation we just had about all these stages in the value stream that you can measure from, there are also different places that you can start thinking about why you're doing the thing you're doing and what you want the outcome to look like in terms of customer experience.

So a lot of people in the traditional project world didn't ever really do it, or they'd have some very high level idea about what they thought the project might deliver. In my, I often talk about my, I did already my idealistic utopian world, we would have a value statement in every PBI or every product backlog item or user story or use case that you've described. So we would know what we expect to happen when we push that change into production.

And we would measure the impact of that change. And this is another question we ask in our research, when do people measure how value has been realized by the customer? Do they do it at the point of deployment?

Do they do it a week later, a month later, regularly? How do they describe what they expect to see? Because we want to see it described as an experiment, always.

Experiments aren't just for product development, they're for every product enhancement we're doing. We should always be trying different things out and getting that feedback. But we should know what we expect that feedback to look like.

And that should be empirical. And by which I mean, it should be quantifiable. So it should have a number and a time on it.

So for example, we're going to deliver this feature and we expect 10% of our users to have adopted that feature within a week of us deploying it. So that kind of thing. So this is another area where our DevOps implementations have become so important.

And the fact that we live in a digital world and a digital economy, not only do DevOps toolchains in that digital environment give the ability to instrument and emit telemetry throughout the digital value stream, allowing us to see it, see something that is largely invisible because software is largely invisible compared to manufacturing pipeline. It also allows us to see the impact of what we do in a way that we haven't been able to before. So this is where we open a debate up about value realization metrics.

So people are traditionally talking about the long-term effect of doing something on their revenue and profit. For me, these are very lagging metrics. They don't tell us much about that customer experience in the moment.

What they're doing is telling us about how that customer felt later on, like whether they wanted to continue buying our product, continue subscribing to it, whether they liked it enough to tell us their friends about it, or whether they warned their friends never to go near that company with a barge pole, because what they do is just awful. But in our digital world, with our websites, we have the ability to measure all sorts of things around traffic usage, conversion rates, bounce rates, basket sizes, all sorts of different digital metrics that tell us real time what our customer is experiencing. And sort of, I think getting back to your part of your original question is how do these teams do value realization?

What they need to do is write those experiments in their granular pieces of works. Remember, in Agile, we're breaking things down into very small batches and write them as experiments using digital measurements that tell them about the customer experience of their digital product that they're producing. Am I visualising something that is impossible for people or do you see some of your customers doing some of this now?

[Marc] (25:43 - 29:55)

There's this kind of thing we were just talking about yesterday. And as I came up through Agile, and we were doing Agile-like things in the 90s, and when I first started getting proper training, and I learned about a user story, and everything to me about the customer requirements, I tried to express as user stories, because there's that third part, the so that I receive value. And then, you know, epics, features, tasks, subtasks came along.

And to me, they were still all user stories. But everybody forgot about the user story. And they forgot about the value in crafting these in so many organizations.

And I tried to bring it back up and say that where is the value in the epic? And is it being described there? Where is the value in the feature?

And are there user stories that are actually looking in multiple angles, multiple degrees about how different types of users or the same user performing different types of actions receive one or more types of value from whatever that feature or epic or PBI or whatever kind of are created. So I don't see nearly enough of this at any level, including the user story level, which to me was kind of like one of the core early tenants of describing the value for the user action type of thing. So I like as well a lot about the idea of so we're trying to promote experimentation in DevOps all the time throughout a lot of our customer work, and some customers are getting better at it.

We had a little bit of talk in the pregame that I did a an exercise and we another one of these coming where we invited companies from different sectors together and worked on a kind of high level simple synthetic value stream where we had a telecom company and we had a video streaming company and we had a couple of different types of software companies, even a defense type of contractor there. And we looked at the different steps in creating software within their organization. We looked at the better practices, some of the steps we looked at the pathologies, and we played around with a couple of the things that we learned was where design would fall within the value stream and where experimentation would fall within the value stream.

One of the things that I was doing as a strong example was I was linking experimentation to production, trying to say that if we are able to experiment in production, then we can learn if the customer behaves in the way that we expect them to before we go and start creating or spending more time investing in these types of features that we want, in your example, 10% adoption in for a week or that type of thing. And I really like the idea of creating more clear value statements that can be experimented with actual users in production or what have you and trying to get more focus on this because I think it's generally lacking across many of the organizations that we talk to from Fortune 500 down to SMEs and startups, that they're not actually looking at the impact of individual PBIs or changes.

And the example here that I was actually talking about today, we have a DevOps assessment. It's very well productized in Eficode and we look at culture, we look at testing, we look at architecture and infrastructure and lots of different things. But the company that scored highest on it was, I believe this is public, so I'm going to say it out loud anyway, was Unity.

They got 98 out of a hundred. And one of the things that they do, they actually have screens in their offices that link developer commits towards revenue. And I employed one of these guys for a while.

He was a young guy who started at Unity early. He has a really nice airplane, but it was kind of like one of the greatest things that I could think of in terms of there's value if you actually think, are you able as an organization to take individual developer contributions and look at them in terms of actual kind of revenue generation? So I went to round and around on that one a little bit.

[Helen](29:55 - 31:34)

No, but you gave me a very specific example of an organization that were able to do what we were describing, which is to see real-time the impact of their work at a very granular level. It's something that I know from my clients, they all want to do it, but it is easier for some clients than others. And it relates again to what we were talking about earlier about the we build it, we own it philosophy.

So you've probably heard, I'm sure you've heard the product managers and product owners are mini CEOs. So when I talk to people about thinking of their team, owning their value stream, I encourage them to also try and own their profit and loss, their P&L. And a lot of technical people look at me like I'm a bit mad to begin with, but I remember having this conversation about five years ago with a gaming company that I was working with.

And for some reason we had to keep moving rooms around the offices, you know, a bit like pre-pandemic and they were overbooked and someone else had booked that room. But we walked between two of these offices and one of the guys went, Oh, I just realized that we can do this today. And it just took them to realize that they were measuring their revenue on a real time basis.

Now it was a bit easier for them because they were a gaming company and it was relating to specific sporting events. So they were able to tune into, you know, they would focus a product on say horse racing, and then it would be the grand national and they would deploy that feature and they could see a direct increase of the revenue coming in and usage and all those other numbers. But, you know, for a core value stream, it's going to be easier probably than a supporting value stream, but that doesn't mean that these principles don't work and we shouldn't be trying to practice them at these more granular levels for sure.

[Marc] (31:34 - 33:14)

Yeah. I spoke about this recently as well. I think it was from amplitude.com that had an infographic about the journey to becoming a product team. And this product team with a mini CEO was the highest or second highest of the, their kind of maturity model for this, which I think is really interesting because most of the product owner, you know, the joke about product owners still remains, well, I don't really have a product and I don't really own anything in an awful lot of organizations still today where the elite performers, yeah, they have become mini CEOs now and have, you know, even P&L.

And I think that that's a huge paradigm between even the mid performers and elite performers today. Helen, I wanted to ask something. So one of the things that is so valuable about your work is that not only do you work as a practitioner and you work directly with companies in order to help them, but you write books and you have, you do all of this public facing work, speaking and all of these other things.

And I'd like to ask like a little bit about the path towards becoming, you know, a public facing person and doing this type of work. I always want to encourage people that would like to share their work to do so would like to get up onto a stage and tell their story and their way of seeing things. So would you like to tell us a little bit about how DevOps became important to you, about how value stream mapping and management became important to you and maybe how you developed into someone who, you know, writes books and goes out and speaks with people on podcasts like this in stages around the world.

[Helen](33:14 - 41:24)

I'll try and keep it kind of short. It's probably a bit of a long story. I guess the speaking part was kind of born out of necessity, like lots of these things.

I'm not sure that many people want to get up on stage, particularly in our industry, where I think we're probably quite a high instance of introverted people. I've been watching the Dallas Cowboys cheerleaders series on Netflix in the last couple of days. And one of the things I was like, oh, wow, these people have very different brains from what I do.

You know, they just, you know, they want to audition in tiny outfits in front of hundreds of people and then go and do that in front of millions of people. So I think a lot of people probably wouldn't say, yeah, I want to go and be a speaker. But what happened to me is that I did an English literature degree.

I didn't know what I wanted to do there. I temped a lot when I was at university. It tended to be for tech companies.

And I went and didn't know what I wanted to do with my degree. So I carried on temping and long story short-ish there, I ended up at IBM as a temp in the sales teams. And I saw the sales teams and what they were doing and thought it was pretty interesting and managed to get myself a job there at IBM and then went into a startup a few years later, just in the dot-com bubble.

And we were focused on e-commerce and e-procurement solutions at the time. And then I moved on from there and got involved with a set up a software reselling business and a related services business. And we were working with website development and a lot of, basically it was part of the IBM partner network and IBM bought Rational, another brand, which had all their SDLC tooling in it.

So not only were we dealing with the admin side, so the web front end side, we were also dealing with the SDLC side. And that then led me to a place where I got involved very just specifically on release management. So with a company that had developed their release management solution for Lloyds Banking Group and spun out of Lloyds Banking Group.

And that's really where I met DevOps and enjoyed DevOps very much, enjoyed the cultural aspects of it as well. And I've always enjoyed being sort of at that front end of what's happening in our industry. I think it's one of the most exciting things about working in information technology is how fast it's moving and how many things get innovated.

So I was involved with DevOps and then I left that organization to start up another organization. So now you're getting the idea that I've got a bit of a pattern going on, like I'm a serial scrappy startup. So quite like that environment of really, you know, trying something new and building something out of nothing.

I'm not a great person in a large corporation. It doesn't really suit me. I'm not, I don't have an awful lot of patience.

So bureaucracy can, I can find very difficult to deal with and things like that, which is obviously quite prevalent in the larger and older organizations you tend to deal with. So I was still more on the sales side at this point, but I became, or I got a relationship with the DevOps Institute for their DevOps Foundation course, which was quite new. And we also developed our own DevOps assessment also.

And I was having conversations with prospects like Lego and they were saying, but you'll come and deliver it at our headquarters in Billund, won't you? And I was thinking, but I've never done consulting, but yes, I'd really like to come to Lego in Billund. And actually I had Daniel Breston, my colleague with me, who is a very experienced consultant.

So we went and did that work together. And similarly, I had a prospect, half a mantis in Switzerland who was saying, but you'll come and deliver the course, won't you? And I was like, okay, I'll put my big girl pants on and learn to be a trainer.

And that's kind of how that happened. And then I spent nearly 10 years training and consulting in DevOps with very large companies all around Europe, Middle East, Africa, which was extremely enjoyable. And I learned a huge amount, but we were in scrappy little startup mode again.

So one of the things that happened is people would offer me to speak at an event about my experiences with my customers or my customers would come to events. So Lloyd's Banking Group and I and Lego and I both all spoke at DevOps Enterprise Summit at various points. And it's effectively kind of a free way to get one to many when you're in scrappy startup mode.

So it's like a sales opportunity. So trying to make our business work was what taught me to be brave enough to get on stage. And yes, the first few times it was difficult and it was a bit of a mind over matter.

But the one thing I'll say to people that think that speaking is something that they want to do and it'll be useful for them to either promote their own business or build their own personal brand. The more you do it, the easier it gets, the more familiar you become with the feelings that your biology, your biological makeup is set to save you as you go into this sort of fight or flight mode. So you start to learn what that feels like and you start to preempt it.

And after a while, it eventually just goes away and it just becomes part of what you do. So yeah, that was my path to there. And then DevOps is what introduced me to Value Stream Mapping.

Daniel that I mentioned earlier, Daniel introduced me to Value Stream Mapping conceptually. He was a lead practitioner, a lean practitioner as well. And we did our first Value Stream Mapping exercise together at a client of ours, Vocalink.

And I kind of fell in love with it. And then the DevOps handbook came out a few years later. And that really validated what we were doing because it really talked about Value Stream Mapping as an exercise that really helps with DevOps journeys.

And we were discovering that as well. It's incredibly useful in so many ways, mapping because it gets people in a room and you start to collaborate visually on what you're working on. And actually, it's incredible way of helping people understand what DevOps practices are because you look at the current state map and when you build that future state map, you start saying things like, what if we do testing earlier?

What if we automate some of our security testing or try and up the levels of skill that we've got in security in each of our development teams? So you basically are introducing all the DevOps practices as ways to get to that future state that you wanted to. But I was discovering a couple of downsides with Value Stream Mapping.

One was that whilst the feedback I was getting was that it was so powerful in the room that day. And I would make sure that when we left that room, we would have a future Value Stream Map and we would have a hypothesis backlog of actionable items that people could do to get them moving to that state. When I'd go back and visit that customer later to see how they were doing, I would frequently find that very little had been done.

The other thing that I was finding is that people were really struggling with metrics and what metrics to use and where to get them from and how to measure them. And it just seemed like a huge mountain to climb. So one of my writing jobs is with InfoQ.

One of the advantages of writing for something like that is you often get press passes to events. So I went to the DevOps Enterprise Summit in London in 2019 and I wanted to write an article on Value Stream Management because it was this new thing that was coming out. And I met a few of the Value Stream Management people there, including Jeff Kyes, and it was a bit of a meeting of minds.

And I did have my slide at the time that I took to my customer presentations at the bottom there. It said, optimizing the flow from idea to value realization, which is basically what we're doing, Value Stream Management. But it was an epiphany moment for me.

It was like this Value Stream Management, different from mapping, this idea that I can now use the data that we've got to visualize this value stream. So I now no longer have to get a bunch of people in a room again, expensive people, expensive time. And that's really what was stopping people moving forward with their future value stream maps, was that inability to motivate or mobilize those people to do the work again.

But as soon as we have that data available at the touch of a button, we can continuously inspect and adapt it in our sprint cycles or whatever ways of working cycles we're using. So that really was how the consortium was born. And that is what continues to fire my passion for all things Value Stream Management today.

[Marc] (41:25 - 42:18)

Really cool. And I love the closing here. It's like, one of the things that we try to do in so much of our system development is we try to understand how are we going to measure the outcomes in the design of the system, and doing your future state map so that you can manage the flow, I think is a really, really neat way to think about when you're doing the initial mapping, and then you create this future state and this hypothetical backlog, keeping in mind that we want to be able to measure it so that we don't have to come back and do it so that we can actually steer it in real time in the future.

I think that's really cool. Helen, thank you for coming. I can't wait to see you in Copenhagen and in Stockholm at the DevOps conference.

It'll be November the 5th in Copenhagen, November the 7th, 2024 in Stockholm. Thank you for coming to our pregame and spending some time in the sauna with us.

[Helen](42:19 - 42:26)

I'm also super excited. Thank you for inviting me to the sauna. It's been wonderful. Can't wait to see you in Scandinavia.

[Marc] (42:26 - 42:27)

Awesome.

[Darren](42:27 - 42:38)

And thank you for joining, Darren. I hope you enjoyed the ride. Yeah, it was quite enlightening.

I just don't think you should interrupt smart people when they're talking about what they know. So it's quite good to hear your two's back and forth.

[Marc] (42:39 - 42:52)

All right. Thank you. And we'll see you next time in the sauna.

We'll now give our guest an opportunity to introduce himself and tell you a little bit about who we are.

[Helen](42:52 - 43:14)

Hi, I'm Helen Beal and I wear a lot of hats, so bear with me. This might take a little while. I'm the CEO of the Valley Stream Management Consortium.

I lead the ambassador program at PeopleSert, which includes DevOps Institute, ITIL and Prince2. And I'm a strategic advisor for a few different companies in the industry and the ways of working in DevOps coach.

[Marc] (43:15 - 43:22)

Hi, I'm Marc Dillon, lead consultant at Eficode in the advisory and coaching team. And I specialize in enterprise transformations.

[Darren](43:23 - 43:29)

Hey, I'm Darren Richardson, security architect at Eficode. And I work to ensure the security of our managed services offerings.

[Marc] (43:30 - 43:36)

If you like what you hear, please like, rate and subscribe on your favorite podcast platform. It means the world to us.