Dr. Mik Kersten

Thank you for coming. We're going to be talking about value stream architecture.

Carmen DeArdo

I'm Carmen DeArdo. I'm joined by Dr. Mik Kersten, the Tasktop CEO. I'm a director at Nationwide Insurance. I'm sure everybody knows about Nationwide and can sing the jingle.

I think the key point of this slide is the size of our IT staff. Cindy Payne and Jim Grafmeyer gave a great talk in this room a few days ago and really talked about our journey, and I encourage you to go and look that up if you haven't seen it. But we're obviously a horse. Our IT staff is like 5,000 FTEs plus contractors. So what we're trying to do here is really across the enterprise.

Dr. Mik Kersten

And I'm Mik Kersten. I'm the founder and CEO of Tasktop, and we've been working with the world's largest organizations in helping support their digital transformations by providing them a value stream integration and a value stream visibility layer.

And this is sort of the reality that, when I talk to the IT leaders at these organizations, they're living in day to day. This is this really neat graphic put together by CB Insights, and it's called the unbundling of a bank. They've got the unbundling of a car, in case some of you are automotive, unbundling of insurance companies, and so on.

And what's been happening is that we've had basically this Cambrian explosion of startups, and these startups are digital natives, and they have these extremely lean and effective value streams. They've grown up in the world of lean, of agile, of DevOps, of product management, and it's all been kind of new.

I like this graphic a lot because what you see is actually the kind of pressure, as you heard in the Wells Fargo talk, the kind of innovation that needs to happen in traditional businesses. Because the startups are much smaller, they're much leaner, and they're going after really small parts, layers of the user experience.

And here you can see this pointing out different parts of the consumer banking experience, and just how many of these startups there are. And they're innovating around the mobile experience, the web experience, and so on. And it's the same thing just across different industries.

So somehow we have to give the larger IT organizations, the horses, the kinds of tools to innovate, to deliver faster, and to compete against this kind of onslaught of VC-backed and well-funded startups.

Interestingly, this is happening in DevOps as well. So this is by GrowthPoint Ventures, another one of these kinds of visualizations, and this is all of basically the new DevOps vendors out there. So again, tons of VC-backed companies, tons of investment.

You actually saw Gene talk today about the deployment age in the talk, but there's basically all this financial capital causing all of this digital innovation that's putting, again, tremendous pressures on businesses across the economy who are trying to get through their digital transformations to get ahead of this.

And what's so fascinating about this is it's caused this incredible best-of-breed ecosystem. There have been major shifts in the industry that have enabled this. For example, it used to be, 10, 20 years ago, that some of our IT stacks were just basically run through the Rational Unified Process, and everything was connected end to end. But everything's gone completely best of breed as these startups, these best-of-breed solutions, and these great tools, many of which you see on the show floor, have just exploded and thrived.

But when we actually then dig in, not to those startups, not to the digital native companies, but when we take a closer look at the toolchains, the value streams of organizations out there, the organizations driving most of the economy still, we actually see this incredible fragmentation that's resulted from these best-of-breed solutions out there.

And so if you look at this one view of the value stream, where you're trying to deliver some kind of business value, bring it to market as quickly as possible, as efficiently as possible, innovate as effectively as possible, these disconnects that you have, and there might be a disconnect between the way that your business partners, your customers think of their requests and how those flow into requirements, and then how they flow into an agile backlog, into testing, into operations, and so on, how things flow back. Those kinds of disconnects, what we're seeing is they've become... There'll be different ones. They're becoming the number one bottleneck on basically scaling software delivery.

This problem is very easy when you're small, when you've got 50 developers, 100 developers. It gets very difficult once you're into hundreds or thousands of developers, different lines of applications and projects and products, and so on.

So what we've realized by digging in, I'll actually show you some results of analyzing the value streams of 300 different companies that we've done. But what we've realized is that we need a much more structured way of looking at this. We've been thinking very tool-centric, we've been thinking technology-centric, process-centric. That's important, but we're not combining these pieces in the right way.

