From Projects to Products

Imagine a world where the same approaches that successful startups follow also worked for Fortune 500 companies. With the right organizational structures, it can be a dream come true.

However, IT organizations tend to think that innovation is one install away and the path is littered with failed agile transformations. Changing from a project- to a product-centric approach may address some the major obstacles preventing the nimble startup-like success larger enterprises crave.

Join us as we speak with Dr. Mik Kersten, CEO of Tasktop and author of “Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework”, as he talks with us about a critical disconnect between business leaders and technologists and how enabling a shift from project to product can make all the difference.

Accenture | SolutionsIQ’s Skip Angel Hosts

Find Skip’s infograph on Twitter.

The Agile Amped podcast is the shared voice of the Agile community, driven by compelling stories, passionate people, and innovative ideas. Together, we are advancing the impact of business agility.

 

Read the full transcript

SKIP ANGEL: Welcome to another edition of Agile Amped. I am your host, Skip Angel, and today, my guest is Dr. Mik Kersten.

Mik is the Founder and CEO of Tasktop, and he’s written over one million lines of open source code that is still in use today, and has brought seven successful open source and commercial products to market. Mik’s experiences working with some of the largest digital transformations in the world has led him to recognize that there’s a critical disconnect between business leaders and technologists. Now he’s working to create new tools and a new framework for connecting software of value stream networks and enabling the shift from project to product.

Again, thank you for joining us. Now, onto the conversation.

Mik, thank you so much for taking time with me to record today for this session.

MIK KERSTEN: It’s great to be here, Skip. Thanks for having me.

SKIP ANGEL: Let’s get into your book. You just published a book a little while ago, and why don’t you tell us a little bit about what that book’s about and how it came into being?

MIK KERSTEN: The whole journey around this book called Project to Product started with, I think, as you said in the intro, is this experience I had working in an extremely productive environment in open source, and seeing just how much output, how much great stuff you can deliver when you’re in the flow of your work, and when the team’s in the flow of the work, and when the organization’s aligned to its customers, and everything’s connected.

Really, my journey in terms of moving out of what I was doing in research and building open source programming language tools and frameworks onto applying that in a commercial setting, trying to make it work for large enterprises, trying to make some of those things that I realized, along with my PhD supervisor, can really transform how software’s built, is that the setting in enterprise IT was completely different, and that there were some things that were just completely impeding this kind of innovation that I really was seeing in open source, and in startups, and increasingly in the tech giants who’d figured some of these things out.

So having spent a decade working with Fortune 500, and actually, Global 500 enterprise IT organizations, I realized that there’s just this fundamental mismatch. It’s that all of those things that the technologists were trying to do within those large organizations were the same kinds of things that actually worked in startups, and open source offerings, and in the tech giants, but that the managerial structure that we had in enterprise IT organizations was somehow preventing that. So I started asking myself why is that? What’s so different about large scale enterprise IT? What’s stopping us from getting those benefits of Agile at scale, of getting those benefits of what DevOps provides? Why is it so much harder?

Is it what I always thought it was, that things just get more difficult as they get larger scale? And I realized that wasn’t really the answer. It’s not like a company like Microsoft has any less scale than a typical enterprise IT shop. They have just as much legacy in their IT systems as well, having been around for the better part of 50 years.

So, I realized there’s another fundamental mismatch. There was something more to this, and that these companies that were not able to set themselves up in this new way of working were actually starting to fail. Where now, due to where we are in the climate, I speak about this a bunch in Project to Product, where we are in this fifth technological revolution, the age of software, it’s no longer a luxury; it’s no longer only the most innovative companies that need to figure out these problems of how to build software at scale, how to become a software innovator. Almost every large organization needs to do that right now, yet they’re approaching it the wrong way.

So the book was really written to help all of those organizations get on a different path, get off that path of having your Agile transformation fail yet again, even though you threw some DevOps automation in there, and onto the path of actually becoming a software innovator, but really understanding why, previously, organizations had approached it in the wrong way, and then giving you this simpler, better path forward.

