Agile Toolkit Podcast

Kevin Fisher, Nationwide Insurance Associate Vice President, Lean Process Management (Lean, Agile, DevOps) sat down with Bob at the DevOps Enterprise Summit 2018.

Connect with Bob on Twitter.

Transcript

Bob Payne:  "The Agile Toolkit."

[music]

Bob:  Hi. I'm your host, Bob Payne. I'm here at the DevOps Enterprise Summit 2018 and I'm here with Kevin Fisher from Nationwide. Kevin, we worked together an awfully long time, back from the early days of Agile, at Nationwide.

I remember, actually I Tweeted, because it was in the talk with a couple of gentlemen that were from Nationwide. They were talking about the DevOps roll out that they're doing and they had this sort of Sherpa chart.

It's always great to see how far you guys have come from the early days. I was impressed by their talk. Unfortunately, I didn't get to your talk, but I hear you had some pretty interesting things in your talk around metrics, and measuring flow, and that sort of thing.

Maybe we can chat about that?

Kevin Fisher:  That's right, Bob. Bob and I worked together back in 2008 when we experimented with Scrum and XP. Bob and some other folks were our on‑site coaches.

From those early days of having one Agile team, now we have 200 Agile teams. All of our work is done with those 200 teams. We think of our transformation in three distinct kind of bodies of work.

The first one, obviously, is introducing Scrum and XP and then scaling that up. That took a long time, given our size of our organization. Now we're focusing on DevOps. You heard the talk from Jared and Jim. We're rolling out DevOps in a self‑service way. It's more carrot than stick.

Bob:  It was great to hear, because all too often it is not implemented in a self‑service way.

Kevin:  We want teams to figure out their local impediments and use these techniques to solve their local processing problems.

We gamified the friendly competition between teams. We have a monthly DevOps challenge. All the teams can submit their progress against whatever that topic is of that particular month. We choose a winner, and they get custom stickers for their laptops. That's it. There's no monetary conversation.

[laughter]

Kevin:  When we were exploring and doing some experiments, we had two of our teams have a friendly competition against each other, and it was simple. We didn't give them extra time. They had to complete all their normal standard work.

We said, "What can you do to go faster and get your work done faster? By the way, you have a colleague team over here that we asked the same challenge. We want you to attend each other's show‑and‑tells."

It was fantastic to see the friendly competition in their eyes when they're attending their colleagues' show‑and‑tell and the colleagues talking about how they just pruned 2,000 automated tests that weren't delivering a whole lot of value to 700.

Now they have it integrated into their build process. They feel real good about it. They have a big visible monitor that displays the health of the build on a real timestamp. Then you can see the other team thinking, "Wow! We could do that. We could beat that."

It was very healthy, and that's how we came up with the idea. Then, when we heard about the Verizon cup...Verizon has a similar program, and we said, "That is a fantastic idea. We're going to leverage that idea from the Verizon cup. We're not going to make it quite as elaborate ‑‑ they actually give a trophy. We're going to scale it down and just give stickers," and it's been a great thing.

Then the third avenue for us is this whole concept around changing the mentality of our senior executives in finance, from project to product. That's a difficult turn to make.

Bob:  It's a huge turn. Yep.

Kevin:  We've had many conversations over the years. We've made some changes in IT that are putting us in the right direction, but we can't go further without the business being side by side with us.

Early on, attempts at forging that conversation with our business executives and the finance teams was not received well, because we kept talking in IT terms.

We want to bring Agile, we want to infuse Agile methods into our planning. We want to talk about this. We want to talk about that. They rejected a lot of that conversation because it was viewed as very IT‑centric, and just not in terms they could understand.

The progress we've made on two fronts over the last couple of months is number one, we now have a very rudimentary view of lead time and cycle time within the functions of IT.

It's not perfect. It's certainly fraught...You could poke holes in it if you look real hard at it. But, when we boil it up at the macro level, the law of large numbers takes hold and we actually feel like yeah, this directionally correct enough.

It shows what we knew all along and that's the development piece of hands on keyboard, writing code, is not the problem. That's actually the shortest piece of our value chain.

Bob:  By a ridiculous amount.

Kevin:  By a ridiculous amount. Two and a half percent of the time we spend on stuff is actually on hands‑on‑keyboard coding.

Bob:  That must have been validating but also a head‑scratcher. I'm sure you took a look to make sure you've got the numbers right because that seems like something that's very...

Kevin:  We have the numbers. It's very low.

Bob:  People would want to poke a hole in.

Kevin:  People want to poke a hole in it. It's a very large data set so, "All right. Let's say we're off by a 100 percent." It's still pretty low.