We need to start thinking end to end, and we need better tools to think end to end. And Carmen and I have been talking about this since we first met at the first DevOps Enterprise Summit, is how to take a more distant look at the value stream.

We understand architectural principles. We understand how to make boxes and arrows and put them on slides and in Visio and so on. Why can't we take some of that approach in how we create our value streams? Because in the end, aren't those at the very core of our DevOps transformation, of our agile transformation?

So we're going to share with you in this talk some of our early thinking on that, some of the tools that we've come up with for ourselves that we've been using at Tasktop and at Nationwide, and hope you can take some of that home.

So I think we'll start by basically giving you a walk through the Nationwide journey to how they got to these conclusions, and then we'll show you some of the value stream architecture concepts that we've come up with.

Carmen DeArdo

Thanks, Mik. So I'm going to go through this pretty quickly because, again, Jim and Cindy did a great job about this.

I think the key takeaway is we started in 2006, right? So it's been a long journey. As we've gone through this, what you'll see is we went through an agile transformation, we went through a lean transformation, and then we're now really focused on DevOps. But what does that really mean from a value stream perspective?

So we got results, and the way I think about this is agile got us predictability and quality, and lean got us efficiency. But what that left was speed. And when you're architecting for efficiency, it's not necessarily going to architect for speed.

So if we took a step back at our value stream, a few years ago, I actually showed this slide, I think, two years ago, what we realized is we had optimized the middle of our value stream. And it's not like intentionally we said 10 years ago, "Hey, I got a great idea. Let's optimize the middle of our value stream." No. But we were very good at going from a backlog to a set of iterations, or at least we were better at that part than the rest of our value stream.

But if you walked up to a team and you said, "Why can't you go faster?" it was where they're waiting for something, right? Either they're waiting for work. We estimate that we may spend 50% of our time before a card ever gets into the backlog of an agile team. And when we're going through a series of iterations, we're not deploying. There's a whole process, manual steps and things, that it was going to take to actually deploy.

So we said, "Okay, how are we actually going to increase speed?"

So it's really the DevOps compass, that in the DevOps journey that we're looking at to improve our speed. And the compass I think is very important, and Jared is sitting here in the front, had a role in coming up with, I think, the compass concept, is around the four DevOps metrics that you've heard Nicole Forsgren in the State of DevOps Report.

But you have to change your goals. You're no longer saying, "I'm going to implement pipelines based on efficiency and support." You're saying, "I want to optimize the developer experience and that horizontal value stream from customer concept to customer delivery. And if I'm going to get there, I have to architect it. I have to intentionally architect for results like lead time and frequency of deployment."

And my sense is, and you can raise your hand if you're doing this: have you ever heard someone say, "Yeah, we're going to architect intentionally around decreasing our lead time or increasing our frequency of deployment"? Anybody? Because if so, you can come up and help, I think.

And it also means organizationally, and I'll talk a little about this later, if you've gone through the journey as a unicorn, you've already kind of started thinking product and horizontally, and I'll show this on a slide. But if you're a horse, you probably started out in these vertical silos, and you're probably still dealing with silos. So how do you kind of support those horizontal systems thinking if we're actually going to accomplish this?

So with that, Mik's going to show you some very cool BMW shots.

Dr. Mik Kersten

Yeah. I'll explain this in a moment, but like Carmen, I've been very motivated around better understanding this topic, talking to our customers about it, understanding Nationwide's journey. BMW is one of our largest customers, and in the research of writing a book with Carmen's ideas in it, which you'll see...

Carmen DeArdo

But it'll still be good even though that's my name.

Dr. Mik Kersten

...on this topic, and I want to actually just get a little bit of a... And I've done a Gemba walk for Nationwide. It's been very eye-opening and amazing. I wanted to do one of the kind of old-school Gemba walks of walking along an assembly line. So I got invited to the BMW Leipzig plant, where the entire architecture of everything is around these value streams.

