Mik Kersten - DevOps Enterprise Summit 2018

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