SKIP ANGEL: It’s interesting. One of the things I have ran into, leading and coaching transformations, is that it’s almost as if I wish I could cut across the organization and look at it like I would a tree because I would see these rings of Agile attempts along the way. Many of them are trying on their fifth time, their fifth wave to try to make this work. They want innovation, they know they’re complex, they would love to be as nimble as a startup, but like you said, there’s this obstacle getting in their way.

The title of your book, I thought was interesting, and it was a way that we connected in that we were starting to see this need to shift from project to product. I’d love to hear from you, why is this shift needed, and what does it look like for organizations? Why do we need to care about going to products and what does that shift look like for people?

MIK KERSTEN: Yes. I’ll summarize that in just a moment, but Skip, I think that visual of those rings in the organization of the failed attempts to transform and to become more Agile, I think that’s the first time I’ve heard that and I think that’s a visual. Yeah, I think it’s exactly the right kind of thinking is what stopped that ring from growing bigger? What were the fundamental things that prevented that?

I think you and I had a very similar journey of understanding here, of learning here because it was, for me, that brilliant infographic that you put out. I didn’t come across that until I had just, I think it was the same week, I submitted the very final copy of Project to Product, and I wish I’d actually seen it before because there’s some really interesting ideas in there, some interesting extensions I didn’t quite cover in Project to Product, but really, the exact same line of thinking in terms of what it means to have a project-oriented approach for the business versus a product-oriented one.

Because I think like you, the thing I noticed is that these enterprise IT organizations, the way that they manage and plan software deliveries or the way they look at it, at a business level, the KPIs they look at of, say, being on-time and on-budget, those are not there in any software innovators. Software innovators look at software delivery and IT in a very different way.

I actually kept digging on this topic, and I said, “Okay, well, is this normal? Is the fact that organizations who become good at different kinds of manufacturing,” and the book, Project to Product, goes into a lot of detail how BMW did this, how you innovate in manufacturing at scale, and I realized that the real application of Lean principles, whether they’re to Lean manufacturing or they’re to software delivery, they’re actually similar in terms of the principles. Of course, the manufacturing processes, the design processes are different, but they share this common thing. It’s that if you’re innovating, you’re doing this in a product-centric way, not in the project-centric way.

When you do things in the product-centric way, you’re looking at this process of production very, very differently. You’re thinking longer term. You’re not thinking about moving people and resources using a Gantt chart and resource management tools between things; you’re actually starting to think about, well, how do I help this team grow and master this particular part of my technology stack and get better and better over time, rather than moving people around from team to team, and pretending that they’re fungible assets, that I can treat as cogs? Which you can do, if you’re building a large building or bridge because that’s exactly how very simple endeavors work is that it’s repetitive work that you can reassign continually.

What I realized is that there was this fundamental, that the lens with which the business looked at, software delivery was wrong, that we, in Agile communities, were always, I think, saying more or less the right things in terms of how you apply Agile, how you be Lean, how you be adaptive with DevOps, how you get the flow and feedback and continue learning through that journey, but this was actually never making it to the business side in enterprise IT organizations.

There’s this fundamental limiter of that last ring of the Agile transformations always hitting that same brick wall, which is that the limitations, in the end, of having a project management outlook on IT.

SKIP ANGEL: Yeah, and it’s interesting. I started doing a lot of pilots for Agile in product companies. I found the translation to their world was actually one that was pretty easy to do. They understood the need to define things as products and that need to continuously make those products better. It felt like a natural fit.

In fact, I don’t know if a lot of our viewers realize this, but Scrum, the background of Scrum is around an article that was published years ago called The New New Product Development Game. In that article, it was really around a different way to think about developing products in a way that could be collaborative, in a way that can be focused, and was the inspiration for what we think about for Scrum. It wasn’t a, as many people have labeled it, a new project methodology.

It became kind of weird as I started working, especially in large, complex IT organizations, that it was feeling more like they were putting labels in front of things without changing those things. Labels, you know, we’re going to call it an Agile project versus a regular project; we’re going to call project managers, Agile project managers. It didn’t feel like it was the right fit. It was kind of the square peg in the round hole, and it just didn’t go as well for me. So I knew that I was onto something, that this shift needed to happen because we really are talking about two different things.