This plant produces a car every 70 seconds. And what's fascinating is actually you can walk through the architecture of the building. This is called the five-finger architecture, where these fingers basically extend as they add stages to the assembly line. So the buildings actually grow longer, let's say they need to add a Bluetooth module or a CarPlay module, or something of that sort.

So the kind of discipline in terms of value stream thinking and how it's baked in, for example, the electric cars that are over here, they're actually architected completely differently. They've got very different value streams because far fewer of them come off the line. An i8, the assembly line's probably a hundredth the length of the 10 kilometers I walked along the 1 Series and 2 Series line.

So there's this very basic deep thinking that's gone into the entire architecture of their building, their business, the offices is all around this value stream. And they've made it so incredibly explicit, where the CIO sits just to the left of what's visible on the desks here, and the assembly line actually flows through and over the IT staff. The bottleneck of the plant, which is just another fascinating topic, it actually happens over the lunchroom, the resorting that needs to be done around the bottleneck of the plant.

So all of this is incredibly explicit, and the business value is just present everywhere as you walk into this building. So business value at BMW is defined in this really cool way of cars that offer sheer driving pleasure, and you see that on the wall, and everyone sees these cars flowing, and everyone's really inspired by optimizing and helping with that flow.

So as I was walking through this plant, my whole goal there was trying to learn as much as I could on how we could apply this incredible discipline and maturity that one of the most advanced manufacturing plants on the planet has to their value streams, to how we build software. Because sometimes I leave from these trips from our manufacturing clients, and I feel like we're kids in a sandbox in terms of how mature we are compared to this.

But we're trying, and as I was trying to apply these concepts, I realized that there's things that we can take back from it. We've taken a lot of lean concepts, baked them into DevOps. But when you look at how design happens, when you look at how the work actually happens here, these cars are designed in yearly cycles. They don't actually change that much from car to car. So these value streams are all about producing the same car as repeatedly as possible, and the creative process and the manufacturing process are completely decoupled.

As you walk through this plant, the robots, there's now cooperative robots, which actually assist humans with lifting heavy things and fine-grain installations and so on. There's no creative process happening on the assembly line.

And when you look at how things flow, it's very different than to when we look at inside our organizations. So if we think about how business value flows in IT, because in the end, that's what we're here to do. We're here to help business value flow in IT. It feels like customers want new things, new designs, new ideas to actually happen much more quickly on two-week sprints or 10,000 times a day, as some high performers apparently are able to deliver new value.

And the interesting thing is that the creative process and the manufacturing process are actually coupled. So there's something just fundamentally different. And as I was trying to make things seem, in my mind, as similar as possible to how this works and how manufacturing works, I actually got this really weird thought that there's just something fundamentally wrong about the kind of batch, linear process metaphors that we're using. That work for the automation that you need in your delivery pipeline, but they don't work end-to-end if you're thinking like Carmen, and you're actually thinking about looking at the end-to-end process.

So now if you can imagine this image of your organization. So you saw the BMW plant from above, and you can kind of imagine an X-ray of that building and cars flowing and that business value being delivered and driven off the end of the assembly line. So now think about your organization and just try to imagine business value flow within your organization. Because you know the teams, the people, the buildings, and so on, and what's flowing. How is the value being created?

If you think of John Allspaw's talk, you have to look at sort of the representations of the value, but we know what they are because we know when we deliver business value, we delight users, or we produce revenue results, something that there's an effect of those things.

And just think about how it flows. If you try to visualize how it flows across your organization, because it is kind of flowing across the people and the teams.

So I did this experiment a few years ago of visualizing this at Tasktop, and we're able to get all the data from all the repositories in a value stream. We connect it to our own repositories, like Jiras and so on, to some open source repositories for open source projects that we work on.

And I'll show you this. It's just kind of a toy visualization, but I'll show it to you quickly.

What it's doing is it's taken all of the collaborative activity in the repositories, laying out people on a force-directed graph. So basically, the more that people comment or do code reviews together, so they comment on a Jira issue, Bugzilla issue, Targetprocess item, so on, our support desk and such, the closer they come together. And this is just one visualization. We've tried many different ones of these, of our own data sets, of what our value streams look like, basically, to try to understand them better.

