Value Stream Management With Helen Beal

Posted on Tuesday, May 2, 2023
Managing work processes across an organization can be a challenge. Shared responsibilities and bottlenecks can cause confusion, stress, and delays. In this episode, we talk with Helen Beal about Value Stream Management, a practice for gathering insights on workstreams from ideas to value realization.


Mandi Walls: Welcome to Page it to the Limit, a podcast where we explore what it takes to run software in production, successfully. We cover leading practices used in the software industry to improve the system reliability and the lives of the people supporting those systems. I’m your host, Mandi Walls. Find me, @lnxchk, on Twitter.

All right, thanks folks. Welcome back to Page it to the Limit. This week we’re going to talk about value stream management. I’m here today with Helen Beal. Helen, welcome to the show.

Helen Beal: Thank you for having me. It’s a pleasure to be here.

Mandi Walls: Awesome. So tell us a little bit about yourself. You’re like the busiest woman in DevOps. What are you doing these days?

Helen Beal: I get bored really easily, so I’ve got lots of parts, all my fingers in lots of pies, however you want to put it. I’m a chair of the Value Stream Management Consortium. I’m a co-chair of the Value Stream Management Interoperability Technical Committee at OASIS. That’s a bit of a mouthful. So I’m practicing learning to say that. I’m also chief ambassador at DevOps Institute and I write and I chat and just talk about all this stuff that I love, which is mainly DevOps and Value Stream Management I think we’re going to focus in on today.

Mandi Walls: Yes, excellent. So tell us about, for folks who are new to value stream management or they’re not really sure exactly what it all means, what is it and why are we talking about it now?

Helen Beal: I think maybe if we start with the kind of customer in mind, the goal really of value stream management is to improve customer experience. And the sub goal of that is to improve organizational performance because it goes to show if your customers are happy, they’re going to buy more of your product or service, they’re going to recommend it to more of your friends, family, colleagues. So your business is going to be more successful. So that’s where it’s coming from. How does it do it? Well, it does it because it improves flow. So by flow we mean the way that we deliver things. So basically getting things to your customer faster. But conceptually, time to market isn’t that useful if what you are producing isn’t what the customer wants. So we talk about time to value or actually sometime, we talk about time to actionable insight because what we want is to be producing the right thing.

So it’s not just about how efficient we can be, it’s about how effective we can be. So at the Value Stream Management Consortium, or I might say the VSMC in the future, just to shorten it a bit, we talk about this duality and the duality being flow and value realization, efficiency and effectiveness. And I should probably mention that it’s not a new thing as well. The history of value stream management, some people draw all the way back to Venice in the 1400s to the Venetian Council. In terms of when humans started to diagram out information and materials flow, and of course Ford came along and then Toyota with TPS in Japan in the 1950s and we started getting more and more sort of visual collaboration around the production of things. And value stream mapping came about and in the 1990s people started to use the term value stream management, but all the way through this it was quite focused on the manufacturing industry. And of course, we work in the technology industry, and so the software industry and specifically these days even infrastructure becoming much more codified and software oriented than ever before with cloud and all of that stuff.

So we’re kind of going on a renaissance with value stream management and it is different in our digital world. It’s different because our value streams are effectively invisible. You can’t walk into a factory and see all of the parts on a conveyor belt and how they’re being pieced together. And another big thing is in digital we have long-lived products. And when we make a change to that long-lived product, it’s a one-time only change, normally. It’s an enhancement or a bug fix. Whereas, in manufacturing, what we do is we design a product like, we always use Heinz Ketchup for some reason as an example.

Mandi Walls: I love Heinz Ketchup. It’s fine.

Helen Beal: Lots of people do. That’s probably the reason. So you design your ketchup and actually my mom used to work for Heinz kind of diverting slightly many, many years ago in Ealing. So she probably did some of this. You design the recipe, you test it, you pasteurize it, you see how long it’s going to last in people’s fridges. You test out preservatives and all that kind of stuff and then you sign a bottle and a label. You price it all up and do all of that and then you start manufacturing it and you manufacture it. I don’t know how many bottles of Heinz ketchup have been made over the years.

