Tag: value stream management

Transcript

Mitch Ashley: Hi, everyone. This is Mitch Ashley with devopsy.kinsta.cloud, and you’re listening to another DevOps Chat podcast. Today, I’m joined by Steve Boone, head of product management at HCL UrbanCode. Our topic for today is extracting value stream management from your existing DevOps culture. Steve, welcome to DevOps Chat.

Steve Boone: Hey, Mitch! Thank you so much for having me here today. It’s an honor.

Ashley: It’s an honor to have you on. We appreciate you joining us. Would you start by just introducing yourself, tell us a little bit about what you do at HCL UrbanCode and a little bit about the company?

Boone: Yeah, absolutely. I’ve been with the UrbanCode brand now for a little over 13 years. If you’re not familiar too much with UrbanCode, back in 2013, we were acquired by IBM, and then just recently, about two years ago, we entered an IP partnership with HCL. Which is fantastic, because then we have both the likes of IBM and HCL investing into our whole portfolio of UrbanCode products. You know, everything from continuous integration, continuous delivery, release orchestration, and lately, we’ve been turning our eyes towards value stream management and trying to focus on how we can help enterprises take that next step and challenging and kind of solving what we think of are day two DevOps challenges, you know? Kind of overcoming the fact that now that we’ve got all this automation, how do we take it to the next level, how do I identify the new bottlenecks that are emerging in my organization and become more successful? I think, ultimately, that’s what we’re all trying to do.

Ashley: Absolutely. We should start with a little bit of a definition. How would you define value stream management?

Boone: Boy, it is a great question. I think it is very much kind of an emerging market. When we think about value stream management from an UrbanCode perspective, we’re really looking to make sure that the work that our development teams are doing is one, aligned to be overall business goals, right? And then two, we want to be able to provide the data and information that’s important for not only development teams but testing teams, designing teams, for them to be responsible for what we would think of as their own value stream.

And when we think about it, it’s really the idea of how do I take something from idea and move it all the way into, let’s say, production or my customers’ hands? But what are all the different steps along that journey, right? That’s really what we think of as the value stream.

So, have an idea. Eventually, that idea turns into some item in my developers’ backlog, and then I wanna progress those several sets of ideas that equate to some business value. And, you know, years prior, in the throes of the DevOps revolution, if you will, you know, a lot of the things that people would say—“Well, your bottleneck’s clearly in deployment automation” or, “It’s clearly in test automation.”

And that’s just not the case any more. I mean, many of these companies have invested millions of dollars in people, process and tools, right? And now, they’re starting to come back and go, “Well, great, we’re doing all of these things. How do we get better? Where are my new bottlenecks?”

And value stream management really looks to kinda shed light on that space and help people understand where the new bottlenecks are emerging within their organization.

Ashley: Excellent definition. I totally would agree with how you’ve laid it out. Validate if you think this is a correct or help me advance the idea a little bit—it seems like value stream management has come on the scene because things like agile, lean, DevOps, very dynamic processes that are creating software, doing work in much smaller increments, much more flexibility about how you pivot, adjust, take on the next story in an agile way, whatever it might be. But that also can be very confusing and opaque to the organization, trying to understand if we insert money here and requirements for products here, what do we get out? And the value stream management is maybe a reaction or a way of putting kind of a systemic view on what’s happening in all of that process so we can understand both where we’re getting the value and are we getting the things that we needed to take to market as well as continuous improvement and how we can get better.

Is that on track? Do you think maybe that idea needs to be advanced in a little different direction? What are your thoughts?

Boone: No, I think the market’s really early, and I think that what you’re saying reflects that, right? It’s a very big message that I think value stream management is trying to take on.

I kinda look at it as a couple of things, right? I think you’re right. There are many different development teams within an organization. I think these days, many of them would raise their hand if you said, “Hey, are you an agile team?” You know, having many agile teams doesn’t really necessarily make an agile enterprise, right?

And so, the question becomes, what are we doing differently across these teams? How do we surface best practices? How do I gain visibility into the work that these teams are doing? And how does that roll up?

So, if I am a C level executive and we say, “Hey, you know, we wanna go invest in these new features and functionality”—well, what’s the right technology to do that in, what are the right teams that we should handle that onto? What are those teams currently working on?

All of those become very important questions. And I think, more importantly, when you look at the investment that these organizations have made over the last 10 years in DevOps, there’s a little bit of kind of mounting pressure to be able to show an ROI, you know? Out of the people that we’ve invested in and the processes that we’ve been working on, the tooling that we’ve acquired, is it paying off? And if not, why not? What do we need to adjust?

