Helen Beal, Chief Ambassador of DevOps Institute, joins Jayne to discuss trends she’s seeing in the value stream management space, why it’s a human exercise, how neuroscience influences the work we do, and its role in change fatigue.
The lightly edited transcript can be found below.
You’re listening to the Humans of DevOps podcast, a podcast focused on advancing the humans of DevOps through skills, knowledge, ideas and learning, or the SKILL framework. Here’s your host, DevOps Institute, CEO Jayne Groll.
Hi everyone, this is Jayne Groll, CEO of the DevOps Institute, and welcome to another episode of the human sip DevOps podcast. I’m delighted today in particular to be joined by Helen Beal. Helen is DevOps Institute’s chief ambassador, she’s an industry influencer, she’s a frequent presenter, a very, very well known woman in tech. And so, Helen, welcome. Tell us a little bit about yourself and some of the things you’ve been working on.
Thanks Jayne. It is a pleasure to be here and be talking with you, as always. I describe myself as a DevOps-ologist. I have a massive collection of hats. Basically, I wear a lot of different ones. As a DevOps-ologist, I’m primarily a consultant and coach and learning facilitator. So I’m blessed with having some incredible clients that range from some very, very large global banks and telecoms, giants based out of Europe and across the Middle East. So I spend a lot of time with end users and organizations talking about their challenges. And I also have a love for writing. So I spend a lot of time studying and writing about this and networking across community. Which is why it’s been such a pleasure to take on the chief ambassador roll, actually, at DevOps Institute is to really extend my global network and meet all these wonderful people worldwide that are also pushing forward the humans of DevOps.
So, I know you’ve been spending more than a fair amount of time lately focusing on a couple of areas, one of which is value stream management. Tell us about some of the work that you’ve been doing. And more importantly, I think, what trends are you seeing in the value stream management space?
The birth of this, it goes back a really long way actually. So if I think about what started me thinking or got me interested in value stream management it is really value stream mapping. So value stream mapping is a service that I’ve provided to possibly even hundreds of clients over the past several years as a really incredible way of starting a DevOps evolution or a DevOps journey. So it gets a bunch of people in a room and they start collaborating together visually and they stop thinking about flow. And for a long time I’ve been using phrases like optimizing the flow from idea or ideation to value realization. We’ve been talking about focusing on finding outcomes and not productivity and things like this. And this is the natural extension really.
So as of last June, in 2019, it was when I was at the DevOps Enterprise Summit in London, I became very aware that Forrester had coined a new, if you like, or new process and tool set around value stream management. And that led to a number of conversations with the likes of Futura and TaskTop. And the lights just were really going on in my head because this is what we’ve been trying to do with people and their DevOps tool chains for such a long time. Is actually have traceability from the point that a human has an idea about what they want to do and being able to trace the journey of that idea through its life cycle and then measure the impact of that value. What it actually… What the actual outcome that was when it hits the customer’s hands. So, I had a real light bulb moment. I don’t know if you can remember when you first started talking about value stream management over mapping. Was there a specific moment where you saw it happening?
Yeah. You know, funny… Like you, when we started to look at where organizations were starting their DevOps journeys, many of them were starting it in CI/CD, and nothing wrong with that. Right? But a lot of talk about, “Well, we need to add value and value creation and value streams.” And a lot of talk about value. And it reminded me, like you, how can you start a journey if you don’t know where you’re going? And so, value stream mapping, really, leading to value stream management, for me, was the starting point for DevOps and talking to the likes of Mike Orzen and Dominica DeGrandis and really those that come from the lean space. And understanding that the value stream is not just mapping your activities or mapping your tools. Right? It’s understanding how you create value. And that is, very much, has to be internalized by the humans.
Automation isn’t going, necessarily, understand the creation of value or will underpin the mechanics of that. So it became a very social exercise, it became something that you could benchmark against. It’s certainly something that, from a management perspective, we could look at from idea-
… What do they call it? From ideation to value realization. Right? And then on and on and on. What sort of return that investment is making and how the customer experiences impact by it. So like you, it is the start of any journey but there isn’t a finish line at the beginning. Like, “Oh, we mapped our value stream, now let’s move on and introduce a bunch of new technologies.” Value stream management, I think, takes it to the next level.
Absolutely. And I think that was one of the biggest fails that we were seeing when we were doing lots of value stream mapping. And we still are but we have mechanisms now to stop… trying to stop people falling into this trap. But teams of people would get together… And it’s worth noting that often when a team initially gets together to do value stream map, they’re often not on the same team at that time. They’re often transitioning between waterfall and agile then moving from project to product. So you get a bunch of people effectively from different teams that over time may become one product team.
So one of the big fails that we saw is people would do a value stream mapping exercise… And when we do it, we do it over two days. So it’s not a cheap thing to do, from a people’s salary perspective, given that you’ve got 10, maybe 15, people in the room, all highly paid. Often, some very senior decision makers in the room as well because some of the things that we’re trying to do might affect the way that budgets work or the way that the organizational design looks. Some really high level decisions need to happen.
But they’d get together, spend all this time, all get super excited about all of what they decided to do, and then they disperse and business as usual would happen. And the value stream analysis that had been done would not be effectively revisited and the plan that they had to make improvements was not happening. And I think this all links back to a lot of the difficulties and challenges that organizations have around measurement. So what do you think organizations think when they think about how to measure themselves?
Well, it’s a good question. Because again, if you look at it historically, how the organization measures itself, and again let’s look at it from an enterprise perspective, how IT measures itself, how the different functions within IT measure themselves are usually based in some type of operational excellence. Right? Like, “Yay, we deployed.” Or. “Yay, we finished that sprint.” Or, “Yay we released that campaign.” But an end-to-end level of measurement of value, I think, has always been a little bit of lacking. Even that enterprise to IT to other business units… a shared understanding of what value means. And so ,I think you’re right. It falls into the level of checkbox. Like, “Oh yeah, we did a value stream map.” Check. You know? Documented, thank the facilitator, file it.
And I think the work that you’re doing and I think the work that others in this space are doing, particularly when we look at automating value stream management. We look at, really, the negotiation skills that are associated with this, not on a onetime basis, on a longterm basis really exemplify the need for human skills. So I think it wraps everything together. Metrics, it measures a business and IT alignment… I don’t even like that term anymore. Right? It implies were in parallel lanes but sill, it says a lot. It implies that we have some type of ongoing opportunity to measure and also adapt if, for whatever reason…
Again, look at the situation we’re in today where businesses are having to adapt their models very, very quickly from both their customer side and from their staff side. So being able look at this in a longer term view instead of, “Hey, we mapped our value stream,” I think gives us a lot to go forward from. But Helen, at the end of the day it is a human exercise.
It is, completely. And I think there’s so much that you can learn from… about the culture from doing these sort of exercises. And some of the things you just said about the kind of metrics that people are used to reporting on, those metrics tell you a lot about what that organization does from a command and control perspective, and how good they are distributing authority and things like that. So getting to a point where you’ve got every team that has autonomy knowing what metrics they’re using and they’re really using them to discover and learn. They’re not using them in order to report on targets and try and gain or game bonuses that they may or may not be due at the end of an annual cycle. It’s pretty difficult and takes a really different approach from leadership in order to make it happen. What’s really challenging is that a lot of the people don’t have the facility or the capability to gain these metrics in order to do what you’ve just said.
They’re not transparent, they can’t inspect and adapt them very easily. They’re being able to look at what the typical cycle time of a feature, on a sprint by sprint basis, is very difficult for lots of teams. Partly because they haven’t think given the room to build those tools, they haven’t got the tools available, they’re being told just to push, push, push more change through or they’re drowning and technical debt. There’s lots of reasons but generally, from a human point of view, actually having that data to hand has been pretty difficult with the organizations I work with. And the leadership has typically driven them in the past to look at metrics which may not be the most useful for the business moving forward.
So I always ask people, “What are the top metrics that you are asked to report on?” And I always get, “Downtime and number of defects.” And customers don’t really care about downtime and number of defects. What they care about is whether they’re getting that new feature that they want that’s really going to make it easier to report when they’ve had a car accident or make a transfer to their friend when they’ve just had dinner together and they want to pay them back for their share of the bill. All of those sort of things are where the real value is.
You know what’s really interesting about that is you’re implying the best and the worst. Do you have an example of a customer you work with, obviously keeping the customer anonymous, that the experience of not only mapping the value stream but then that measuring it on an ongoing basis, that they’ve taken some steps that perhaps are either unique or really contributing to their success? And then, of course I’ll ask you on the other side, what are the big challenges or, I don’t want to say not-success stories but you know what I mean… give us an example of something that perhaps they shouldn’t be doing.
So, the more successful organizations we work with have typically gone through a similar journey with us, in that they start to do value stream mapping and they start to understand and think of the end-to-end flow. And then they start realizing that they need to be able to measure that. So, typically we’ll end up doing things like metrics workshops. And I always say that organizations tend to fall into one of two categories. They either have far too many metrics and it’s just noise or they don’t have any at all. And it’s… it sounds really obvious but it’s been absolutely true from my experience. So what we try and encourage people to do is have a handful of metrics per team. And this is where it gets quite tricky because this is a cultural, human thing.
What we’re talking about here is about empowering teams to be autonomous. And humans that have been working in waterfall environments for a long time have not been empowered and they haven’t had autonomy. And they’re expecting their leaders to target them on the metrics that they, the leaders, will believe will make them successful. The teams haven’t had accountability and haven’t been empowered to really look at those things themselves before. But once we start going through this process with them, we very quickly get to a point where the team start to take ownership of them. And interestingly, the role that most often starts the automation of the gathering of these metrics, so that the humans can inspect and adapt accordingly, is mostly the Scrum Master. And lots of organizations I work with say, “Shouldn’t that be the product owner?” And I think it doesn’t matter. It just needs somebody that is in the team and close to the team that has the time and the wherewithal to at least set up the framework so that the team has transparency and visibility into those metrics and they can start using them in a meaningful way.
What’s interesting about that is, because it’s not easy to switch from waterfall to agile overnight, leadership doesn’t switch from one to the other. Investing in a journey between the two states is a big thing and requires a lot of commitment from the senior levels of management in an organization. Those managers and leaders are still interested in knowing what’s going on in the journey, they can’t afford to just pass everything over to the teams and tell all their bosses, or the shareholders, “Well, it’s not us now it’s the teams doing it.” They still need to get a global view.
But once we start getting those teams collecting those metrics, you can naturally roll up to the global view. Culturally, we still have to be careful. We still have to make sure that those leaders aren’t using those to punish people or berate people or target people but that everybody understands they’re used to discover and learn and improve, which can be quite challenging. And I’ve seen in many instances during my career, of leaders that talk the talk but don’t walk for walk, that’s not uncommon for people to do that. And to be fair to leaders, it is hard to change when you’ve been working in one way for a long time. It is hard for anybody at any level to change that. So the most successful organizations that I work with that have started doing that and they have started collecting metrics at the team level, some of them, and this is like, say… is becoming an apparent anti-pattern, is actually using dashboards over value stream management.
And I say that because there’s many levels of things that you can do to get these insights into the value stream that we want, from a data perspective. So you can integrate all your tools, or some of your tools in your tool chain yourself, which is very time consuming. It’s very difficult to swap tools in and out later. It’s quite inflexible or makes your tool chain quite un-adaptable or it’s difficult to evolve your tool chain moving forward. Obviously a lot of tools now either come from the same vendor…
So, if you use a lot of Atlassian products, that’s helpful. If you’re a Microsoft user or a dot net house, that’s helpful, there’s a lot of tools and prebuilt integrations and plugins. There are also companies that offer brokers that will automate tool integration. So, let’s assume that we’ve started to think that we want to traceability from ideation to realization. What we’re now talking about is getting those metrics out. And of course we have some well-established patterns now for metrics that we can look to. Things like the state of DevOps reports and the DORA, the four key metrics, like deployment frequency, lead time, change fail rate and MTTR. We can look to those sort of metrics, they’re good places to start for teams. Downside of all of those four that I’ve mentioned is none of them actually do end-to-end cycle time, even lead time is actually only from code to commit to deploy into production.
So it’s missing a whole load of stuff that happens to an idea before a developer actually commits code to trunk master. So we’ve got these metrics and some people have gone down the route of getting dashboards and WHILST dashboards can tell the team something, they’re probably more useful for the leadership to get a view across their whole global landscape, of which teams are doing what well. And then we fall into that trap of potentially saying one team’s better than another.
But what we should be asking is how each team can help themselves improve. And then the other big problem with dashboards is they’re really just a skin on top of our tools, they’re not actually showing us the end-to-end cycle time from tools to tools to tools. They don’t give us very easy insights into where our waste is or our blockages are happening, so it’s very difficult to get insights out of them. And this is the real strength of value stream management is it gives us a view into the end-to-end flow throughout the whole DevOps tool chain and allows us to get insights into, you know, whether security are holding us up for six weeks while we wait for a pen test or whether the cab is giving us a three day lag after every sprint.
So, it’s that level of information that we can actually start to plan interventions as a team. If we’re a very large enterprise, we could start scaling interventions using one of our agile to scale frameworks, whether it’s Scrum, Master for SAFe or LeSS or whatever it is. But we can really use this data to make improvements with the ultimate goal of improving and accelerating the flow of value, rather than reducing costs or making teams smaller or whatever it is that people have traditionally used to build a business case.
And it’s interesting that you say that. A couple… Just a couple of points and then there’s an interesting pivot here. So first of all, I’m not surprised it’s the Scrum Master, I’m a trained Scrum Master… I haven’t done it in a while. But the role of the Scrum Master is to protect the team and to be the expert on different frameworks and different approaches and, of course, the expert on agility. So, interesting to me that it is the Scrum Master that’s really taking the lead in that. But the other thing I think that’s really interesting is, in the earlier days we talked only about value stream mapping and I think you make a good point that the value stream mapping exercise is critical but it’s not the end game. Right? Because again, having it visualized, having it socialized but not being able to measure it is not going to deliver, no pun, the value of the exercise itself.
And I think it’s one of the reasons we’re talking more these days about value stream management than we are about value stream mapping. Again, it’s not that value stream mapping is not important but at the end of the day you have to manage the value stream. Being able to optimize some of the tools that are available that really do give you that end-to-end view, instead of putting blinders on and only looking at a particular team or a particular feature or a particular branch.
But again, all of this is really human cycles. Right? The automation will help us and I think a lot of this is changing the way people think.
There’s a lot of talk, there’s certainly a lot of assets that are being produced right now. The upskilling report certainly does demonstrate the importance of human skills, equally important to process some automation skills, that are uniquely human. And I know you’ve been doing a lot of work in neuroscience, so why don’t you tell us a little bit about how neuroscience really does influence the work we do, how we do it, how we think, and more importantly, how we’re successful.
So, my interest in neuroscience really began with a book called Why We Love by Helen Fisher, Dr. Helen Fisher, who later became a consultant for chemistry.com and other things. So it was very interesting to hear about how our human experiences are so directly affected by how an organ in our body works. So, love is a really interesting subject. I have an English Literature and Language degree, so I’m quite well versed in how many of the human stories that we tell are related to love. And that’s obviously quite separate from the working environment but that got me interested in understanding why we feel good about things sometimes and why we feel bad about some things and what’s actually going on inside our brain to create those feelings. And how we can understand them and how we can control them to some extent, not completely. But understanding them or being mindful of them gets us a lot closer to being able to put them aside if we need to, or explore them further if that’s something that we choose to do as well.
So, as I go into DevOps and as everyone knows here, it’s such a huge part of DevOps’s culture, it started me asking more questions about the working environment and how culture works at work. And that got me… I can remember, I think, the first book I read that related to neuroscience at work and it was several years ago. And we were having a breakfast briefing and the topic of the breakfast briefing was motivating people, it was goals and rewards in the context of DevOps. And obviously we were talking a lot about things like shared goals and things like that but it drove me… or a book arrived from the ether to me, which is called Your Brain At Work, by David Rock, who heads up The NeuroLeadership Institute. And that made me start understanding how our brains are all slightly different and we have different reactions according to who we are.
So, David Rock talks about the SCARF model for motivation. So, he basically says that broadly, all of us fall into one of five categories in terms of our primary motivations at work. So SCARF stands for status, certainty, autonomy, relatedness and fairness. So, for example, I’m an autonomy person, which means that if somebody tries to micromanage me it makes me very tense. So, it means that I’ll get all the nasty anxiety chemicals happening in my brain, so all the cortisone and stress chemicals. It means that I will probably experience quite a lot of distraction in my frontal lobe which is where our key parts of our neurological processing happen. And that’s just… it’s snowballed from there. I’ve read lots and lots different work and tried to pull it all together and, in particular, looked at it through the lens of learning. Because what we’re trying to do in DevOps is unlearn and relearn ways of working.
We’re trying to move from waterfall to agile, we’re trying to move from project to product, we’re trying to help people unlearn behaviors and habits and do things in different way. And that’s very frightening for lots of people. And actually, one of the other books that taught me a lot about this was Wired To Resist by Britt Andreatta. Britt’s not a neuroscientist herself but she’s done a lot of research of research and brought it all together. And she’s learned things like, actually as humans we’re all naturally wired to resist. It’s a evolutionary tactic to resist change because change means there might be a threat.
And just knowing that and knowing the kind of neurological responses that we have when we’re fearful, we have a fear avoidance tactic in our brain, can really help us understand as leaders and colleagues when we’re going through change in an organization, as to why it’s difficult. You can probably think yourself about moments where something seems a bit difficult and it’s new and your head just goes really fuzzy and suddenly you can’t seem to even think. Have you experienced that?
Yeah. Oh, often. Often. It’s like, “Okay, all right. Process.” One step at a time, right? That’s the most important part.
And the one step at a time’s so important as well. Because the way that our brain learns is that, again, it’s our frontal lobe and our frontal lobe actually has quite a small stage, effectively. So it can only have a handful of actors on stage at any one point. So you’ve probably seen me do this in some of my presentations but I put up a string of letters and they’re in sets of three. And I ask the audience to try and remember as many of the letters in the right order as they can and then I put it away. And the audience really struggles with it because there’s a lot of information and there’s no context. And then I put up another set of letters and they’re actually the same letters but they’re now in groups that people recognize. So they’re things like REF and MRI and BBC. And suddenly the audience is remembering most of what they’re seeing on the screen.
So what that’s physically showing us is that our… It’s basically showing us our cognitive capacity or our frontal lobe. So if we look at work that’s being done by people like Matthew Skelton, who by the way is a PhD neurologist or neuroscientist himself, and Manuel Pais, their book Team Topologies. A lot of that is built around understanding what humans’ cognitive capacity is and how much it’s feasible… fair, feasible reasonable to ask people to learn as we move from one working state to another working state, which is the core of what we’re doing at DevOps.
You know what’s really fascinating about it? There’s a lot of studies and discussion about change fatigue. Right? That the rate of acceleration is so fast that learn, unlearn, learn, unlearn, learn, unlearn is a pretty common cycle, particularly for those of us that are in technology. But even the customers of our technology are in that, “Okay, is this going to stick? Is it not going to stick? Are they going to change it tomorrow?” So there’s a lot, in terms of how we process, that, I think… that is almost not recognized from, “How much capacity can the human brain handle.” Right?
I mean, aren’t you… I’m famous for saying, “I can handle three balls in the air but if you throw me the fourth I melt down.” Right? So it’s the same kind of thing where you can handle so much but you also do need to honor what you… what’s familiar to you, probably having something to do with the recognition of those letters. Honor what’s familiar to you and then build on it as opposed to let’s just keep wiping that slate clean.
So, let’s take neuroscience and apply it to value stream management. So, what is it that we can learn or do as a takeaway today that says, “Hey, we understand that the value stream from a mapping and a management perspective are human exercises supported by automation.” Right? We need to be able to measure. Right? Because I think that’s also a very human piece, where we need to know, “How are we doing?” Right? “What needs to be corrected? What should we be doing differently?” And I think that’s a very human thing. So, just some knee jerk ideas in terms of that. How do we apply what you’re learning about neuroscience to this accelerated interest and need for value stream management?
I think you really hit on it a few moments ago actually, when you talked about change fatigue. And I think a lot of the change fatigue comes from these big bang, transformational, revolutionary, project driven approaches that we’ve worked with for decades. And actually having a more continuous approach to everything, a more evolutionary way of looking at things… and I’m well known within my clients, probably within my writing in the industry, for being somebody that always wants to talk about evolution not transformation. Because with evolution we understand that it’s incremental. I look to Damon Edward’s DevOps Kaizen, the big “J”s versus little “J”s, and lots of work like that to explain to people that they don’t need to be overwhelmed by this. It doesn’t need to be big bang. It doesn’t need to be huge and scary. We can just to a little bit every day.
And I think that really helps when we talk about mindset. So, we talk about mindset, it’s really bandied about a lot in our industry. But the origins of it was that you either have a fixed mindset or a growth mindset. And in a fixed mindset it means that you believe that you can’t learn. And in a growth mindset it’s you’re a learner, your a lifelong learner and all of those things. And for a long time we believed that that was true, there were these two camps.
But what we’ve learned through neuroscience, and this started by a neuroscientist observing people that had had very significant and awful brain injuries, and they were very surprised actually, to find how much people could recover from having a brain injury. And that led them to discover the thing that we call neuroplasticity. And everyone has neuroplasticity and it’s a fact. And what’s really interesting about this is when you tell people that have thought that they couldn’t learn new things and they thought they were one of those fixed mindset-type people, when you tell them about neuroplasticity, it changes them and they are able to learn much more effectively.
So, as we go into value stream mapping and as we go into value stream management, we need to go into it with a mindset that this is a foundation for continuous improvement as we move forward. And it’s going to be incremental and we’re going to measure it regularly. It’s not going to be something that’s going to happen annually, it’s going to be something that we want to inspect and adapt every sprint review. We probably want to inspect it every sprint plan that we do. Every time we set a sprint goal we need to do it. And if you’re using Kanban, that’s fine, just make sure there’s regular and frequent inspection points as well. But effectively, it brings… this is what brings it together is that need to measure and inspect and adapt to make improvements and learn as we make those improvements, as we move forward. So, that would be my takeaway.
So, thank you for that. And again, we’re about to run out of time but I do want to share… So, DevOps Institute, partially in response to the fact that a lot of our in-person events are no longer being held, and also because we have such a global community, we’re introducing a series of micro conferences, virtual micro conferences, known as Skillup Days. And the first one’s going to be about value stream management. And you are going to keynote and tell us, in more detail, about metrics. And so, do you want to give us a little teaser on your session?
Sure. So, I’ve talked a little bit about metrics today. I haven’t mentioned COMMS, I’m sure a lot of people listening will be familiar with the DevOps acronym of COMMS and the importance of measurement. So, I’ll be exploring why measurement is so key, how we need to do it, leadership’s role in it, the kind of key metrics that you can start with when you’re looking at value streams. About how to get to and how to evolve to a capability when you’re inspecting flow on a day to day basis and you’re really focused on that.
And then, the last bit I’ll really be looking at is how to actually measure value. So, what is value? Which is a really big and difficult topic, one of the most difficult, I think, that I’m working with my clients at the moment. And sometimes it’s as simple as revenue or basket size or NPS but often it’s a pretty complex thing to do and very difficult to map a user story’s value back to a CEO’s goal, for example.
And so, thank you for that. So, for those of you who are listening, Virtual Skillup Day is a free online micro conference. Helen’s going to be our keynote, joined by some other well known industry thought leaders. And so, I’m hoping that you’ll go up to our website and register. Again, it’s a free micro conference, there’s even some giveaways and there’s an exhibit hall and a networking lounge. So, the goal is to connect the humans of DevOps. Helen, thank you. This has been really insightful for me and I’m sure for those that are listening. Really understanding, not even only how to measure, how we create value for customers, really resulting in an exemplary customer experience. But also, the human perspective of it down to how our brains work. Right?
Everyone’s being told to change their culture, everyone’s being told to upskill, everyone’s being told that it is the humans of DevOps. But really understanding in more detail how our brain, which obviously is an important aspect of how we learn, how our brain can absorb and how we can motivate people to take on that journey and feel good about it. Incredibly invaluable.
So thanks again, appreciated. Look forward to Virtual Skillup Day on April 30th, with you. Appreciate it.
Thank you for having me.
Yeah. Anytime. You are always welcome to come back and talk with me and the Humans of DevOps. So, appreciate that. So, thanks to everyone who’s listening, this is Jayne Groll, CEO of DevOps Institute. You’ve been listening to an episode of the Humans of DevOps podcast, specifically about value stream management. Have a great day.
Thanks for listening to this episode of the Humans of DevOps podcast. Don’t forget to join our global community to get access to even more great resources like this. Until next time, remember, you part of something bigger than yourself. You belong.