MIK KERSTEN: Yes, absolutely. I think it’s like you say, the origins of some of these things that we’ve all been trying to implement at organizations in terms of their Agile journey, they actually are around product innovation. I think one of the books that inspired me and a lot of other people, Donald Reinertsen’s Product Development Flow, it has the key insights, right? Those are the kinds of key insights that then Scaled Agile framework, and a bunch of other Agile frameworks based some of their concepts on, and the concepts of queuing theory and so on. Those are all, in the end, product development principles.

I think it’s now just become a question of given the fact that those principles are so misaligned, the product development and the Lean principles, which are all about customer pull and value streams, those principles are so misaligned to how project management works in the sense that you’ve got, again, these finite time frames and budgets. You bake in all of the risk for a particular product development initiative upfront as if you understood how the future would pan out. There’s simply not that much information upfront in a software development initiative versus something that project management’s great for, which is constructing a building. You actually know all your parameters and variables ahead of time, you overbuild sufficiently to deal with anything else.

But this is where I think the Cynefin framework is so relevant where, if you want to understand what’s project management good at? It’s where we’ve got less complex initiatives, where the things are simpler, they can be more cookie-cuttered, work can be divided hierarchically in a very easy way. If we look at what’s going on with software, and especially innovation around software, well, it’s highly complex, and in some cases, might feel even slightly chaotic because you’re learning so much as you go.

With that principle, we now know, okay, project management won’t work for that. In the end, this is a learning process, it’s a discovery process, so we need to take a different approach.

I realized that it’s not that project management won’t go away. Right? Organizations have a PMO. Consulting organizations always will have some sort of project structure on their engagements and so on, but it cannot be the primary vehicle with which the business looks at software delivery, otherwise the business is going to continue making very bad mistakes in terms of how it’s leading the transformation, how it’s leading this journey to become a software innovator.

Just as an example, the concept of, say, technical debt is very well-understood by you and I, Skip, by people practicing Agile because we just know it’s a key facet of software deliveries. You take shortcuts, technical debt builds up you need to pay down at some point or it ends up biting you and slowing you down in a big way in the long-run.

That’s not a key concept in project management, right? Project management, in the end, you’re trying to deliver a set of things, call them features, call them functionality in digital experiences to people. There’s no accounting for technical debt and there’s no understanding of that. You know if you’re off-track or you’re on-track, but this actual primary force in software delivery does not surface at all. Whereas, again, this is why in manufacturing things like quality and rework and so on are primary. You always need to know if you do have some debt in the manufacturing process.

I think you and others have become very good at communicating some of the key problems that, if you have this project-oriented mindset, well, you’re not actually going to become Agile at a business level. Your teams can get as Agile as you want, but if you think through the theory of constraints, just because you’ve got Agile teams and you might hire double the developers on those teams, that doesn’t mean they’ll go any faster if you’re actually not Agile end-to-end.

The thing that I was really trying to come up for all these years that came together after we did the research, some of the background research for the book, by analyzing 308 enterprise IT organizations’ value streams is this new way of looking at things. This is really what the flow framework is about is to take the minimal set of concepts that we do need to understand, and that the business needs to understand from the scaling frameworks, such as technical debt, such as these notions around quality and flow, and to make sure that both the business side and the technology side agree on those as the way that we’re going to look at our velocity, our delivery of software assets.

I can’t quite say it’s the simplest framework in the world, but it’s really meant to be as simple as possible while capturing those key concepts, and the reality of implementing those concepts, whichever scaling framework you might be applying, whichever development methodology you’re doing, or whether you’re in pure IT or you’re a mix of IT and hardware systems or any of those kinds of things, that the core concepts and idiosyncrasies of software delivery are visible at the management level of the flow framework so management can make the right decisions and trade-offs. For example, deciding to focus on technical debt reduction for a period of time to get more feature velocity in a future period of time.