And what you'll notice is it looks nothing like an assembly line. There's no linear process here. You can actually see teams forming. The people who talk, basically collaborate more, people who share more, they get closer together.

This actually was an amazing predictive model of the people who would be promoted. So the people like Nicole Bryan, she's our VP product. She's kind of hanging off on her own here because she's using a different tool. We were not actually incorporating data from that tool. Lucas Panda became our senior director of engineering. The bigger the people are, the more they're collaborating.

And what you notice is that people are actually connected through the artifacts they create. So somehow, the visual that we got from this is that it's those artifacts flowing across people and teams that are a fundamental part of our value stream.

Really, what does this mean, and what can we do with this? So here's another less messy visualization, and let's say you've actually taken the step a little further along the line, so you've now made these cross-functional feature teams.

If you look at how these teams interact, again, the artifacts they create, the ones they collaborate with, the places where they create information, they create value. You'll see, for example, that you might have an epic broken down to some features. Those features get broken down to stories. Stories get broken down to tasks. And each one of these things will have some collaboration, and there'll be some UX. And the UX hopefully is embedded on the feature team. Often it's not. Often it's elsewhere. You hopefully have an ops person and a security person on your team. Chances are there's also an ops team and so on.

So these lines of collaboration actually flow across these people and these tools. And when you zoom out a bit more from the feature team, you'll now see that, and you actually analyze the work that's happening. So you'll see that for us, we see for our customers, we see a lot of that communication is, "I need another bit of API. I need these three microservices to be composed somehow because you guys are confusing me."

So we actually see then these flows of information across those teams, and I think the most fundamental thing we've realized is these value streams are not linear. These value streams form this network, and the nodes in this network are the people and the communication, the collaboration that really is the underpinning of the conversation of software delivery, of bringing value to market. And that conversation then starts with a customer. This is why a lead time measure always needs to start with a customer request.

So what we realize is that this kind of batch-oriented linear metaphor just does not work. That this thing that we're looking at when we actually look into the live value stream within an organization, it's much more like an airline network, where the planes are these artifacts that are flowing, and the bottlenecks are nothing like the bottleneck in a car plant because the bottlenecks are much more like a tornado that might go somewhere else, where a team is missing three people, so they're slower, but another team will compensate, and things will get rerouted.

But there's resiliency in this network, and the way that you look at constraints in a network is completely different. You really care about backlogs and queues of constraints in the network, not that there's this one place where everything's broken because you've got lower quality widgets coming out, and you have to revisit those parts of things.

But instead of being airports and hubs, this network is backed actually by the tools that underpin your value stream, the processes that you've implemented that connect them, and of course, the teams that work within those tools and processes.

So I think one of the big problems and failings that we've seen is when you try to optimize and you try to basically make a transformation strategy around optimizing a linear flow and think everything is this continuous delivery pipeline, you actually make some of the wrong assumptions.

And I think one of the most problematic parts of that was it's basically trying to linearize the entire software development process, where it's this collaborative, network-based process. And I actually see what happened in the industry with waterfall and with RUP as just an overaggressive attempt at linearizing the software delivery process that just drove everyone.

It made sense to the organization. You had full traceability. Everything worked end to end. So top-down, it made sense because it plugged in this delivery process into the planning cycle. But in reality, everyone actually who was part of it rebelled. They didn't like it. "This is not how we work. It's not this linear. It's a collaborative process." And RUP kind of went against that, which is why the agile movement, DevOps movements disrupted them so much.

So one of the most important takeaways I think that I've learned that I encourage you to think through is that the end-to-end software is not this linear manufacturing process. In your company today, you've got this ad hoc value stream network. Most is probably disconnected. Until you start connecting it and looking at it as a network, you're going to be making some of the wrong conclusions.

So we absolutely need to automate each step through that network as much as possible. So all of the CI/CD efforts that you're doing, they need to be there, but what layers over top of that is this collaborative network of people, processes, and teams.