Ashley: Yeah, excellent. I think you’re right and I appreciate you saying that up front. It is emerging, it’s still kind of being formed, and we’re early in this process.

One of the things that enterprise organizations tend to do is, they don’t always like to be first in something. They like things to be proven out. Not always, but you don’t want to be on the bleeding edge of everything. How are enterprise organizations approaching value stream management in these earlier days? Are many of them jumping in, are a few taking the lead, and there’s other followers? How do you see this unfolding?

Boone: Yeah, you know, it’s kind of been an all at once thing. I don’t think any organization is unfamiliar with the concept of value stream management. What we’ve seen is, they typically go through some kind of value stream process once or twice a year where they’ll look at from kind of a large, 1,000 foot picture, how is the organization working together, right? How does work turn in this giant crank, and how do we improve it?

But kind of the theory of DevOps, right, we want that fast feedback and once or twice a year looking at your whole organization and how ideas move through it—that’s not really effective, and it’s definitely not feedback for the people who are doing that work.

And so, what we’re starting to see is management try to give teams the tools they need to control their own value stream and to be responsible for that value stream, right? In a large company, they’ll say, “Hey, we’ve got value streams everywhere.” HR could be its own value stream—how we hire and train new employees into our organization has an impact on the type of work we’re able to deliver.

From an UrbanCode perspective, we’re focusing on value stream where we know best, which is continuous integration and continuous delivery. So, we focus on looking at the tools that are in our space, whether those are deployment tools, build tools, testing tools, source code tools, and then we start looking at, “Well, who are all the players in a typical development team that advanced these ideas?” Right? You know, our development teams are dependent on design teams. They’re dependent on testing teams.

And all of those have an impact in things like lead time and cycle time and mean time to recovery. Kind of the main types of things that, if we were to look and ask somebody, let’s say DORA, the types of metrics they care about and, you know, identifying high performing teams and being able to look at other teams and say, “Hey, look, these are kind of metrics we’d like to see you improve upon.”

So for us, we’re looking at the value stream very much at a kind of AppDev/Operations level, but with big business value in how you can roll that up to the business, and justify the work that’s being done, justify the investments that are being made and to continue to recognize areas of improvement within that DevOps culture.

Ashley: Well, it seems as organizations evolve and their adoption of DevOps eventually run into what were traditional stage gates, maybe you can view them as barriers, stopping points, because the rest of the organization is not set up to operate in that kind of dynamic flow, and it has traditional kind of waterfall processes. It seems like what you’re doing with UrbanCode is, you’re not only automating and integrating that at full CI/CD process across the tool set, but you’re also giving information that ties back into communicating some of those things that will help teams more easily flow through, pass, or if it is a stop, it’s minimal, because you’ve got all the information there that you need to say, “Are we ready to go into production?” or, “Were these things in the release?”

Is that how you’re connecting kind of value stream to the dev process?

Boone: Yeah, that’s right. I mean, one of the key things we look at is just, you know, where are these ideas that developers are working on store? Well, you know, typically, they’re in something like JIRA, right, or RTC—but there is some backlog management that is holding these really brilliant ideas, and they’re in the form of Epics and work items and they’re tied to sprints and releases.

And so, you’ve got all of these ideas, and they’re all in motion. They’re all at some stage of work. They’re either sitting in a backlog or they’re being designed or they’re in progress or they’re in review, or they’re being merged, they’re being built. And that idea has a journey. It has a history and a life, and if we can start kind of surfacing that journey, then people can start seeing how ideas flow between various different teams, right?

And everyone’s trying to do the best that they can for their group, their team, their application, their project. It is by no means about pointing fingers and saying, “Oh, well, we were held up on this release or this particular value, because it didn’t come out of testing fast enough” or “We didn’t get the designs fast enough.”

But it is about surfacing the relationships between these different teams so that we can start having meaningful conversations with the right folks to improve these small bottlenecks that kind of crop up from time to time within our own internal processes. And, you know, very much like we talk about people, process and tools, at the heart of that is culture, right? And I think one of the really cool things about value stream management is, executed correctly, we can really start to enforce that DevOps culture and kinda stoke the flames of that, right? Reignite in the creativity and really get people bought in on the sense that it’s not about one individual team or application, it’s about the enterprise working together to deliver value for our customers in the most efficient way possible.