SKIP ANGEL: All right, let’s get into the flow framework because I think that’s a big part of your book. For the skeptics out there, they’re probably going, “Do we really need another framework?” We’ve got, you know, especially with Scaling Agile, there seems to be just a ton out there. How does your flow framework differ from, say, the SAFe and LeSS and DAD and other things that are out there around scaling? What makes yours different and what are the major components of your flow framework?

MIK KERSTEN: Yeah. I think the key thing is that the flow framework assumes that you’ve picked some kind of scaling framework, whether it’s Scaled Agile, LeSS, DAD, Nexus, or you’ve grown your own. You are more like the tech giants, let’s say, who’ve just come up with their own software delivery model. You’ve figured out some way of doing Agile at the team level, really up to the portfolio level, and the flow framework simply sits on top of that.

So in the flow framework is this minimal set of principles that dovetail and that just simply, again, sit atop your scaling framework, that the business side needs to understand. I had this experience with my own CFO where I first told him about how we prioritize and measure things with Story Points, and when you start bringing up Story Points to someone who’s … By the way, my CFO’s background is actually in lean manufacturing, interestingly. Once you start talking Story Points, you get some pretty strange looks from a finance person because it sounds more like the language of fairytales than finance.

I realized that while those concepts, such as Story Points, such as enablers, such as weightage shortage, job first, and so on, while they’re super important to our teams, they’re actually not the language of the business. The idea is that the flow framework sits and just captures the flow of what we’re delivering through those scaling frameworks, but with concepts that the business side either A) already understands, or B) needs to learn if they want to help direct their software organizations to success. It’s simply saying this is the minimal stuff you need to understand.

In terms of what that is, just to make it concrete, it’s the concepts of these product value streams, the flow that we measure through those product value streams, and how that correlates to business results.

The first thing is the question of what flows? Because we’ve got these very rich taxonomies. One of the main contributions of SAFe is just how rich a taxonomy it is, but it’s too rich in the sense of having your CFO understand that tomorrow, or someone who’s growing up from the MBA side or going to the company from the finance or operations side, rather than the technology side.

All of those dozens of work items actually correspond to only four flow items in the flow framework, and those four flow items are really what everyone in a software organization needs to understand and agree on as what’s being pulled through your software value streams. Those are features, defects, risks, and debts. That’s technical debts and infrastructure debts. These four are mutually exclusive and comprehensively exhaustive, so MECE for short, which means that they describe all work being done in your software organization, in your IT organization.

For those four things, we measure flow metrics. There are four flow metrics and we correlate those flow metrics to business results. With that, you actually can have a real-time view of what work is happening in your software value streams, where the impediments are, whether a low-flow efficiency comes from the fact that you’ve not done your DevOps automation or you don’t have enough developers, or you have an upstream dependency such as developers waiting on business analysis or wire frames. It actually gives you a view of end-to-end software production.

That’s the other really key difference here of the flow framework. The first one I mentioned was it’s a higher level in the organization. It’s much less granular, it’s much simpler, and there’s just a lot less to it than a scaling framework, but it’s meant to be this common language between the business and the technology. The second thing is it’s all end-to-end, so it needs to sit over not just scaling frameworks, but over ITIL and those kinds of service management frameworks, over product management methodologies as well, even over project management if some of the work intake is happening that way.

Every metric in the flow framework is end-to-end. There’s no notion of what sometimes gets called lead time, as in commit to code production. In the flow framework, that’s not lead time; that’s just a subset of it’s really cycle time of an end-to-end value stream. Everything’s measured end-to-end from the customer’s perspective, whether it’s an internal or external customer.

Just an example, flow time starts whenever work was taken into the value stream. It’s whenever you started working on that support ticket that then turned into three different issues, or features, or something of that sort. The flow time clock in the flow framework doesn’t stop until the customer has the software, until it’s running. So the second big difference is everything is end-to-end, and by virtue of that, it actually might span multiple frameworks, such as SAFe and ITIL.

SKIP ANGEL: Let’s get into the value stream aspect of it. You’ve talked about how to measure those value streams. It’s interesting, over the last especially couple of years, as we’re scaling Agile, there’s been this recognition and everybody talks about value streams, yet you look at the organizational charts, and you look how we’re organized around projects or programs, and how we tend to reorg organizations at least once a year, if not more often. It feels like everyone’s talking about it, but very few have found it and really understand what does the value stream really look like and how to make that work effectively.