Mandi Walls: I cannot imagine.

Helen Beal: Billions almost certainly. But we don’t do that in software. We don’t create the same bottle of thing, billions of times. It’s kind of one of things we spend a lot more time in the design and development phase and much less time in the production and delivery phase. And DevOps has contributed to that as well because we automate that phase using CICD. So we shorten it even more. And in terms of getting that thing to market.

Mandi Walls: Yeah, definitely. It’s been interesting especially over the last 10 years to watch DevOps start to pull and learn from manufacturing, the stuff about lean, everything that Toyota learned like you mentioned in the ’50s and bringing in all that. I talk about automation and all of that stuff emerged in the late ’60s with nuclear power generation and some of these other signal-to-noise and all this other kind of stuff. Super interesting to start gearing up for all these things that other folks have already learned and how they apply to their industry and how we can apply them to technology is super interesting.

Helen Beal: Absolutely. And I used to talk a lot actually about DevOps as a conceptually as a super pattern. And it happened because I was at a show, it was such a long time ago now, maybe even coming up to 10 years, in Germany somewhere. I think it was in Munich and John Willis was there and I did a couple of presentations and one was a repetition of one that I’d done at DevOps Enterprise Summit London that year with Lego and it was about correlations between Holacracy and DevOps. And then I did another one that I’d ripped off. She won’t mind me saying one of my very good friends, Jayne Groll, the ex CEO of DevOps Institute. She used to talk about the harmonious polygamous marriage between Lean, Agile and ITSM and this kind of love child that those three things produce, which is DevOps. So you know, combine your agile and your ITSM, you apply some Lean and now you’ve got DevOps.

And John came up to me and he said, “I’ve been talking about the three-legged stool,” and his three-legged stool was something like safety culture, learning organizations, and I think the theory of constraints. So together, we kind of came up with this idea of the super pattern. And if you search on YouTube or somewhere you’ll probably find some ancient presentations around it. But it was kind of this idea, and I used to have a presentation where I used to do the side of a pound coin and then an Oasis album cover because they talked about standing on the shoulders of giants. And this is the idea. It’s like all these thought streams are kind of coming together and we are taking the best of the learnings, all of them like you said about new conversations and all these other things, and putting together into something we can apply to improve what we’re doing today.

Mandi Walls: Yeah, absolutely. I want to kick off the next question, but I want to ask you about debunking a myth, something that we recurringly ask folks on the podcast to sort of go into things that people have misconceptions about the topic that we’re talking about. I think this will lead us into the next section here. So I’m sure there’s a lot of myths about value stream management. What’s a good one that you’d like to debunk for folks that are listening today?

Helen Beal: I think the key one right now in the market is that value stream mapping is value stream management. And I completely understand why people think that. The way that I see it on a day-to-day basis, so I’ll have a conversation with somebody and I’ll say value stream management and they’ll go, “Yeah, I know about that. We’ve been doing some value stream mapping.” At that point I’ll be like, “Okay, this person maybe is new to value stream management.” We may need to explore kind of the breadth of both these things. But it’s completely natural because most people’s entry point into value stream management is value stream mapping and it’s completely the same for me. I remember it’s probably slightly illegal but I probably won’t get prosecuted for this. The very first value stream mapping exercise I did was in North London and while I was driving around a very famous road in the UK called the M25, which basically circles London, we also call it the car park in the UK because it runs very, very slowly a lot of the time.