Ashley: I love where you’re heading with this. This seems like one of the potential natural reactions of the DevOps team or development organizations is, since the organization hasn’t quite worked in that kind of an environment, value stream management could be seen as a way of gaining control, which is sort of the dark or the negative side of this. Another way to look at it is bringing transparency and giving, you know, really looking at a systemic view, as I mentioned earlier, across this.

Have you seen that reaction of kinda pushing back against value stream management, because this sort of feels like the big brother kinda coming in and trying to grab control, or do DevOps teams pretty quickly see where the value is and start to embrace it?

Boone: Yeah, I think it’s a couple—I mean, I definitely, I think back to the earlier days of just continuous integration, right? We have that thing where, if you broke the build, you’d get the big red light flashing in the dev pit and people would look and be like, “Oh, he must have broke the build over there” and—

Ashley: The wall of shame. [Laughter]

Boone: You know, you’d have to—yeah, it’s like, you’d have to wear the dunce cap. I think we’re far away from those days, but there is still some hesitancy, right? I mean, the reality is, if you go into a lot of organizations and say, “How is your DevOps journey going?” they’re gonna go, “Oh, pretty good. We’ve added a lot of automation. We’ve invested in a lot of training. We feel pretty confident about where we’re at.”

So, any time you walk into a dark room and kinda turn that flashlight on and see the real data for the first time, there can be some alarming things there, things that people didn’t necessarily now about. You know, maybe some quote-unquote skeletons in the closet, so to speak.

But what I’ve learned is that development teams, they really want to be the best that they can be, right? They wanna deliver high quality product and they wanna do it in a bleeding edge, fast way.

And so, if we’re giving them the feedback of how their work is moving, and if they can see where things are breaking down, they tend to do the right thing. They have the meaningful conversations and they improve and take responsibility for their own value streams. And that overall starts to drive the business that much more efficiently, right?

So, I think that’s one of the really positive aspects about it is it gives people the tools needed to take that responsibility. And then, sure, as we roll that data up—so, you know, you provide value to the development teams, that data and that value then rolls up to the upper levels of management, so they can effectively run a business, right? I mean, at the end of the day, there’s still a whole lot of money tied up in these organizations. So, if we wanna put together a new plan, a new set of functionality, if we wanna be first to market, we wanna make sure that we’ve got the right teams, we’ve got the right technologies and platforms, and that the efforts that we’re investing in are aligned to the business goals.

And so, there’s kind of a win-win for both sides of the house. You know, the AppDev team wins, the business wins. And where we really think we can make a lot of impact is, some of the groups that maybe haven’t quite felt as much love in the last couple of years in the DevOps space—I’m talking more about our folks that are sitting in operations, security, testing, maybe some of the folks that are more focused on our agile success.

You know, we see more and more of these high turnover rates of developers and management within organizations. You know, as you move from company to company, the definition or the implementation of agile best practices is probably a little different and maybe even changed, right?

Ashley: Mm-hmm.

Boone: So, how do we make sure that everyone understands how our business works, how things are working here and so that we can constantly be working to improve that process?

Ashley: You know, one of the things that I get asked frequently, both by individual technical experts, developers, even leaders of technical organizations is how can we better communicate with the C suite. And usually, it boils down to, you have to talk in business terms. You know, how is this investment or this money, whether it’s a process improvement or a technology, helping us increase revenue, bring in new revenue streams, improve customer experience, reduce churn—which is always kind of a famous one, catch all.

But you have to put it in business terms, and it seems like if you believe in what you’re doing, if you believe in DevOps—and we know it’s not all perfect, we’re all a learning organization—that transparency can help you get very quickly to say, “Why is investing in another test tool, or investing some time in re-engineering, a process worth spending the money on it?” Because we can see the results of it and we can also have a way to communicate what we’re doing and the value of doing that.

Boone: That’s exactly right. I can give you kinda two classic examples of that. You know, right now, we see a lot of companies trying to rearchitect or modernize their applications to speed up delivery, right? So, we’re taking distributed applications, we’re building them into microservices with the idea that they’re much easier to manage from a configuration and a delivery standpoint.

Ashley: Mm-hmm.

Boone: But there’s a cost associated with taking a team of developers and saying, “Hey, you need to rearchitect this thing.”

Ashley: Absolutely.

Boone: So, you basically need to build it from the ground up, but you also need to manage the existing business value that’s keeping the lights on.