Is that something that you’ve seen as well? How have you addressed that in your flow framework? I know you have something like a value stream network. Tell me what you think about that.

MIK KERSTEN: Yeah, absolutely. I think this concept is absolutely key is that value streams are the way that you want to organize. This doesn’t mean that you’re going to reorg tomorrow and align everything to these value streams, but in the end, all that matters in terms of a successful transformation is how much more business value you’re able to deliver to your customers, to your stakeholders at the end of the day.

In the end, that’s all what we want. That’s what becoming a software innovator’s about is delivering more and learning from that because in the end, you need a feedback loop. You’re delivering and you’re sampling and learning more frequently. Those really are the three ways of DevOps as well, of flow feedback and continual learning.

In terms of what a value stream is in the flow framework or in this common definition, they appear in the Scaled Agile framework as well, of course, the way that you deliver value end-to-end through your organization, so the way that you take in work that you’re going to do, which is why it’s obviously critical to capture all work somewhere, the way that work flows to analysis, and development, and design, and then turns into working software.

What Project to Product says is that you organizationally need to align your value streams because you have them no matter what. You’re delivering value. You’re building software. In an organization, you have these, but you need to align them to products so that you can measure what’s happening in your different product value streams. The products can be external-facing, so they can be some mobile experience you’re creating; they can be internal-facing, they can be as simple as a set of STKs or APIs that are being leveraged internally by teams. But you look at your software organization as a set of product value streams the way a car manufacturer would look at their product as a set of manufacturing lines for cars.

This is why, in the end, Project to Product is all about value stream networks. As soon as you start taking a look at your software organization that way, you realize this is actually a network. It’s not a linear manufacturing line. It’s not like your continuous delivery pipeline stretches end-to-end as a batch process and that’s how you build software. You’ve actually got a network of these teams, and the teams have dependencies between each other. Once you start to look at that network, and this needs to be more, by the way, than just a value stream mapping exercise, those whiteboard exercises, you actually start looking at your value stream network of every team, every dependencies and start measuring flow in the value streams that you care about at a business level, which in the end is that digital product that you’re creating for internal or for external consumption.

You can actually start measuring things and start getting some real insights, rather than making these … organizations tend to fall into these very broad-based decisions such as do we go and dockerize everything tomorrow and everything moves to Kubernetes? Do we need to double developers across the organization? Do we need to get to 100% test automation? All of these are the wrong questions because in the end, what you need to look at is for this product value stream, what do we need?

Well, if we need a really faster feature flow because there’s a lot of innovation that needs to happen here because it’s our new digital experience, well, then yes, you probably want to go with a cloud native stack because those cloud native stacks give you the fastest feature flow and feedback traditionally. But for a value stream that’s some mainframe code or some backend services that you can just wrap in some APIs, well, you might not need that. For that particular product value stream, you might be okay with a more traditional stack, even in some cases, organizations shouldn’t start their Agile transformation there and they leave those as waterfall for a year or longer.

That’s okay because once you start looking at your organization and its set of product value streams, once you start seeing the flows, so using these flow metrics to see, okay, we’ve got too much risk within this value stream, we need to figure out some common components for our new approach to authentication and data privacy, and we’ll actually make that a new internal value stream, you start thinking like a software innovator. You start seeing your value stream architecture and you start being able to make decisions on how to increase flow where it matters most, and how to extract these common platform components, how to invest in your platform itself as a product that all your other value streams will depend on.

You actually start getting the right look at your software delivery organization, and it’s a completely opposite and different look than a bunch of projects being on-time and on-budget. You’re actually looking at the software organization in a way that makes sense for software and for the creativity that’s involved, rather than, again, assuming this level of predictability that’s not there in project management for software.

SKIP ANGEL: How does that change how you might look at the overall portfolio? Because a lot of the portfolios, I think, as well are based on a bunch of projects that we need to prioritize and try to get done. Does it look differently now that you’re getting into value streams? Does that change even-