So we've actually analyzed 300 organizations' value streams at Tasktop, and we actually see how this works. So we know that 70% of you integrate more than three endpoints, 40% of you have more than four tools in your network because you're doing things at scale. A bunch of you will have three agile tools, which would make no sense except for legacy reasons and different lines of business choosing different tools and so on. Use different integration patterns, as you saw some of those hops.

So the key thing that we want to get across right now is that we need to start thinking of these networks not as an ad hoc architecture, but as a disciplined architecture. And we need, in this room, the kind of value stream architects to emerge who are looking at these things end to end, not just code commit to deploy, but actually end to end the way Carmen's doing.

So in terms of value stream architecture, we actually believe that the software architecture, so the code and APIs and microservices, should follow the value stream. You need to decide, do you need to optimize for faster feature delivery in this part? Or maybe it's a bit of mainframe code. You actually need to just optimize for security. You don't need to Dockerize the whole thing, right?

The APIs, if you optimize for value stream, you're going to create APIs that minimize dependencies between teams because you need autonomy of teams creating features, and some need to be a very high velocity for new business value delivery. Some can be lower. You can actually make those decisions rather than re-architecting your entire code base around some notion of what one enterprise architect's view of microservice is. You actually optimize things differently for different value streams. The same way BMW has a very different value stream for a 1 and 2 Series than they do for the i8 or the i3.

Your org structure, this typo there, needs to follow the value stream as well. And this is why feature teams, the Spotify model's so popular. It kind of naturally fits into that. They fit into kind of the sizing that you end up with microservices.

And then the key thing is someone needs to own this. You need a value stream architect who understands this. There's some deep technical questions over here. The kind of landscape of tools is complex. We need someone who can do the value stream integration, create a visibility strategy, because in the end, to find those bottlenecks, figure out whether 50% of your bottleneck is upstream and your CI/CD efforts won't actually yield much till you address that, or it's downstream because your security certifications are taking six weeks. And again, automating everything in the middle is not going to produce results if it's not at the bottleneck.

So we also believe that this person, this role, is core to your transformation, that your transformation will succeed or fail on the quality of your value stream architecture. So it just cannot be done ad hoc if you've kind of got one go at it.

We've come up with this framework, so I'm going to quickly run through this. It's a work in progress. You can email us. My name, it's mik@tasktop.com. We're taking input. It's kind of a core part of the book.

But the idea is that end to end, you only need to measure five things. And you only need to optimize value streams for the flow of five things: feature stories, defect stories, tech debt, and security stories. So again, this is from John Willis yesterday. These are the primary things. Security's not a secondary thing.

Some value streams you'll optimize for getting the security vulnerabilities fixed as quickly as possible. Some horizon three projects, some new projects, transformation zone projects, you actually want to maximize for feature story delivery. In some cases, you'll be sitting on an old platform. If you don't re-platform, you need to make a business decision to take down technical debt stories or value stream improvement stories themselves.

You've got some legacy tools, and the value stream improvement stories actually are investing in the factory itself. Similar to how BMW over time automated more and more of the i3 line, but did not need to do the i8 line because it would not have produced those revenue results, right? They were okay with much less automation on the i8s than the i3s.

So the idea that these form this new language that allows the business to decide, "Okay, we want to invest in more flow for feature stories, so we need to re-architect the software this way. Or we want to invest more in security, and so we don't need to re-architect those parts of the software."

So these become the underpinnings, and what you care about in terms of it not just being lead time of feature stories that you care about, you care about how quickly you fix defect stories and parts of it. Carmen?

Carmen DeArdo

Yeah. So I promised special guests, so we'll have to pick it up a little bit here. But again, here's some examples. I'm not going to really talk through these, but we'd like to get your perspective on these things, right? Some of these you may already be measuring, but you're probably not measuring things like end-to-end lead time.

So that gets us into an example that we did, and we said, "It's really not enough just to look at code commit to deploy." So on our own, we started to implement something for lead time. We have 200 agile lines, and for every story, they can actually see what their lead time is.

