Bob Davis of Plutora on DevOps and Value Stream Mapping

Introduction [01:17] 

Shane Hastie: Good day folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. I'm sitting down across distance with Bob Davis from Plutora. Bob, nice to meet you. Thanks so much for taking the time to talk to us today.

Bob Davis: It's great to meet you too, Shane. And I look forward to covering some interesting topics here in the next half hour or so.

Shane Hastie: I look forward to it. I suppose, a good starting point is who's Bob.

Bob Davis: Bob Davis is a startup junkie and for the last 35 years, this is my 10th startup. Right out of college, I joined Intel and that's the last large company I ever signed up for. I made my way to a few large ones through some acquisitions, but I've always been more on the startup side. I'm a creator as a result. I like to build things. And the most fun I have is when we're creating new opportunities and new markets. I used to tell my kids when they'd asked me why I did what I did. And I'd say, "I want you to go when you're in school and you're reading the history of IT and computers that you can look and say, my dad was there." Because I was involved in some of the most ground-breaking technologies that existed over that period of time and it's been just a blast. And I feel like we're in that space again with Plutora.

Shane Hastie: So tell us a little bit about Plutora. What do you do there?

Bob Davis: First of all, Plutora is in the DevOps space. It's a product that is used by organizations to get a better handle on their development process. It's part of an emerging market category called value stream management, which is a capability that looks at software development from the moment I have an idea or a customer request all the way through to when the product is in production. And it's making money or cutting costs or it's making life easier or whatever it's intended to do, it's doing that. And the question then is, did it work? So companies that have invested in DevOps tools, be it automation capabilities, testing capabilities, planning capabilities, deployment capabilities, millions of dollars are now starting to say, "So did it work? Are we faster? I read better. Is our software more competitive?"

Bob Davis: And that's where value stream management comes in. It starts to look at the business of the organization and to answer the question, what's the value that the software development process has provided to that business? And it's a very exciting time because that's software is eating the world as Marc Andreessen said. And people are using it to become competitive and value stream management is being used to optimize. And that becomes the best competitor organizations can.

Shane Hastie: Wasn't this what we've always been trying to do? I think of showing my age, going back to some of the sequential software development life cycles, there was always a reason why we're doing it. Most of the time we lost that along the way with agile development shrinking those cycles to get feedback with dev ops, it's shrinking it even further. So how come we need this overlay now?

The value of exposing the value stream [04:21]

Bob Davis: The classic case when we talk to prospects is they'll come to us and say very much like he was just saying, Shane, "We've been operating so successful for so long because the companies that proved to ourselves to, just as a quick sidebar, are our global 2000 organizations that are in long-standing industries, financial services, telecommunications, healthcare, pharmaceutical, those kinds of people. So we're not talking about the unicorn Silicon Valley software developer. We're talking about businesses that have been in business for literally hundreds of years, in some cases. And have a lot of legacy equipment, software applications. And you're right, all through those hundreds of years, they've worried about delivering value to the customer. They worried about quality. They worried about all those things. But now they're coming to us and they're saying, "Look, two, three, four, 10 years ago, I released maybe once every six months."

Bob Davis: I'd release software once a year, once every six months. And I could do a lot of things manually if I had time. I could keep track of my schedules on Excel spreadsheet. I could share information about what I was building in SharePoint or Dropbox or something like this. Now people are being asked to release much more quickly, and those processes don't work well in that scenario. In an effort to deal with that, methodologies have arisen, and the lean agile methodologies have come into their own over that period of time. DevOps really came about a little over 10 years ago in an effort to, as you said, break things up, iterate faster and move through the development cycle more quickly so I can release and provide value more quickly. The problem is that the tools and capabilities were all very specifically focused. Three, four years ago, people worried about test automation. I want automate tests.

Bob Davis: I want to buy a test. I want to buy a build or a CI server or a build server. I want to buy the deployment server or deployment capability and automate that. The problem is as that started to creep in, you ended up getting a little quick win here and there, automating a process, getting a little faster, but in the end, your process has actually slowed down. Your technical debt increased because one group might be doing automated processes and using the very latest two tools. And they're getting things out very quickly, and it's going to the next segment of the development process, who may not have the benefit of those tools and they get stacked up. So they get behind. So the very point about quick iterations is now being conspired against by work back.