MIK KERSTEN: It does look differently. And it’s not that, again-

SKIP ANGEL: Okay.

MIK KERSTEN: -that you can’t, in a large organization with hundreds of thousands of projects, hundreds of thousands of applications in the end, you can’t make this change overnight, but you immediately, what you should start doing if you’re working in an IT organization, is actually start mapping out, maybe only a couple or a few at a time, your product value streams and say, “Okay, this product involves these sets of teams, and this is how we actually deliver the value through this product.”

The product value streams, by the way, one thing that makes it easier is that they’re at a higher level, keep in mind, than the Agile teams. So you know, they’ll map into release streams and so on, but you’ll typically have between a couple and ten teams working on a single product value stream. You’re getting to that scale of Scrum of Scrums. You’re getting up to 100 people, typically, working on a single product value stream and delivering something really meaningful to the business.

Again, you’ve got this higher level, and once you’re looking at things on this higher level, you can actually start measuring the value stream. As an example, and this is key to the flow framework and the business results part, you start looking at cost and value delivered for that product value stream. You start measuring employee … The happiness metric is a core part of the flow framework because you start measuring happiness – at Tasktop, we do it with employee NPS scores – for that product value stream.

Then you get the right kind of insight. You see, wow, why is this one product value stream actually happy and delivering more features, and why is this other one miserable? Maybe that miserable one hasn’t had a chance … By miserable, I mean they have lower scores. They haven’t had a chance to resolve their tech debt and they’re keep being asked to do more without the ability to fix the underlying problems in their software architecture. You start being able to ask the right questions and direct funding and initiatives in the right direction, rather than, again, having this knee-jerk we have as, “Well, we just need twice as many developers and we’ll get more done.”

As I think, Skip, you and I have seen, love to hear some of your experiences on this, that often is not the answer because it’s not where the constraint is.

SKIP ANGEL: Well, yeah, I think there’s two problems. I think organizations overall have a what we call WIP problem, work in process. There’s too much trying to go on at once. We’re trying to start everything and we have a hard time finishing things. I think that’s a global problem I’ve seen everywhere is just we’ve got too many plates in there, too many things were going on at once. I think what I like about your framework is I think it starts to provide a better focus.

The other thing is this obsession with cost, and how much things are going to cost me, and how much money do I need to handle those costs, and how do we optimize those costs? What I hear you saying in this transition is there’s a lot more, based on looking at these metrics and based on where the organization is going, it seems like it’s more of where do you put your money down? Where are you investing in the organization or taking your money off the table?

I’m imagining a big roulette board where you’re putting your bets down on certain things and doubling down on certain things. It feels much more like that than I think we’ve seen in a lot of the traditional, “I’ve got to focus on trying to get my project approved, whether it’s a good idea or not.”

MIK KERSTEN: Yeah, exactly. I’ll address both those things that you mentioned, Skip, both that WIP problem, the work in progress problem, and this cost focus.

If you only take this project management mindset of just, “We need to get more done, we need to get more features out by the launch date, and we need to do it at this cost and keep the costs lower,” you’ve got such a partial view of the picture, it’s a very dangerously partial view of the picture, that you completely miss these things. You could have gotten the wrong thing out, as you’re alluding to. You could have built up such unsustainable technical debt that this thing that you built will never scale. I’ve seen that over and over. There’s some great new digital initiative from a new team, maybe the CMO hires them on or just somehow it’s gotten in this bimodal land where they’re off to the side, and that thing that they built, and they did it within the right cost profile, the right project timeframe, never has a chance of making a dent on the business because it was approached exactly the wrong way with, again, only a partial view of what it takes to bring a software product to market.

First on the cost thing, we can’t get away from cost. Cost is a key part of the language for the business and finance side. Cost is one of the four business results in the flow framework, but always as it corresponds to value. You have to create a value metric for every product, and that’s what will get you out of this tyranny of managing everything to cost because we’ve seen these large Agile transformations that hit on their cost KPIs, and actually, after spending a ton of money, cause a lot less value to be delivered to the point of unsustainability for the company because the wrong things were outsourced, the platform investments were not made, and so on. The primary focus on value streams is actually on delivering more value, and then you decide is it more value with the same costs, with less costs? You can take on more costs because you’re investing.

