Conferences are often a great source of inspiration. But sometimes, our takeaways from these conferences aren’t easily incorporated back into the organization, as internal systems might be prohibiting these changes. In an Agile Amped podcast, Mirco Hering, Accenture’s Global DevOps Practice Lead, speaks with Mik Kersten, CEO of Tasktop and author of the book Project to Product about the reasons companies often struggle to achieve their desired transformation. After reading the excerpt below, listen to the whole episode to learn more.

Mirco Hering: Welcome to another edition of Agile Amped. I'm your host Mirco Hering and we are podcasting from the DevOps Enterprise Summit in Las Vegas. Today my guest is Mik Kersten. Mik, thank you so much for being on the podcast today.

Mik Kersten: It's great to be here. I'm Mik Kersten, I'm the founder and CEO of Tasktop and the author of Project to Product. I've had the opportunity to be part of this community for quite a while. I've been learning from people, trying to understand the problems over the years as the conference, and as the DevOps movement, has evolved. I found a few things that I thought were wrong with how people were approaching this need and this desire to change and to improve. And so, I tried to put some of those thoughts in this book, Project to Product.

Mirco Hering: You clearly hit the nerve there with your book and the useful framework that you are providing. Since the book has been published, what has the feedback been?

Mik Kersten: I was not expecting this kind of popularity for the book. And I realized when we meet at these conferences, we have these conversations, we see people on stage, and I think generally people here understand what needs to change and how it needs to change. Here, you actually recognize the need for continuous flow, feedback and learning. But I think the problem is when you leave these conferences, you go back into your organizations, and that motivation, sadly, get squashed by that immune system within the organization not to change.

I was spending so much time on the road with customers, that over the course of a year, I actually had 220 meetings. This was three years ago. I decided to understand what's going on, why is it that we have all these great conversations, we generally know what to do, but then these organizations just don't seem to be doing it the right way? The technologists get it, but the business is not changing in the way that we think. It's frustrating for everybody. And worse yet, it's not producing results. If you look at the top of the business where the board, the CEO and the executives are, there's actually this massive desire for change. There’s just something wrong with the way that change is being approached.

And I realized that, first of all, the language that's being used by the business is so much different than the language of technology. And so, people are trying to tell the business to change with the language of mean time to resolution, deploys per day, and chain success rate and story points. But that's not resonating with the business because that's not the language of the customer. It's not the language of the business. So there's a big problem there.

The second thing is the way that change and improvement's being measured is either nonexistent or completely broken with a set of proxy metrics. Again, how many user story points you delivered is probably not that meaningful to your CFO. But there are aspects of that that are very impactful. Certain concepts are so important to technologists because they realize that they can make or break a product, a platform, and a company. One example is as technical debt, which can go completely ignored by the business.

I realized that what I needed to do is to try to come up with a minimal common language that would help bring all these great ideas from the DevOps community, extend them and force the business to basically understand and acknowledge these things.

And that's really the goal of Project to Product. No matter what industry segment you're in, whether you're in a primary or secondary, tertiary part of the economy, you're going to get affected by this, whether you're doing energy or resource extraction or healthcare or education, software will determine how effectively you can deliver your product or service.

Mirco Hering: Yeah. And that leads, then, to the old pattern where we had these horizontal applications that support absolutely everything, where you didn't really get to the point that you had a product identified.

Mik Kersten: That's right. One thing that Project to Product says is you need to define product value streams. Because these product value streams, by definition, should be meaningful for the business. They should be things that customers are pulling and are delivering customer value, even if it's for an internal customer, even if it's just a set of platforms or APIs.

And the most important thing in this continual improvement journey is to be driven by data. And that data, I tried to capture in the flow metrics, flow time, flow efficiency, flow velocity and flow load.

Mirco Hering: And you hear that at the conference, right? Getting access to the data is actually really hard because for so many years we hid it in all our systems, and they were all disconnected. And now, I hear it in every presentation. How do we get the data out and connected really can make decisions based on that? And I think we're getting there.

John Rudd

Global Business Agility Lead

Subscription Center
Subscribe to Software Engineering Blog Subscribe to Software Engineering Blog