Bob Davis: Your work in progress, your WIP, is increasing. Your technical debt is increasing, and your ability to get things out the door is compromised. So the question that is why? Why is that happening? And it's that question that generated this whole move towards that higher level. Because it's like, "Well, where am I waiting for proper work for things? Where am I losing time?" And the notion of value stream mapping started to come up and this idea of looking at my design process, and it was very manual. It was done with sticky notes. And looks like you could have one behind you there. Because it's like a Kanban board of sorts where you've got your sticky notes and you said, "Okay, here's where I'm doing work. And here's what I'm waiting for things." And trying to answer the question of how long does it take me to get something out to a customer?

Shane Hastie: Yeah. So value stream management is an idea from Lean manufacturing and Toyota?

Value stream management to have a common view of the pipeline [08:14]

Bob Davis: It absolutely is. It carries an incredible parallel to that process of saying, "First of all, I want visibility." In fact, we referred to value stream management as a catwalk across the software delivery floor. 30, 40 years ago, they had those catwalks across, and people were able to go around. And they had to the cords. The andon cords that they could pull and say, "Okay, I've got a problem. I want to stop the process, fix that, and continue." And that created quality circles and all that stuff. And this notion of value stream management, old concept, 1950s, put it on the shelf. And it was about years ago, fast forward to two years ago we're forced to research. And Chris Condo, an analyst, wrote the first document on applying value stream management concepts to the development process. And it said, "What I want to do is I want to connect the dots across all of the different tools that exist in a tool chain from my enterprise agile planning tools like Jira, for example, to my automated testing, and maybe my build tools.

Bob Davis: You often see Jenkins a CI server, very, very common. A lot of tools, you want to Ansible, different things along the way, lots of different tools. Digital.ai, formerly CollabNet and Xebia Labs. Xebia was the author of a periodic table of elements for DevOps. There was hundreds of tools. So, value stream management sits on top of that, connects all those tools together, brings that data into a common data model, normalizes it, gives you the ability to analyse it, automate it, provide alerts, set up standard processes to ensure compliance and governance. And I can do that without intruding on the developers’ actions at all, they continue to use Jira. They continue to use Xebia. They continue to use whatever they want and all that information is correlated and used by product owners and release managers to orchestrate the process all the way up to production. And it's proving to provide incredible savings.

Shane Hastie: So, if I'm an enterprise software programmer or team lead, what does this mean to me?

The value of visibility [10:38]

Bob Davis: If I'm a programmer, I shouldn't have to worry about value stream management quite frankly. I want to worry about doing my job. I'm going to program. I'm going to be on my two pizza team and I'm going to be doing my programming. And if I'm a team leader of that team, I've got my tools. I'm using my development processes as I'm keeping track of my requirements. I'm executing on my story points with value stream management. I'm assured that I can do that seamlessly without worrying about people coming in, asking me every five minutes, the status of my project, that I can understand when things that I'm depending on are going to be available. Most applications are not individual value streams. They have many connections and dependencies across multiple applications. Even the simplest iPhone app might be calling upon a database that's sitting on a mainframe on the other side of the world that has security issues and whatnot that need to be adhered to. My iPhone app is updating every day it seems. And that backend database can't possibly do that.

Bob Davis: So if I'm a programmer working on that front end and I don't have any way of understanding the status and progress and where things are and when things will be available to me, my job becomes incredibly frustrating. I think people, humans, react poorly to ambiguity, react poorly to waiting without a promise of when; look how grouchy people get in long lines when the line isn't moving. So, if I'm that programmer and I'm dependent on those other teams, if I'm waiting for them, I get frustrated really fast. From a culture point of view, from a behavioral point of view, from a job satisfaction point of view, teams that are better correlated, have better communication, and can collaborate seamlessly or happier. They are more productive. Over and above the math of a duty cycle and the positive nature of a value stream that's efficient. Just the people, it's more pleasant to work in an environment where you say people are doing their job and it's easy.

Bob Davis: Alerts are provided. If I need to do something, it becomes very clear, the system reminds me. And it does so through my normal means of doing my job. If I like Slack, I can set it up so I get a Slack message. "Hey, Bob, you need to go back and follow up on this test. Your recent test failed, go back." I can get that Slack to me, or I can look at a dashboard in my application. So, I've got lots of flexibility and I can get the information out. It makes my life so much easier. Keep in mind that the practitioners span along a broad area from the program office in the planning, budgeting capabilities, to the deployment guys sitting up.

Bob Davis: And so often, these guys don't know what's coming. So, a big complaint on the deployment side is that I'm getting two, three weeks of newest to do full deployments. That's frustrating, people don't like that. It's the Thursday before a long weekend, I've got a holiday planned and you show up with three applications that have to be deployed by Monday. Couldn't you have told me this ahead of time? It's that thing. You literally get those issues. And if that can be smoothed out, life is so much better and software will respond. We'll be happier. Happy yourself.

