Agile Toolkit Podcast

CEO of Tasktop Technologies Mik Kersten discusses his session "Project to Product: How Value Stream Networks Will Transform IT and Business" at the DevOps Enterprise Summit 2018.

Connect with Mik and Bob on Twitter.

Learn more about AgileToolkit Sponsor LitheSpeed at lithespeed.com.

Transcript: 

Mik Kersten ‑ DevOps Enterprise Summit 2018

Bob Payne:  "The Agile Toolkit."

[music]

Bob:  Hi, I'm your host, Bob Payne, here at the DevOps Enterprise Summit 2018 with Mik Kersten. Mik, you gave a really great talk, one of the keynotes, and I really love the message that you were pulling in, bringing some of the Lean Manufacturing ideas. I know you've been working with BMW, so it's a pretty close call.

This idea of looking at data visualization, flow metrics versus compartmentalized, "We've gotten 20 tickets done, but what sort of value have you captured?" I love the fact that you were mixing four different types of work so that you can visualize ‑‑ How are your investment strategies paying off? Are you investing in paying down debt?

How does that, in the future, affect your ability to deliver feature flow? I just want to talk a little bit about your flow framework and some of the work that you've been doing.

Mik Kersten:  Excellent. Thanks, Bob. Yeah, I think that's a great summary.

Bob:  Great.

[laughter]

Bob:  Why don't you just give a little recap of the things that you were saying and some of the clients you're at?

Mik:  I realized, like you, like a lot of us, having to live now through basically, a decade of large organizations trying to go Agile and seeing some repeated failures, knowing that the core practices make sense, yet these transformations tend to go sideways. I just kept asking myself, "Why do they go sideways?"

I've witnessed some of the longest running ones, as closely...It's one of the things that I relayed in the book that we launched here, "Project to Product," which will actually be available on November 20th. That's still on pre‑order.

Bob:  I don't yet have a copy of that. I went out to dinner at Lotus of Siam. [laughs] I didn't make the sign‑in.

[laughter]

Bob:  I wish I had.

Mik:  There's a story in there of Nokia, who were a poster child of Agile transformation. They were, at a business level, incredibly motivated by this thing called the iPhone to succeed in that Agile transformation, and, yet, something failed.

Stephen Elop, in, I think, 2013, sent that burning platform memo when he was CEO of Nokia, realizing they had not done the right things to allow them to become a software innovator, which when, screens get that large, you'd better be if you're going to compete with Apple. Somehow the business, the leadership at Nokia at that time, was doing the wrong things.

I was speaking to technologists there who actually knew what the problem was. They knew that the Symbian Operating System ‑‑ they were in transition, going from Series 40 to Series 60 ‑‑ it was not going to be able to support the kind of features that you needed, things like building on an App Store, on top of the platform that was there. Yet those investments were not being made in replatforming.

They were being pushed to go Agile and they were being tested, basically. The measurement for the transformation was the Nokia test, how agile these teams were.

Whether they were trained on Scrum, that had nothing to do with how much more quickly, if you look at the end‑to‑end value stream of what Nokia was doing of delivering software, how they were actually optimizing or improving their ability to deliver the kind of platform features that you needed to survive and be a phone.

Bob:  A local optimization problem rather than a system's.

Mik:  I got this term from Carmen DeArdo. I think of it as 100 percent as a local optimization of the value stream. They were completely doing a local optimization of the value stream. Then you have to ask yourself, "Well, was it really the architecture that was a problem? Were their deployments that's still there?"

She had some impressive security checking deployment automation. They had some reasonable automation in place. I actually thought they were doing quite well for a company at that time on their delivery pipeline.

The bottom line is the business was not giving the technologists the chance to replatform and give them a shot of surviving. Of course, then they end up switching operating systems and the whole mess happened. They lost the market as a result.

You look at all these other companies who have done that. Amazon completely replatformed. Probably spent over a billion dollars doing that. Bezos realized that they could not scale on the old platform. We've seen LinkedIn do this.

Many of the tech giants know, at a business level, when to shift and, rather than incrementally building features, recreate a platform so that you can get through the next generation of technological change. Those companies who have replatformed, they tend to have CEOs who came from software development, who actually were programmers at one time.

I realized that we need a new language to help these Agile, these DevOps transformations succeed so that business leaders and technologists can work together to determine they need to do something like a feature stand down, when they need to do something like a replatforming.

When security risks or other kinds of risks, like the privacy risks, need to become a focus, and what that means across the different product value streams.

In doing that and trying to create this framework, I realized that the main thing getting in the way of people having the right conversations ‑‑ leaders on the business side and finance side with the people on the technology side ‑‑ was that there was this completely messed up layer separating the two. That layer was project management.

[laughter]