So I was actually in my car driving up to this meeting with a colleague of mine, Daniel Breston, who was very experienced in value stream mapping, about to do my first value stream mapping exercise under his guidance. I had Karen Martin on YouTube playing on my phone. And so I was driving around the M25. So that’s how I’ve kind of first even heard of value streams was through Daniel Breston. And this is actually the DevOps handbook being published. And he and I used to do value stream mapping as an exercise with people that wanted to adopt DevOps because it was such an incredible way of getting a group of people in a room, getting them to visually collaborate and getting them to look for areas of improvement and introduce the concepts around DevOps practices.

Whether it was a cultural attribute by the way that we build teams or the way that we communicate and collaborate together or whether it was something more technical in the way that we might test or build a product, it was a very effective way. So we did loads of value stream mapping. DevOps handbook came out. I think it’s like chapters two and three, it starts talking about value streams.

Mandi Walls: I can look, I have it on the shelf behind me.

Helen Beal: So it’s quite early, it talks about how to identify the importance of it. And it doesn’t quite go as far as value stream management, but we’ve had value streams and that concept because it’s lean concept at its course we established it comes from TPS in part. And it was so exciting for us to see it come out in DevOps handbook because we’re like, yes, we’ve been doing the right thing. DevOps has been emerging and people were quite resistant to really stamping down what it was. So a lot of practitioners like us were experimenting with different things. So lots of people do value stream mapping.

I did loads of value stream mapping and then my switch to value stream management came about in 2019. I went to the DevOps Enterprise Summit in London. That year, I actually went on an InfoQ press pass and I’ve seen a lot of people talking about value stream management. So I went to the event with the intention of creating an article about this, what seemed to be an emerging topic, and interviewed a number of vendors like Tasktop, who’s now Planview, and Plutora and ConnectALL, and particularly with Jeff Keyes, then at Plutora. It was a bit of a meeting of minds. On my slides, my company slides at the time, at the bottom I had a strap line that said optimizing the flow from idea to value realization. And speaking to him, I realized this was exactly what value stream management was about and that I was getting frustrated with people that were defining DevOps tool chains as the CICD pipeline because I saw it starting much earlier at the front of the fuzzy front end.

I saw it finishing much later after service desk and operations into customer feedback. And this was where value stream management was coming together. I sound like I was really frustrated. I was also really frustrated because I do these values stream mapping exercises with my clients and they’d be brilliant. We’d like do them sometimes over four days. It’s a lot of effort to get these people in the room, we’d all have a wonderful time. There would be loads of epiphanies, light bulb moments, sometimes there’d be rows and things would get emotional and that would be our job as the facilitators is to kind of referee and keep us from not going down rabbit holes. And everyone would have a great time. You’d finish the session, you’d have your future value stream map, your action plan or your hypothesis backlog.

Everyone was really fired up. You’d leave the room, go off and do something else and you’d come back a little while later. And the poor guys had either not managed to do anything because of this thing we call BAU, or they’d done some things but they couldn’t figure out what they’d done or how to get the time to figure out what happened. So we had these value stream mapping exercises that on the face of them looked really powerful but kind of weren’t followed up. And this was quite similar to another experience I was having. We had metrics workshops. So I’d sit with people to try and figure out what DevOps metrics they should use, where they were going to get them from, how often they were going to check them. And similarly, I’d go away from the workshop, come back, see how they were doing.

And quite often, maybe they’d got some reports in Jira or something, but not an awful lot happened. So value stream management comes along and I’m like, oh, hold on a minute. This is different because it’s a set of principles and practices. It’s another way of working, but it’s really focused on that end-to-end flow. And then the other reason I talked about two reasons earlier, why it’s got Renaissance now because of technology being different. The other part of it is that we’ve built DevOps tool chains. We’ve spent over 10 years doing this. So what we’ve effectively built is an abstracted technological model of what a value stream is that we can make it emit the data. So if it emits the data, we can observe the data, we can transform the data in a way that it looks like a value stream and tells us things we want to know about our value stream like where are the delays, where are the bottlenecks, how long has it taking me to get from here to there, what’s my customer feeling, when we finally released that thing, was it worth the amount of effort we put into it. So that was my big epiphany, really. It was like suddenly I’ve got a thing that I can take to all these people that couldn’t get back together to look at their value stream again, couldn’t work out what metrics to do. Now we have a key enabler that automates the inspection and adaptation or automates the data that allows for the inspection and adaptation of value stream and gets us to a point where we can understand more clearly about what our customer is experiencing real time, rather than just using the lagging metrics of profit and revenue that tell us what our customer thought about us three months ago.