But really, the focus is on value, and when you’ve got cost and value, we are seeing Donald Reinertsen’s focus on lifecycle profitability as the main metric. That’s a bit more advanced than the flow framework, but in the end, we just always need to have both measured for every product value stream.

And then again, correlating to that, once we’ve got this value focus in terms of what we’re trying to deliver in each one … This also means, by the way, I should add that you’re creating value metrics even for internal things. If you’re making an API, a new capability in your platform, well, the value metric can be the adoption, the internal adoption on it, how quickly you can end-of-life some legacy system that you had as well.

Now, with that, again, we’ve got that value focus, it’s of course still very easy on the business side to just ask for things that are too big, too much, and so on. This is a normal thing. There tends to be more demand from customers from the market for software than there is capacity within the organization. That triggers that work in progress problem, that WIP problem that Dominica DeGrandis speaks so eloquently to in her book, Making Work Visible.

One of the four flow metrics is actually flow load, which is just a WIP metric. Within our own value streams at Tasktop, I can actually see that. When we put too much WIP, too much flow load, on a particular product value stream, their feature velocity tends to go down because there’s just more thrashing, your flow efficiency gets worse, and so on. It actually gives this dynamic check and balance to the business of knowing well, for this particular product value stream, how much is too much? In the end, it gives the leadership on that particular value stream where you’re saying, “Look, you make us take those four things on while we have to do our data privacy changes, we’re actually going to get less done over the course of the next six months, even though for three months it might look like we’re getting more done.”

Really, I want to emphasize this: the flow framework is meant to be a way that the business side and the technology side can communicate because a lot of these things, the technologists already know. If they take on way too much work, way too much WIP, they’ll get less done. But the flow framework allows them to show that visually to business leaders who of course are just asking for more features sooner and to market faster. I think that’s why it’s so key that we elevate, this is again, one of the other goals, just like it’s to elevate technical debt, to elevate value, to elevate WIP with this flow load metric so that the entire organization understands that concept, not just the technology side.

SKIP ANGEL: You already started talking down the path I want to go next, and that is this isn’t just an academic exercise for you to come up with a theoretical model. You’ve got a product company, Tasktop. You’ve talked about flow load, but tell us the other areas that you see your company benefit from using a lot of the concepts in the book, and what was that evolution like for your own company?

MIK KERSTEN: Yeah, absolutely. We’ve been on this journey where we’ve had the opportunity to adopt … We adopted SAFe- Scaled Agile Framework many, many years ago, and adjusted it some to fit our needs, but as we got bigger, and my role expanded as the number of our teams grew, I realized I needed a higher level lens. I no longer was going to look at individual user stories, how many of them we completed or particular defects, but I still really cared deeply about knowing where we needed to put additional investment, where a team might actually need to focus on some tech that worked and be able to set the expectations of the rest of the organization accordingly.

I realized that it wasn’t enough, and of course, coming from being a software developer, these are things that were fairly easy and innate to me, but I realized it was actually important for the sales side to understand that, for the marketing side, for the entire business to understand these things and these trade-offs that you end up making, because these four flow items are, in the end, a zero-sum game. We knew we had to do a whole bunch of GDPR work, some regulatory work, a couple of quarters ago, actually before that as well, and that would affect our feature delivery because you do more of one, you do less of the other.

As another concrete example, I thought I knew, with my background, enough of how to help the organization handle technical debt because it’s something I’m very familiar with and have worked with a lot. The flow framework allowed me to realize that, be a little bit overly surprised, but that the effects of technical debt in one of our product value streams were a lot worse than I had ever assumed. I had optimistically thought, “Okay, we can get out of this in two quarters,” and that simply wasn’t the case on one of our product value streams.