Shane Hastie: One of the things that we're seeing at the moment, given the state we're in, the changes that are happening around the world, particularly with that move to working from home, working remotely, these two pizza teams don't often share pizzas anymore. They might have a Zoom meeting where they're chatting about pizza, but not actually eating the same pizza. What is that indication there? And how does thinking about value streams help us in that regard?

The value for virtual teams [14:29]

Bob Davis: That is just a huge issue. The world of software development and DevOps and agile, were already moving in the direction of distributed teams. And these two pizza teams, that was the idea. And now we've got distributed teammates and it's not going away. People are going to be working from home in droves.  Gartner study said 74% of the companies they interviewed would have some heightened work from home policies where they didn't have them before. So, it's here to stay. The agile manifesto, which set out to describe how agile processes can be built out in organizations suggested that the best way to communicate was face to face and that spawn the stand-ups and the daily interacting and the value of that human condition. Obviously, that's broken. So that's a huge problem. At this part of the conversation, I will sometimes hear, "Well, that's not such a big deal, Bob, because people have been doing remote development forever. Look at the whole open-source movement. It's all remote development. Why are you suggesting it's so difficult?"

Bob Davis: And my answer to that one person asked me is I said, "Okay, let's take that, for example, let's compare two people from those two populations." An open-source developer sitting in Silicon Valley somewhere, but having a cup of coffee, pounding away on some code, and posting it, and getting it. Compared to that person with a developer, sitting in Bank of America and described to me all the things that are common about them. I think your list is really small. The issues of security, compliance. It's night and day the differences. You have a tremendous amount of overlap in teams from a standpoint of dependencies, from the standpoint of handoffs, you just simply can't walk across the hallway and say, "Hey, Shane, how you doing on that piece of code? Let's get down…" You can't do that.

Bob Davis: If I have to wait to schedule meetings, then I've got inherent delays. Even if we say we're going to meet every Wednesday and sort through our problems, what if I have a problem on Friday? Now I've got to wait till Wednesday, or I'm got to call you. It's disruptive. All of those things conspire against remote teammates who are working on a common goal. And in our customer base, compliance and governance trump all of that. If I can't get traceability, if I can't prove that I have repeatable standardized processes that meet the needs of the compliance standard, then I might have millions of dollars in fines. There are tremendous requirements, there's a tremendous need, and there are tremendous hurdles in the way of accomplishing working remotely.

Bob Davis: So when office workers work from home, they use Zoom, they use Slack, they use whatever collaborative tools. The equivalent of that in software development is something that will have the ability to communicate changes, handoffs requirements, issues, in real time, exactly when it's needed to every stakeholder that needs to know throughout that entire chain. And a collaboration tool that is instrumented across all those people and can provide that level of wording, solves the problem of handoff, solves a problem of dependencies in the sense that I know where my problems are.

Bob Davis: And so now I'm only calling you Shane, when I've seen that you're delayed and now we have to come up with a plan B because now I can't meet my needs. The scope of the application will need to change. Let's talk about it. So, my conversation with you as one of making progress on an issue, not one of uncovering the issue. The system shares the information and helps me uncover the issue. The conversation and the human involvement is about making progress. And that's what people need to do. Systems need to keep track, keep score, and the humans need to play the game. That's the value I think ultimately is it makes that interaction efficient. So it happens when it needs to. It makes it important. So unnecessary communication doesn't have to get in the way. There's also a whole other angle here, is one of management.

Support for management [18:46]

Bob Davis: If I've got a team and I imagine a remote team, how do I keep track of whether or not they're able to manage it? So I've got big teams that are thrust into working from home. I've heard a number of different stats about people that do really well, working from home versus don't do really well working from home. It's clear, regardless of your perspective, that a 100% of the people don't do well working from home. So I've got to manage that. How do I do that? And I couple that with a really interesting phenomena that works against that. With work from home culture, humans crave human connection, human content. Humans are social. "I want to talk, I want to get involved." So you have two contradictory forces, "I want more contact. I want more connection with humans, but I want the least management oversight. I want to know you trust me. I want to know what my goals are. If I feel like you're constantly second guessing me, I'm going to feel really anxious. And the fact that I'm remote is going to make that worse."

Bob Davis: So there was a big study done about trust, and common alignment of goals and objectives has been key to keeping people motivated and productive and happy. And that requires that I reach out and work with you, but I can't be on your case all the time. I can't be, "Hey, did you finish that? What's going on?" So a tool like this helps keep track of the KPIs of progress in the background. So I, as a manager, can monitor who's having problems and who's not having problems by just watching the flow of information through the pipe. And now I can see where the issues are. I can say, "Hey, this team is having a problem. So let me work with that team because that, we're slowing down here. I've got to be able to do that."