Bob:  Five percent.

[laughter]

Kevin:  We still have a huge opportunity space after the development is complete and, obviously, well before the development happens. Now we're really focused. It gives us data to have ammunition with the people that are either dragging their feet on DevOps and CICD.

We can say, "No, no, no. Here's the data. We need to improve this. You need to show measurable improvement." Then it also helps us in those conversations with our business partners to say, "Look. This business‑IT relationship is really super important and perhaps we need to start thinking about things differently."

The second half of this conversation that's actually been new in the last several months is our CIOs ‑‑ we have a business unit CIO lined up with each unit business president ‑‑ have been successful talking with their business unit presidents and their cabinets, made up of SVPs and other senior leaders, and trying to get them to conceptualize a future state in small increments of time.

Historically, our company has made very large multi‑year bets, and a handful of them. We're going to spend hundreds of millions of dollars over the next five years and all this wonderful stuff will come out of it that's extremely difficult to measure. That doesn't allow us to respond to market conditions at all.

There was an impactful trip, probably similar to most companies. We've had good success getting our executives out of the building to visit with other companies. It doesn't even have to be a financial services company. It could be other industries.

Talk with peers at their same level, and learn. We used it to get progress with our IT leadership on adopting lean management techniques across how we scale. Now we've used it with other business executives to get them to think about conceptualizing outcomes in smaller increments.

I tell the story that we had a group of executives take a trip out West to visit the typical unicorns of the world, Facebook, Google, Amazon. When they were on their trip, they said, "We need to go figure out how these companies do a much better job at long‑term planning than we do." They came back...

Kevin:  Yeah. They don't do long‑term planning.

Bob:  They do strategic execution rather than strategic planning. [laughs]

Kevin:  Correct. Yes, yes. Exactly. That's what they learned. They said, "We actually don't do that. We're just much better than you at sensing and responding to market conditions." What that trip allowed the CIOs to do is introduce ‑‑ I know it sounds simple ‑‑ language that the business leaders could rally around, that they didn't view as IT language.

They didn't have an allergic reaction. When we say things like, "Small batches, iterative work," they have an allergic reaction. They're like, "You're talking IT speak. Agile, that's like an Italian term. Don't come to me with that."

Bob:  [laughs] It's a major word.

Kevin:  Yeah. [laughs] It's a major word. They don't know any of that stuff. "You're an IT folk. Don't tell me how to run my business." They have an allergic reaction to it.

When we talk about sense and respond to market conditions, we actually introduced the term called "base camp." You saw it in our DevOps mountain journey. We have base camps and just tranches of work we want you to try to achieve. Those things that we listed don't have to be done in any particular order, but they needed to be done before you move on to the next base camp.

That concept is now resonating with our senior business leaders like, "OK. You're saying that we can package up or at least conceptualize this body of work. You can get it done in a reasonable time frame, usually three, four months. We can deploy it to our end customer, whether that's the end‑customer, or a distribution partner, or what have you.

They will get value. We'll get value. We'll measure that and then we will decide whether we want to continue or pivot. It's broad concepts that are outlined in books like "The Lean Startup," by Eric Ries and others.

We are using language that our non‑tech‑savvy business leaders can rally behind and don't feel threatened by. It has been really impactful for us to get to that point.

Bob:  I was speaking earlier with a gentleman from Microsoft and they did a sort of long‑term study over the features that they had added. They found that one‑third achieved some improvement in customer experience, a third were neutral, and a third were negative.

When you that sort of data that says if we just produce the things that we will plan to do, we're at net zero impact unless we kill the losers and double down on the investment in those things that are moving the needle.

There was a huge conceptual turnaround for Microsoft. They're huge. They have a huge legacy codebase. So big, he said they actually broke Git and they became one of the major contributors to the Git source code because it was taking 12 hours to clone the Windows repository onto your laptop to make changes.

It was just so a lot bigger than the Linux kernel, a lot bigger than any other stuff that had been thrown at Git to date. They developed the new virtual file system that's used in Git and they are now down to like two to three minutes for that clone.

This idea of reacting to an emerging situation, I think is one that can resonate. I'm really interested to get my hands on the "War and Peace and IT."

Kevin:  Mark Schwartz?

Bob:  The Mark Schwartz book. I loved his analogy with the battle with Napoleon and the slow decision loop actually not even neutralizing, but making the decisions actively bad.

We have not done ourselves much good in the community to allow this idea that Agile, DevOps, the lean terms we've been using were fundamentally IT. It's good to hear that you guys are at least turning that around.