Mandi Walls: So for folks who want to go down this path, do they start with mapping and then incorporate that into a value stream management practice? Is there a recommended way that folks are like, “Man, this sounds amazing”? How do you really get started with all of this stuff?

Helen Beal: Yeah, so in 2020… Kind of forget what year we’re in sometimes. In 2021 we produced the first state of VSM report and then we did the second one last year. We’re about to launch a survey for this year, 2023, it’s the third one. In that first year report, we introduced something called the VSM implementation roadmap.

Mandi Walls: Excellent.

Helen Beal: And that’s a good reference point to start with. And in the second year, so last year’s report, we actually built the entire report around that roadmap. So the different steps on it. And in it we kind of say start where you are. One of the things we explore is why people don’t start value stream management and whether people are not doing it because they don’t think they’ve done enough DevOps or whatever. You can really start where you are. But the first thing you need to do is get your long-term vision and goals in place. You need to understand why you are doing it. So what is it about your business or your team that you want to change? So do you want to go faster? Have you got a problem with quality? Are you being disrupted? Are you wanting to diversify? What is it you’re trying to do?

And then you need to identify your value stream. Now, one of the things we’re working on at the consortium at the moment is a series of workshops that align to the implementation roadmap. So the first one’s coming up soon, which is about identifying your value stream. So we’re coming up with lots of tips, tools to help people do that because some people find it complicated and difficult, which is understandable when a lot of us have been taught to work in silos for so long. It’s suddenly difficult to see that people spread across multiple components or steps of a value stream and that all these different processes slot together to get from idea to customer experience. Then we organize around value stream. Now, I’m kind of touching on this in my brain a little bit. Organizations are all different and different sizes are made up of different configurations.

So there isn’t a really one size fits all. And when I’ve looked at people adopting DevOps in the past, it’s like you can’t wholesale, get an organization to change their way of thinking working overnight. It’s kind of like it’s evolution, it’s incremental, it takes a while. And this is the same value stream management. We might get onto more of the relationship between DevOps and VSM in a minute. But the next thing is to organize. So identify those people around you and they might not be in the same team. They mostly are not in the same team, but you shouldn’t let your organizational chart prevent you from getting people in the same room. And I think it was Spotify in their engineering culture videos years ago that said that the organizational chart is just an illusion. And that’s quite true I think. And it’s about getting the people that are doing the work together in the right place.

Then the next step we suggest in the implementation map is to do the value stream mapping exercise. And when I wrote the map, designed the map, the next step that comes as connect, which is about connecting your DevOps tool so you can see the work. It’s about making work visible. And I thought about what I’ve been preaching and lots of practitioners have been preaching to the market forever, which is the old mantra of people, process, tools. And I thought if I put connect before map on there, I’ve effectively gone people, tools, process and that’s going to annoy people. So I thought, okay, let’s put map first and then we’ll put connect. So we published this report and almost within 24 hours someone in Australia had written a blog post saying, “Yeah, you could do the connect step before the map.”

And I’m like, it wasn’t just me. We have the tools there. And again, you can’t connect all parts of your value stream overnight. It’s incremental parts. You have to pick two parts to begin with. Commonly, people will pick the product backlog and the service desk and say, right, we need to make these two pieces more visible and more traceable together. Once you’ve done all those steps, the VSM implementation roadmap says now you can inspect and adapt and this send becomes easy. This is the point I was making earlier. You don’t have to get all those people back in a room and get those opinions on the table.