And the idea behind this is to give the scrum master and the teams and empower them with, how do you think you can go faster, right? We're not going to grade them and say, "Well, gee, that story sat, was done, but didn't get released for 50 days."

We have stories that sit six days and get released, and we have stories that get 100 days and get released. Well, I'm not going to pass a judgment on that. What we want is the scrum masters in their retrospectives to use that to talk to the team and say, "How can we go faster?" They need to own their journey, right? Because as Deming would say, the associates, the quality circle, they know best how to do their job, and leaders need to provide systems thinking to optimize the whole so that we can take advantage of that across the system.

Now, my dream is this will become so infused at Nationwide that on my TV someday, I'll actually see this. And you can almost... Brad, you broke the build again. So Peyton's giving it to him. Or maybe this. And I realize it's not Luke Skywalker, but then how many Super Bowls did Luke Skywalker win, really? And what's really important, the universe? No, I think it's Super Bowls.

So Mik talked about org models, and as we talked about, if you're a unicorn, you probably started in model three and you weren't even thinking about it, right? You had a small team, you had a product, you had everybody together. If you were a horse, you started in model one, and it was a bunch of silos. And then you said, "Hmm, okay, we need to start going faster." Faster means we got to accelerate horizontally.

But executives like matrices, right? And they think... Like we have seven CIOs. This is being taped. Yeah, that's good. And we have four of them in some way, shape, or form that have to support a horizontal plank.

And it's funny because vertical, they're almost like they're drawn by gravity. The blue is stronger than the yellow, and it's almost crushing the planks instead of supporting them. And so you really need to think about how you can support that from an architecture perspective, from a product owner.

So you had Topo talk about he's the product owner across the value stream for IT for IT. But you also need funding, prioritization, continuous improvement, because if you don't treat that as a product and you don't support it that way, you're really not going to be able to drive value, and you're not going to be able to really optimize for lead time and frequency of deployment.

So this was actually from work that was done at Forum in 2016. And there's a lot of good resources out there. So I think it's back to you, Mik.

Dr. Mik Kersten

Yeah. So I'll just quickly run through this.

We went on this journey five years ago. We were a project-oriented organization, and we had to shift to product, put in place product management, and again, we took this value stream-first perspective. So we, for example, made sure that we had, in this case, our value stream well-defined of all work happening with Jira, but we realized our bottleneck was actually upstream. We did not have enough UX designers for the kind of user experiences we want to generate. And we could actually see that. We could see the numbers for that. We could see that.

We actually did have to bring on board, we had to stop outsourcing it, those UX designers. We also make sure that our value stream is captured all the way from customer request. All our customer requests come through Salesforce. So we care about not lead time from code commit, not lead time from... It's really the cycle times from story started, but all the way from customer request to how quickly we deliver that value. And again, it's a completely different mindset if you're optimizing for that than just a narrow slice of the value stream.

And to me, it's critical, for example, because we can see if our new business value in our reports, the value streams across the organization, if our new business value drops for one of the value streams, which is a very critical thing for me, because we accumulated too much technical debt, and I didn't emphasize enough how much we should take down that technical debt. I over-prioritized for new business value because I'm worried about us going to market on something more quickly.

So again, these business decisions become much more principled as well, and the direction for the teams becomes much more principled if those flow units are clear. And we actually believe this is the way you avoid the Equifaxes of the world, is that the business understands where to invest.

So, I think our core here is that IT organizations cannot thrive without this connected value stream, and we've been too disconnected so far. You have to basically define and connect this network. You need to be able to see into this network so you can get the right kind of reports on what's flowing. And it's not this one size fits all, because different value streams, you will optimize differently and you'll prioritize which ones you transform, where you want more business value, where you need to focus on quality, where you need to focus on tech debt reduction, and trying to do everything and emulate a much smaller company just doesn't work when you've got hundreds or thousands of applications and product lines.

And the key thing is to assign ownership of this to someone in your organization. And we see that role as the prototype of that role, in my mind, always Carmen as the value stream architect.

So thank you.