Mik:  The fact that rather than measuring ‑‑ and this is where the car man and production line, manufacturing line analogies do help. There are places where they don't help, but [laughs] one of the places that they do help...

Bob:  Time and motion set us free example. [laughs]

Mik:  One of the places where they do help is that there is no separation between the business and production at a company like BMW. Everyone knows how much is flowing through those value streams. When they need to increase production of a car, like in '93, they increase production and there's more market demand.

The concept of pull goes all the way through production, right to the business. The business understands the concept of pull and of product value streams. I realized we need to replace that product management layer that manages things to costs, budgets, and timeframes, and assumes time frames are certain.

Which, of course, goes completely against agilities to bake in two years of uncertainty into a software project. It sounds as crazy as it is, right? Yet, everyone is saying...

Bob:  Also, you were unable to exploit opportunities that come because your plan doesn't include those opportunity.

Mik:  Exactly. The only thing is to get away from what Mary [indecipherable 7:12] had called the cost in a trap in this great blog post that she wrote. Which is, again, if you're measuring to cost, chances are you're going to succeed at reducing costs. There's an even better chance you're going to succeed at reducing how much value you deliver in the process.

Whereas cost reductions can be very important, but you need to focus on value delivery. We need to measure value delivery in software.

I realized, for me, as someone who has come out of...worked a lot in Agile, who spent basically two decades doing Agile development, or overseeing Agile development, that the way that I was communicating about it was not working for people on the finance side.

When I first told my CFO about story points, he looked at me like I had a unicorn horn on my head or something of that sort. That we needed a language that was higher‑level and more compatible with the way that business leaders think to allow them to basically participate in understanding what flows through software delivery and have these teams work together.

That's really the goal of the flow framework.

Bob:  Great. I know that the flow framework, it looks at feature flow, which is a proxy for value. It's not a direct measure of value. You certainly have quality metrics built in. I notice that you also looked at team engagement as part of that part of the Tasktop tool.

Are you also doing anything integrating ‑‑ and I'm sure you probably are with some of the tools that you're able to integrate ‑‑ pulling in customer MPS, referrals, or any other pirate metrics or other indicators of possible...that are a little closer to real value?

As Microsoft showed, one third of their things added value, one third were neutral, and one third were negative. You could run like hell and stay exactly where you were, producing equal numbers of negative drivers and positive drivers. I'm just curious because I haven't drilled down enough on that.

Mik:  No, I think that's a really important question. The flow framework at the highest level has two components. It has these flow items, like features. Let's just talk about features. There are features, defects, risks, and debts are the four flow items.

It has those, and so you basically measure the flow of those. At that point, all you're really doing, as you're saying, Bob, is focusing on the efficiency of flow, the productivity flow and so on. That's not telling you at all whether you've done something useful to a customer

Bob:  There is a huge advantage because you're tracking across business, IT, and operations, which is different than tracking work inside of an Agile team.

Mik:  Yes, there is. It's different, yeah. What you're doing ‑‑ and we can do the car analogy at this point, the plant analogy ‑‑ is you're seeing if value can flow without interruptions through this value stream or where the long waits are.

It's because there's a dependency on another product value stream who's not made that API for you that there were supposed to, and so on. All you're getting there is making sure that things flow. You're not necessarily delivering any value. The flow is based on pull. What you do is you correlate the four flow metrics.

In the flow framework, you have this section of business results. Those do define value, cost, and so on. You basically are looking at a dynamic system.

The business results, the whole goal of the framework, both the flows and the business results need to be defined for each product value stream whether that's an external product, whether that's an internal billing system, whether that's a developer API that you're building or a piece of the developer platform.

When I'm looking at the full framework internally at Tasktop, what I see is, "OK, we've delivered all these features. We increased our feature velocity. Did that produce more value?" For me, as a software vendor, the value is going to be revenue.

Bob:  Revenue, retention, referral.

Mik:  Exactly. Retention rate, upsell rate, so on. That's the value component. The key thing is the flow framework forces, A, the measurement of flow across the entire organization, and, B, specifying value, cost, quality, and happiness for each value stream.

Now, for an internal product, you might just specify value as adoption. The key thing is you're specifying it. Otherwise, you have no business investing in it if you don't know what the value is. It's a correlation. We don't see exactly how this feature...It's not taking the approach of putting a business case in every single feature and measuring the outcome of that business case.

It's actually allowing you see this much...You can do that if you're that sophisticated, but you're seeing this much higher correlation then. "OK, we invested a lot in feature delivery. Did that produce a business result?" The other key thing is to measure cost.

You measure cost per product value stream. Keep in mind that the whole point of making these product value streams first class is because I notice that Agile teams or feature teams, they're great, but they're not coarse enough, they're not big enough.