And value streaming is opinion based. Let’s not forget that. It’s incredibly accurate. I’ve done value stream mapping and you go through this day long task of putting all the steps on the board, putting all the touch time, putting all the wait time, doing all the calculations, putting all the people in it. And people have gone, “It was 180 days when we did it.” But they’ve just built it from… They’ve kind of reverse engineered it effectively and then gone, ‘Oh wow, it was as long as we thought it took." So yes, that’s what we’re trying to do.

Oh yes, see, inspect and adapt. So now what you’ve done is you’ve got realtime data, so you’re now data driven, not opinion driven because it’s coming from your tools, it’s accurate. And you can inspect and adapt one if you want. So an example we take is if you’re following Scrum, you could use scrum events. So you could inspect against OKRs at scrum planning and at scrum review, even at retrospective, if you wanted a slightly different measure that you were looking at. You could even use it in a data standup potentially if you were tracking a particular, depending what speed you’re working, if you’re tracking a particular metric.

Mandi Walls: That’s super interesting. That’s an interesting idea to keep it as top of mind for folks as often as possible while they’re trying to improve it. So it’s sort of constantly in the conversation versus something that you kind of visit every quarter. And then really the 48 hours before the meeting people are like, “Oh yeah, what did we actually do with this thing?” And then make something up.

Helen Beal: It’s like continuous inspection. And the other thing is you’re being driven by your goals rather than your work in this instance.

Mandi Walls: Yeah, that sounds great. This sounds amazing, right?

Helen Beal: Yeah. Why isn’t everyone doing it?

Mandi Walls: Yeah. Right? So you mentioned DevOps a few times. Is there an explicit prescribed relationship between DevOps and VSM? It just feels like, as you’ve described it, VSM really fits pretty naturally into what most folks kind of probably think their aspirational goals are for why they’re going to do DevOps, other than it just sounds cool. But is there an explicit way that you think about the relationship between DevOps and VSM?

Helen Beal: So I swing between, or maybe I’ve got a foot in both camps. One is that it’s the next generation, DevOps and the other is that DevOps is the toolkit that enables VSM. So if I go into each of those in a bit more detail, I’ve done a lot of presentations on this again, that you could probably search on YouTube or in my SpeakerDeck. And it goes back to the 2021 state of DevOps report from Puppet or a lot of the grounding of the data was there. And what that particular report showed is that a lot of the basic mid-level performers in terms of DevOps capabilities have kind of got stuck here on year on year, on year. We’re not managing to break them out of that capability level to the higher level.

So it needs something to unlock that stagnation. And I think that stagnation is partly to do with people’s inability to show how to continually improve or to fight for the time internally to prioritize improvement over change. Because they haven’t got any data. So it’s all hearsay and they’re all controlled by the business still because people haven’t really understood that we are software companies, the world is disrupted by technology and now the technology teams are the strategic enablers. So still being treated as order takers.

So what VSM does, and this is where I think a lot of the analysts Gartner that have been like, this is a must do, this is a must have if you want to succeed in DevOps, you have to do VSM. What VSM does I think makes the work visible in a way that allows people to say, “If we make these changes, we’re going to be able to give you so much more stuff.” And that’s basic, the argument for the business. We can increase our capacity by X degrees so we can leapfrog the competition.

So that’s kind of the next generation DevOps thing. And then the DevOps toolkit argument is we’re like, well how do you do this? If you discover a delay or a bottleneck and it’s that you are waiting six weeks for security to give you something, you go and get the DevSecOps book and you read that and you figure out how you’re going to collaborate better. If it’s that you are having to go round and round and round testing because you’re chucking out such more quality stuff, you go to the DevOps handbook and look at team topologies and how to fit together like that. And then you get into some automated testing and then there’s… All of these things are DevOps practices that enable VSM.