Another case, we had to just replatform. It allowed me to realize way earlier, and this is the key thing because you learn these things in the end anyway, but the flow framework allowed me to realize way earlier that we had to replatform, that we could never get the kind of feature flow we wanted out of this one part of our software architecture, and we actually had to make a completely new stack to deal with that and decide, well, either we do have the runway to do this or we don’t. But the great thing about it is, it allowed me to realize it before we ran out of runway, before we were too far along on having the old platform deployed.

It basically makes visible the information that you need to make these decisions, and then the trade-offs you end up discussing with your IT team leaders and teams. I think the most interesting thing about it actually is one thing is just being able to make decisions. It’s fairly simple like, “Okay, I understand. We need to take down more technical debt,” but the really neat thing about the flow framework is you’re not making those decisions based on some industry best practice. Some people think every release, you need to take down 20% of your technical debt. I actually think that’s generally a good practice, it’s the practice that we used to use, but it’s never one-size-fits-all. I can actually see that on some of our product value streams, that’s not enough; on others, that’s too much. They don’t need to take down that much technical debt. They’ve not incurred as much. They’re using new languages and frameworks that actually make some of that a bit easier than some of our enterprise Java value streams.

The really big deal, to me, that you start noticing almost immediately is that you can make decisions based on reality rather than cookie-cutter best practices. And then the other really, really important thing is being able to make decisions and understand things across your product value streams, to look at these things as a portfolio.

A really neat one to me is a new team that started using one of our newest product value streams, they actually went with a different stack because they thought it’d be more productive for what they were doing. They went with, I think, Scala, TypeScript, React, and a few other new technologies on that front. Of course, the idea is that this was going to be more productive, but you never really know at a business level. Well, is it more productive? But they’ve actually been able to demonstrate much higher flow velocity as a result of that.

Now, from an architecture point of view, we can connect those dots. We can start looking at, okay, well maybe should we start moving to the stack from some of our other offerings for the next value streams that we build? We actually have the empirical data within our organization, not from someone else’s PowerPoint who had good luck with TypeScript or Scala before, and can make those decisions based on what’s right for our organization because, in the end, all this data’s there. It’s all in the tool chain. It’s a matter of connecting and viewing it with the right lens. Really, that’s what the flow framework is. It’s that lens.

SKIP ANGEL: Awesome. Tell us all how to find your book and where can they learn more, even beyond the book?

MIK KERSTEN: Yeah. Go to ProjectToProduct.org, that’s T-O Product.org, or just Google Project to Product, and you’ll get there. There’s an overview video that talks about some of the concepts, but it really just touches on it at a pretty high level. The book, you’ll be able to get on Amazon, Apple Books, basically anywhere that you can buy books. There’s an audiobook, ebook, and paper of course. It’s just been great to see the, actually quite surprising to see the response of the book and how it’s been ranking since launch. Please, basically if you’re interested in applying this, don’t hesitate to get in touch.

You can find me on Twitter. You can also email MKersten@Tasktop.com if you want additional followup materials or anything else that we can provide you in terms of helping you adopt these concepts, and these practices, and be connecting your tool chain.

SKIP ANGEL: Fantastic. For people that are interested in that infographic that I produced that Mik had talked about, you can reach me on Twitter @SkipAngel, and you’ll see a pinned tweet to that diagram if you are interested in taking a look at that. So Mik-

MIK KERSTEN: Yeah, I highly recommend that. Oh, go ahead, sorry Skip.

SKIP ANGEL: No, go ahead. Yes, go ahead.

MIK KERSTEN: I just highly recommend everyone take a look at the diagram because in the end, a book is a recipe to help you implement ending up on the right side of that diagram.

SKIP ANGEL: Thank you for that. Well Mik, I really appreciate your time with me today, the conversations that we had. I know I learned a lot and I’m sure other people did as well that are listening in on this podcast, so thank you for your time.

MIK KERSTEN: Excellent. Thanks so much, Skip, for the great questions, and thanks everyone for listening.

SKIP ANGEL: All right. Thanks again for listening to this edition of Agile Amped. If you learned something new, please tell a friend, coworker, or client about this podcast. Please subscribe to hear more inspiring conversations that we have, both in the past and the future. We look forward to learning more and sharing what we know with you. Thank you for your time and this has been Agile Amped.