One product can involve up to, I think 10 is probably the most reasonable number. When I see project investments go over 10, things start getting worrying. Having a couple hundred people contributing to one thing gets tricky. It's the false Scrum of Scrum size that you can go. You're measuring cost and employee engagement through something like the NPS across the product value stream.

As an example, in the case of Nokia that we talked about, you would have seen a horrendously bad employee NPS on the product value stream of the people who were working on the core platform because they could not do enough features. They had this technical depth.

I've seen this at Tasktop as well, where, if you put too much flow load, Web work in progress on a team, and through giving them too big of a backlog of features that they can't complete, I have seen repeatedly that team's employment or promo score go down because everyone's miserable.

We hire people who want to deliver value, and when we get in their way of doing that, they're not happy. [laughs]

Bob:  That's back to classic work that Deming did. He looked at upscaling employees. The assumption that he went in with is everyone is trying to do their best. If you want different results, you've got to change the system.

What you're talking about from pull rate or the backlog, the focus between features and not paying down technical debt, all of those are part of what he would consider the system ‑‑ How is demand flowing into the team?

The same way that Toyota never takes more orders than they can fulfill. They never do. They do lots and lots of work to even the flow. It has turned them into an amazing industrial giant, but they don't have the "Glengarry Glen Ross" salespeople out there selling things they can't deliver. They know exactly what that'll do in the long term.

Mik:  Exactly. One thing I want to build on with your point around Deming is that my approach with the full framework assumes ‑‑ I've seen the opposite be assumed too frequently ‑‑ is that the business people are also doing their best.

Given their understanding and their frame of reference, which might be a financial background, might be a sales, go‑to‑market background...

Bob:  Might be a traditional project control background.

Mik:  Absolutely. They are doing their best. They have these extremely large budgets. They want this transformation to succeed, but, because the languages are different...Again, talking in terms of releases and deploys per day, those are not value metrics for someone on the business side who's trying to allocate hundreds of millions of dollars.

Bob:  When somebody across the table is speaking a language you don't speak, you see risk.

Mik:  Absolutely. You assume the worst and you see risk. For someone who's responsible for financial controls, that's your job. That's really my hope here, is that by creating this higher level, this less granular language, on top of what we've learned with Agile and with DevOps because, of course, those metrics down below are very important if that's where your bottleneck is.

At least it allows people to spot the bottleneck from this higher level to figure out how to invest, and to move the conversation away from projects, timeframes, and budgets, to project value streams.

Bob:  I don't know whether you happened to see Mark Schwartz's talk. He talked about three possible models that you can use when you move away from a classic project. One is the product that you talked about. These are obviously hybridizable. I'm not even sure if that's a reasonable...

[crosstalk]

Mik:  It sounds like a word to me.

[laughter]

Bob:  It does sound like a word, we we'll give it that. These are concepts that could work together. He says there's a product view. There's a product model that can work. There's a budget and investment model that can work. Then there's also the outcome model that can work.

When he was at Citizenship and Immigration Service, he said, "Look, we need to reduce the wait times for people applying for benefits, the backlog that's holding up adjudicators. We need to improve the adjudicator's ability to do their work," and some other objectives, depending on which portion of the business or the mission that he was looking at.

He just simply laid out objectives. He says, "If you do it with adding IT features, great. If you do it with eliminating IT features, great. If you do it changing a business process and not doing anything with IT, great."

I'm curious. My gut reaction is I can see how we might be able to instrument that flow framework to look at those outcomes. What is your thought on those three models that he posited in his book? It was released at the same time yours was. [laughs]

Mik:  Yep, Mark's doing some great work. Just because I've seen too much, I would just call it flailing between different terminologies and so on, I've just decided to try to create again a common and as simple language as possible. I did iterate a lot with a lot of very smart people on what those words should be.

You can do everything in terms of customer experience. In the end, this is all about having a customer‑centered perspective. That's why it's easy and good to go back to those Lean principles from Lomack, from Lean thinking ‑‑ product value streams, customer pull. It's very compatible. The approach that I've taken is that everything's a product.

The reason I've done that is because I've seen that work. I've seen some very forward‑thinking companies like the BMWs, the Nationwides, the Targets of the world who, when they start thinking of everything as a product ‑‑ because if you think of things as a product, you have to specify the customer ‑‑ it's not a product if you haven't specified the customer.

It forces people, especially on the business side, to think in terms of the customer ‑‑ internal customer or external customer, technical customer or paying customer. There is this discipline that we can now just continue evolving. We've got product owners. We've got product managers. Product management is a discipline that's actually getting established.

We can apply those things. Once that's in place, wherever the organization ends up in terms of the hybrids that they would take from Mark Schwartz's models, in my view, they're on the right track.

Maybe they will call it the customer experiences or engagements, whatever it is. In the end, to me, consumers love products. They love consuming products. You might call them services sometimes. You might get with their online and so on, but, in the end, we want those products to work better for us. We want more features sooner and so on.