And so, if you’re gonna make that investment, you know, six, seven, eight months from now, even while you’re making that investment, you’re gonna wanna be able to know how long does it take for us to actually do this? Is this something we can repeat elsewhere in our organization? Does it make good business sense to do that, or should I just focus on building new microservices and new applications and not focus on rearchitecting?

Ashley: Mm-hmm.

Boone: You know, other places where we see this manifest is, you know, one of the things that constantly can be what we call a drag on a team’s velocity is things like unplanned work or incidents that might pop up, customer support. It would be really easy for management to say, “Well, we’re not getting what we need from this development team. We need to hire more developers. Obviously, if we throw more people at it, that’ll fix any issues we have.”

But what kind of people, you know? It could be that we need more support engineers, we need more designers, we need more testers. And so, understanding where resources, people are, the type of work that they’re doing, where that work gets held up is extremely important to understand what kind of folks we should go hire, what kind of training might we need to improve that culture that we’re trying to establish?

Ashley: Since you’ve kind of been engaged in the value stream management part of this, are there—have we gotten to a point where you have maybe a couple of best practices, “if you’re implementing this, kinda going down this journey, some lessons learned or make sure that you do this” kind of thing, trying to lead you to the best chance of hitting a home run or at least a first experience with value stream management?

Boone: Yeah. You know, when we first started talking with customers and they’d say, “Well, how would we get involved in understanding our value streams better?” We like to do small workshops, right? And a lot of it starts at a white board with some open and honest conversations, right? Again, the whole idea is, we’re not really here to point fingers, but we’re here to understand how we get better.

We sit down and start to think about—okay, well, if we get a brand new idea from the business, what is its journey? And I think if you get five or six different people in the room, they’ll come up with the 80% of the journey and then, through more conversation, you’ll start to understand—yeah, well, sometimes, we’ve gotta pull in these different shareholders. Or sometimes it gets held up in kind of political red tape of approvals and sign offs and we don’t get those for weeks at a time.

So, you start to air some of that laundry, but at the same time, you really start to get to each individual step of the value stream and the journey that it goes through.

Once we kinda have that planned and visualized out end to end, then we can start looking for areas of improvement, right? And I think those are kinda the basic things I see companies doing now.

The ones that are being a little bit more aggressive are starting to visualize these different processes as they change state. So, they’re getting to where we can start mapping and tracing the actual journey of a work item, from commit to pull request to actual code merge to build, deploy—you name it.

And, as part of that, they’re starting to look at some of the tools that are out there. You know, UrbanCode Velocity is great if you’re looking to get started for a two person, or I should say a two ____ team. You know, pull it down, the community edition is free to get started with and start integrating your tools. And you can start seeing these work items come to life and see how they start to propagate all the way from your back log, hopefully into your customers’ hands.

And it’s been a pretty eye opening experience, I’d say, for a lot of teams, because they’re learning quite a bit about their own processes, and then having really meaningful conversations with other teams, kind of an, “Oh, did you know? Hey, are you guys seeing the same type of process bottleneck within  your own organization?” And it’s been fascinating to watch.

Ashley: That’s super helpful and I appreciate your thinking around let’s start with the fundamentals, laying out the process, and getting agreement about where we are and then start to instrument from there, and you all do some great work with UrbanCode and having that community edition is really a kinda low barrier, low resistance approach. You can just bring it down, download it, start working with it and understand how you can start applying it to what you do. It’s a great, great tool.

Boone: Yeah, thank you. We’re really excited about it, because it is a very new space, but we kinda see the opportunities abound in front of us for being able to improve not only how people work day to day, but improve the culture that they have for the folks around them. Building software is exciting, and at times, it can be quite stressful, right? And I think that, as people show up to work every single day, one of the things they wanna do is be a part of a culture that’s supportive, that’s creative and that can help them be the best people that they are.

And I think value stream really gets to the culture of DevOps, right? How do we make sure that what we’re doing as an organization is for the best of the business? and make sure we’re giving people the tools they need to succeed.

Ashley: Mm-hmm, absolutely. Well, Steve, thank you very much for being on DevOps Chat with us—Steve Boone, head of product management for HCL UrbanCode. Steve, thank you.

Boone: Mitch, thanks so much, again. It was a real treat.

Ashley: And of course, we want to thank you—you, our listeners, for joining us today. This is Mitch Ashley with devopsy.kinsta.cloud and you’ve listened to another DevOps Chat. Be careful out there.

— Mitchell Ashley