Bob Davis: And it isn't about judgment, it's about getting better, improving. And that's what the metrics are for. And all of this, those KPIs and metrics are not on judgment. They're not about retribution, they're about improvement. And some people worry about the metrics. They think this is big brother and that developer, you asked me, what's it mean to him? He might say, "Hey, you know what value stream management means to me? It means they're looking over my shoulder. And I don’t like that." I would caution against that view because that's not the point. Most of the metrics are team-based and they're trying to look at where those teams are struggling. And it may not even be their fault. And probably isn't. It's probably more a gap in process, and we can identify those, fix those. And that's what the value stream map does, is it shows me where all those holes are and allows me to apply change and make progress and improve.

Shane Hastie: So how do we keep it safe? We know that the trust and the psychological safety... So how do I create that environment where the developer doesn't feel that they are being judged by the metrics, but they are genuinely being used to support and help and identify bottlenecks?

Ensuring psychological safety [21:53]

Bob Davis: And the answer to that question, you're getting a management style. That very question could be asked about how do we keep demand gen marketing people motivated and happy? It's really the same question. I think what value stream management can do as a tool to help managers provide that environment for their practitioners, for developers, is that you now have the means to be able to tell those developers exactly how much value they're delivering to the organization. Every engineer I have seen in the past loves to see their product in the real world. There's a guy that lives in the neighborhood here that was very involved in the development of Siri. And every time, if you're in a bar and you hear Siri come out, I was there. I did that, a huge amount of pride. And I think that's what people love.

Bob Davis: That's why they're developers, they're creators. They want to build something. That I think is the key, is not just to tie the value to the IT for the business management, but tie the value to IT from the human management, celebrate the victories, point out, "Hey, do you realize that that work you've been doing, Shane, has generated $7 billion in savings over the last decade? That's pretty amazing." And you go, "Wow, that's awesome." And that feeling will overcome a tremendous amount of frustration, I think. That's when you get people say, "It makes it all worth it." That's what I think we try to do. And that's what we try to do as we set up processes, is really tying into the value metrics and get people thinking about that. The other thing I would say, Shane too, is a management can measure pretty much anything. We can measure any metric we want, but we can't decide what metrics we want because we can't measure it.

The dangers of the wrong metrics [23:41]

Bob Davis: The question is, which metrics should we use to apply compensation to? If I've got a sales guy then I'm going to comp them on revenue. If I've got a developer, what am I going to comp them on? One of the things I heard a guy, they were tying the compensation to MTTR. So MTTR is the meantime to repair. So how long has it taken me to repair an issue once it gets found out in production? And the goal is to make that short. So if I manage MTTR and I'm comping my ops guy, I'm going to comp them on seeing that MTTR stat go down, make sense until you learn that's not how it works. Because if you have really good processes, the simple problems get fixed right away because you're testing as you code. You've shifted left, you following the rules of modern development. You're finding the errors as they appear.

Bob Davis: You're fixing the easy ones. So what areas, what problems, what bugs are actually getting to production? Bigger ones. Those take longer to fix. MTTR goes up. Is that bad? Or is that good? Based on the scenario I just described, it's arguably good. So if I'm comping somebody on dropping that, I've got a conflict. And there's a lot of those examples. So I think that value stream management is very powerful. And the capabilities that all the vendors bring to the party in value stream management are many. It's an embarrassment of riches. The biggest thing you need to do is really keep the goal in mind, as you implement your process, what are you trying to achieve? And everything you do needs to follow those rules and needs to help you make the decisions of which metrics, how should I tie these things together? Once you do, a process like value stream management would makes working from home, not just work, but it makes it work better. So that's exciting, fun time.

Shane Hastie: But fraught with risk. If I think of the metrics one, in particular, so often we do measure the wrong thing.

Bob Davis: We do.

Shane Hastie: And we incentivize those bad behaviors. So, if I'm a manager, if I'm trying to figure out what is a useful combination of metrics, what are the things that I'm looking to understand?

Finding the right metrics for your context [26:19]

Bob Davis: First of all, I think you're going to need to understand the maturity journey you're embarking. That's a question that leads to a conversation that we have on every implementation with a customer. Where am I on the maturity curve? And what are the next things I need to accomplish from that? And understand that it's not a one-time event. You're not going to sit down as you redo your processes as you're going to have a planning session in January, and that's awesome. We're done work. We're going to be rocking and rolling for the next two years. That's not how it works. It's an iterative process. And as you become more mature, you're going to enter the next objective key result. And you're going to be looking to take the next hill and hit the next milestone. And as you do, the metrics will change. So the first thing is, is you have to acknowledge and understand that they will change and understand what you're trying to accomplish and every step of the way.