So it’s a really close relationship in my mind. But what’s been really interesting working at the consortium is that my background quite clearly is DevOps. That’s where I’ve come from. The consortium has brought me into communities that I didn’t know before. So kind of the really strong lean practitioners, the people that are agile like purists. We’ve even got manufacturing companies that are getting involved as well who kind of need tech. So it’s kind of crossing a lot of communities, which is interesting. So a lot of people come from it from different ways. But for me, it’s next generation DevOps and DevOps are the key enablers.

Mandi Walls: Super interesting. So how does that apply then to say, if we wanted to look at a specific piece of functionality, is there a way to apply VSM to improving sub-pathways, things like incident management or specific projects for IT operations? When we’re looking into going down this path, is it something that we should look at organization wide? Can we concentrate on certain tasks that we feel like we’re having trouble with?

Helen Beal: Definitely. And the principles of value stream management, which are about making work visible in order that you can improve the way that you do it so you can do it faster without wasting things and satisfying your customer apply to all sorts of things, not just a software development value stream. So some of the work we’ve been doing at the consortium, I mentioned the value stream identification workshop. We’ve also produced and are still producing a blog series called, Is this a Value Stream?

Mandi Walls: Oh, nice. Okay.

Helen Beal: It sounds a little bit like a kid book, doesn’t it? Is this a cat? Is this a value stream? Yeah, so we’ve done a few and actually instant management was one of our first ones. I think release management may have been our very first one. We have done instant management. What we normally do is me and Steve and Patrice often, and whoever at the membership wants to chime in, we all look at it and explain whether it’s yes or no and our reasons why. And I think maybe just take a step back for a second, defining a value stream, the value stream starts with an idea, finishes when you deliver that idea to the customer and it’s the series of steps in between. So anything that has a customer theoretically or I often say produces a product or a service is some sort of value stream. So by that token, you could say instant management is kind of a value stream, but it doesn’t really start with an idea. It’s not value generating. What it’s doing is responding to a problem. But it still has flow. So you can still use flow improvement techniques to improve your instant management processes. And it is a number of processes which makes it look like a value stream. It’s not just one process. But I think there’s a more important relationship with value stream management and incident management, in that instant management can really bog us down. It’s unplanned work and if we look at the four types of work in the Phoenix Project, that is the killer. We never put enough contingency and things go wrong, things predictably go wrong as in like we know things are going to go wrong. We don’t know what’s going to go wrong, but we know things are going to go wrong. So the way that we deal with it is really important. So the more that we can reduce the time spent on incidents, reduce our MTTD, reduce our MTTR, reduce the frequency of incidents, the more time we’ve got to spend on value generating, value adding, differentiating features in our products and services. More stuff we can give to the ultimate customer who’s paying the bills, who’s paying us to live, effectively.

Mandi Walls: Yeah, awesome. Who’s out there using VSM today?

Helen Beal: That’s a really interesting question because not everyone calls it VSM. And I’ll come back to that comment in a minute. So examples of speakers we’ve had at various events. We recently had a webinar with IDC. IDC recently produced a PeerScape report on value stream management practices. It featured Netflix as did our, you can see the webinar on demand through site and get a free copy of the report. The report also featured Defense Unicorns, Bryan Finster, Shutterstock and Comcast Business. Last year in October, we had our first in-person event at the Value Stream Management Consortium. It’s called Flowtopia. We held it at DevOps Enterprise Summit in Las Vegas. We’ll be doing that again this year. We’re probably going to do a little roadshow as well, maybe one alongside the Fast Flow Conference in London in May. So that’s all in plan at the moment.

But at our Flowtopia last year, we had to have Bryan and Sejal who were featured in the PeerScape reports. We introduced them to IDC but we also had Bupa come over. We had a lady from Transavia Airlines as well come over to speak about it. Sorry, that was our DevOps Institute event. She was talking about value stream management. Not everyone calls it value stream management because she pitched it as DevOps. But what they were doing, is they were doing value stream mapping. They were aligning around value streams, they were using flow metrics. So they were using all the value stream management practices, but kind of front-ending it with a DevOps title, which is fine as well because I think one of the things we suffer from in our industry is jargon. And there’s a counter argument that jargon’s important because we need labels in order to understand what we are saying to each other, but sometimes we take them too far. But ultimately, we’re talking about ways of working and established practices that do different things.