I've tried to distill it to give people a very concrete starting point. If they want to evolve the terminology, they certainly can.

Bob:  Is there something that you've learned or are going to take away from this particular conference?

Mik:  Yeah, there have been some fascinating learnings. The program's been just amazing. The amount of work that Gene puts into the program, it blows my mind every year, and seems to get better every year.

Interestingly, not only because of his effort, but because of this collective scenius, basically, where you've got people working together, starting to use similar terms, evolve those terms, have these great conversations.

I've been amazed at how much actual consistency of message there's been at this conference as everyone...The different angles that the different speakers and other contributors are looking at, taking a great set of practices from DevOps.

I really think DevOps had a, by virtue of being so focused on automation, flow, and feedback, it really has accelerated some of the things that I do think stalled out in Agile.

Bob:  The one thing that I fear is that we may stall out. Certainly, the folks here get it, but we may stall out when those mainline organizations think, "Oh, DevOps, that's an IT thing."

Mik:  Oh, yeah. That's happening. That is the way everything will get derailed and DevOps in these organizations will fail in similar ways to how we've seen that in transformation failures. If you push it off to IT, that then...That is one of the stories that I recount in the book, which is, you think it's that part of the transformation's IT. You're wrong.

That was really my goal. The biggest goal of the flow framework is to say you have to do this and then you have to do this at an organizational level. If you just allow our teachers to transform on their own, you will fail. In the end, it's about creating, again, these product value streams.

The really interesting thing in the program now is actually that, which is taking something that's a good set of technical practices and tools that we've learned out of DevOps, the components of Lean that have gone into this community, making them bigger, and bringing them to the rest of the organization, bringing them to the business.

The fact that there was a talk with...Who was it? From Nike. I believe her name was Anna. She's a lawyer. She's one of their top lawyers. The fact that she's on stage with Courtney Kissler, that's pretty amazing that the learnings from this community are actually reaching to that part of the business.

I would personally love more conversations with people like CFOs who care profoundly what's happening with value and spend. [laughs]

Bob:  Oh my God.

[laughter]

Bob:  Yeah, especially as they look at the disruption and the people falling off S&P 500 or whatever index of being a great company you look at. CFOs have to be keenly interested in, I believe, survival. You can't grow unless you survive.

Mik:  Exactly, and in this, because one of the things I point out is that we are at this turning point, this point where the rate of disruption then creative destruction will probably accelerate, I don't think you can survive if you don't grow, and you can't grow without mastering software.

Bob:  I often use the other Deming quote, which he was talking about, continuous improvement, "Learning is not compulsory. Neither is survival." [laughs]

Mik:  Yeah, exactly. Back to Deming, everyone has the best of intentions. The budgets are there. It's just a question of having the right model and framework to make sure that things are tracking the way that you expect them to rather than to be disappointed two years down the road, that you've saved some costs, but now things are moving even slower than when you started.

Bob:  Yep. Excellent. Thank you very much for coming on the podcast. I hope your book is a smash success. We're looking forward to working with customers that are using Tasktop. I don't usually do any tool plugs, [laughs] but yours looks very interesting because it focuses on an area that we think is crucial in the work that we do.

We're mostly tool agnostic. We often joke that our biggest tools are your executives.

[laughter]

Bob:  We do a lot of work with executive teams and organizational transformation. I never actually make that joke.

[laughter]

[crosstalk]

Mik:  Yeah, exactly. There's rooms where that joke'll fall flat.

Bob:  Yeah, that might fall flat.

Mik:  [laughs] That's great. Thank you, Bob. It's been a great conversation. Thank you.

Bob:  Great. Thank you. The Agile Toolkit Podcast is brought to you by LitheSpeed. Thanks for tuning in. I hope you enjoyed today's show. If you'd like to give feedback or be on the show, you can ping me on Twitter. I am @agiletoolkit. You can also reach me bob.payne@lithespeed.com.

For more free resources, transcripts of the show, and information about our services, head over to lithespeed.com. Thanks for listening.

[music]

Transcription by CastingWords

Jeffrey Davidson and Jo Avent join Bob to discuss their Agile2018 session Hunting for Diamonds: Hiring the Very Best for Your Agile Team.

Connect with Jeffrey and Bob on Twitter.

Johanna Rothman joins the podcast at Agile2018 and discusses her sessions: You Have to Say More There: Effective Communication in a Distributed Agile Team and Agile and Lean Roadmapping: Incorporating Change at Every Level of Product Planning.

Connect with Johanna and Bob on Twitter.

Esther Derby chatted with Bob at Agile2018 about her two sessions - Creating an Environment for Successful Agile Teams and Clarity, Conditions, Constraints: An Alternative to Top Down Control.

Connect with Esther and Bob on Twitter.