Bob Davis: So the metric is certain to get you to where you're trying to go. And the fact is that the metrics will become obsolete. In almost every case, they will become obsolete. And had a really interesting conversation with a client one time where we were talking about velocity and the notion of speed. Because that's where everybody gravitates towards. I need to be fast. What else is there? I need to be faster. Okay, well, faster is good. I can see why you need to be fast, but what happens in the most elite organizations that deliver on demand? Amazon, I read somewhere, was releasing software 10,000 times a day. Now when I'm releasing software that frequently, on demand, so it's showing of when people need it, is velocity really that important. I would say probably not. It's really more about the degree to which those releases are satisfying the customer.

Bob Davis: So NPS score might be a better measure at that point once I get there, because that's why I'm releasing so quickly. I want to delight my customer as they start to react to that, it starts to go up. So it isn't so much like there's one or two specific pieces of advice change on that. It's really more like got to know where I am and then I need to master that stage with the idea that I'm getting to the next stage. And the ultimate goal is the value of that delivery. And I can never lose sight of that. And that's what happens with people. They obsessed with a particular metric. And throughput is one that they mess with a lot.

Bob Davis: There's a whole another temptation and that is. People will look to try to automate everything. So the very first tendency is I just want to automate everything. In the case of automated testing, one of the things that we've found is people are looking at defects. So looking at the scores of the testing. A really interesting discussion I was in was bubbling up and saying, "Okay, how stable are the environments that you're doing the testing in? How stable are those environments?" Because if I can't make those stable, then my automated testing is going to throw back errors. So if all I'm looking at is the metrics and the automated testing and I haven't looked at them at the configuration metrics of the environment, I'm going to make decisions on the basis of quality that are not accurate.

Bob Davis: So, yes, you need quality metrics, but you need to make sure you're operating within a stable infrastructure. So all those metrics are important. I guess the story I'm painting here is that in every one of these areas, the metrics evolve to a higher and higher level of sophistication as you become more mature. And you need to know that, recognize that. And they're evolving to add some tonality to the goals that you set up for the software you're building, they're evolving to quality metrics, they're evolving to feature complete, whatever it might be. It certainly favors the people that understand what it takes to build a product, because the people that need to be looking at what metrics to track are the ones that have that product ownership.

The need for true product ownership [30:27]

Bob Davis: And that's actually culturally, one of the hard things that companies are struggling with, is where do I find the person that's going to be the product owner in a product focused development team, distinct from a project-oriented development team that I might've had in the past? And that's a really interesting conversation because that individual is hard to find. And we talked to one large organization out of Australia, actually a large telco, who was looking in their HR department for their product owners, not the release managers. It's really interesting where all the organizations are going to evolve to support this.

Shane Hastie: That product thinking and that product ownership mindset is something certainly, and this is probably a conversation for another day, a huge gap that I've seen in the marketplace

Bob Davis: Totally because the product owner is essentially a CEO of the product. That's the mindset. It's, "I own this product. I own every aspect to it. I care about every aspect to it. I may not be responsible organizationally for every aspect too, but I care about every aspect to it. I care about it, the money it's making or whatever the ultimate goal of that application is." So that's a business thought process. If I go into the PMO office where people have been using PPM tools, which is a natural place to look for somebody that's going to be a product owner, but they don't have that notion that they're not business people in that sense.

Bob Davis: So it's a struggle. And release managers are project people. They understand the flow, they understand the details of the product [inaudible 00:32:14], but do they really understand why the CIO care? And how do they communicate where they're at with the CIO? So that's an interesting piece. We've done some work on the role of release managers in a DevOps world and how it's evolving. The follow on from Mik Kirsten’s book, Project to Product, what does that mean to the organization into some of these classic pretty well entrenched positions that are needing to evolve? So as you say, maybe that's another topic. But it is interesting from a human factors point of view.

Shane Hastie: Indeed, and regular listeners will know that I'm a strong advocate of #NoProjects. 

Bob, thank you so much. Some really interesting ideas and concepts that came out here. If people want to continue the conversation, where do they find you?

Bob Davis: They can find me in, I'm at bob.davis@plutora.com. It's probably the best way. On Twitter, @rwdavis2011. That will be the best.

Shane Hastie: Thank you so much

Bob Davis: Shane, thank you. It's a pleasure.