Mandi Walls: Yeah. Excellent. That sounds fascinating. I’ll look a bunch of these up and we’ll put them in the show notes for folks who want to learn more in addition to that, yeah, website that you’ve mentioned has a lot of information on there and we’ll link to that in the show notes as well, and the state of VSM report. And you’ve been very generous to offer our listeners a discount.

Helen Beal: I have. Yeah, I hope they take advantage of that. It’s for annual Influencer membership, which gives some access to the members portal, which has a recorded version of the Value Stream Management Foundation course, which is about eight hours of recorded learning I think. And all sorts of other things, research libraries, resource libraries, all sorts of other things. And to our community as well, so they can meet and network with all our other VSM like-minded individuals.

Mandi Walls: That sounds amazing. So everyone out there who’s listening today, hopefully if you found something interesting that you want to learn more about, you can take advantage of that and learn more from the VSM consortium. Helen, where else can folks find you if they want to learn more or hear more about what you are doing?

Helen Beal: LinkedIn is always a good place. I’m Helen J. Beal on LinkedIn. Yeah, tune to the DevOps Institute as well. We have a lot of events going on there.

Mandi Walls: You do have a lot of events at the DevOps Institute.

Helen Beal: We do. We’re busy bees.

Mandi Walls: You are. Excellent. Well, this has been great. I’ve learned a lot. I was guilty of knowing the value stream mapping part and thinking that was all there was that was going to be into this. But this is so much more interesting and so many more components here that will help folks on their journey to improvement and better customer experience out there. So I’m very excited. I’m going to learn some more about it.

Helen Beal: Well, thanks so much for the opportunity to chat about my passion.

Mandi Walls: Excellent. Thank you so much again. And for everyone out there, we’ll wish you an uneventful day and you can join us again in two weeks. That does it for another installment of Page it to the Limit. We’d like to thank our sponsor, PagerDuty, for making this podcast possible. Remember to subscribe to this podcast if you like what you’ve heard. You can find our show notes at and you can read us on Twitter, @Pageit2theLimit, using the number 2. Thank you so much for joining us and remember, uneventful days are beautiful days.

Show Notes

Additional Resources


Helen Beal

Helen Beal (she/her)

Helen Beal is chair of the Value Stream Management Consortium, co-chair of the OASIS Value Stream Management Interoperability Technical Committee, and chief ambassador at DevOps Institute. She also provides strategic advisory services to DevOps and VSM industry leaders.

Helen is the author of the annual State of VSM Reports from the VSMC and the State of Availability Report from Moogsoft. She is a co-author of the book about DevOps and governance, Investments Unlimited, published by IT Revolution. She is a DevOps editor for InfoQ, and also writes for a number of other online platforms.

Helen hosts the Day-to-Day DevOps webinar series for BrightTalk and speaks on DevOps and value stream-related topics at a wide variety of industry conferences and at corporate events.

She regularly appears in TechBeacon’s DevOps Top100 lists and was recognized as the Top DevOps Evangelist 2020 in the DevOps Dozen awards and was a finalist for Computing DevOps Excellence Awards’ DevOps Professional of the Year 2021.

She serves on advisory and judging boards for many initiatives including Developer Week, DevOps World, JAX DevOps, and InterOp.


Mandi Walls

Mandi Walls (she/her)

Mandi Walls is a DevOps Advocate at PagerDuty. For PagerDuty, she helps organizations along their IT Modernization journey. Prior to PagerDuty, she worked at Chef Software and AOL. She is an international speaker on DevOps topics and the author of the whitepaper “Building A DevOps Culture”, published by O’Reilly.