Kevin:  It's the combination of those concepts that we feel are going to give us the advantage and the power. If we only focused on making our Agile machine more efficient and implementing DevOps everywhere...

Bob:  10 or 15 percent, possibly.

Kevin:  ...it would only take it so far. Now, I will say we have an example of where...We have a particular couple of teams that support our digital online experience where customers deal us over the Web.

They are probably our most advanced example. They can deploy at will. They can do safe, reliable, zero‑downtime deployments whenever they need to, multiple times a day if necessary.

They are our business partner and they have by the way done a great job forging a very strong relationship with their business partner. After they had done this only for two or three weeks, the business partner remarked, "Well, maybe I don't have to test everything now." Like, "Yes."

Because now he has confidence that when things do arise, you can fix it right there, very quickly. Our mean time to repair is very short. That saves him time and energy, it saves us...

All good things happen when that circle gets tighter. Being able to demonstrate, not just talk the talk, but demonstrate it, you're boots on the ground with this. When we actually can achieve this, it changes the whole culture around and how to thinking around it.

Bob:  What has been an interesting thing that you've learned at the conference?

Kevin:  Focus of my talk with Nicole from Tasktop, plus many of the other talks here where they were talking about CSG, Mark Swartz's talk in the morning yesterday all around the concept of project to product, and the difficulties with that. Not a one size fits all models, not a prescriptive model, a lot of people trying to solve the same problem.

There seems to be wide agreement that whether you are approaching that from technology left or from the business process on down, you're going to uncover all sorts of complicating factors.

I was talking with Verizon just a few minutes ago and as they tried to move along their project to product journey, they might have success with a business partner rethinking how they are going to conceptualize work in a product way.

Even the roles that go along with supporting that work, thinking about the differences between what a product manager might do, and product owner, and should they be basically sourced from the same group.

All those sorts of nuances of execution. Then when they get to the supporting IT components, they figure out well, the IT components were never architected to operate this way together.

I heard similar stories from Discover Card where they've done a nice job with some of their executives on conceptualizing around products not projects, and they need to come to figure out, but even then within a product realm, they have miniature silos within IT where teams either have competing and not‑compatible technology.

[crosstalk]

Bob:  Business intelligence team. So many components.

Kevin:  So there's a huge ripple effect of this. I think we're very early on in these conversations. Especially if you are not a traditional CPG company.

Bob:  Yeah. That's what I was going to say. The future is already here, it's just badly distributed. [inaudible 17:02] .

[laughter]

Kevin:  That's a great way to say it, yes.

Bob:  Yeah.

Kevin:  Years ago, 2004‑ish, I was a senior product manager for AOL. We did have it figured out, business and IT together, had a PL. Everything we did on a weekly basis was outcome driven, and it made perfect sense at the time. A lot of companies were not there.

Bob:  Were you out in the Virginia area?

Kevin:  This was AOL Columbus. Remember they bought CompuServe a million years ago. Netscape ran out of Columbus. We spent two days a week in Dallas, but primarily it was Columbus.

Bob:  OK, because we did a lot of the early work with Agile with AOL, but it was all near our scenic Herndon office.

Kevin:  We were doing Bluegreen employments every Wednesday morning and we didn't even know that that was a thing back then. It was just how we deployed code, yeah.

Bob:  That's great. Is there anything you're going to take back that you think will be impactful?

Kevin:  I am. We're in the midst of modernizing our tools that support program and project management and Agile life cycle management. We've made significant progress in how we organized IT, how we execute Scrum and XP across IT. We have not modernized any of the tools that people use to actually do that. We're going to fix that in the next couple weeks.

Good conversations with a lot of companies that are either a bit farther along than we are or recently made a change. It's been great learnings for us and that team that's here to do that.

Bob:  Great. Thank you so much for the chat. It's always been a pleasure working with you.

Kevin:  Bob, it's always a pleasure.

Bob:  [laughs] Good.

Kevin:  Thank you.

Bob:  Bye.

Photographer:  Can we do a picture?

Bob:  Sure.

Kevin:  Because no one will believe that I was on a podcast.

Bob:  Well, they will.

Kevin:  Was that OK?

Bob:  Yeah. It was perfect.

Kevin:  You do this all the time. I'm new at it, so...

Bob:  Well, yeah. They're all this sort of conversational... [laughs]

Kevin:  Did it take?

Bob:  Yeah.

Photographer:  Yep.

Kevin:  Cool. All right. Thank you very much.

Bob:  Great. If you're going to tweet it out, I'm @agiletoolkit.

Kevin:  Cool.

[pause]

Bob:  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 at 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]

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.