Not long ago, I introduced someone named Kevin Sutherland, who's doing really
interesting work in large-scale agility in the governmental public service
space. So I decided to have him on the show because I think what he's
doing and how he approaches it is something that we could all learn from. One
of the biggest challenges we face in implementing agile is doing
it at scale in large environments where the number of people,
complexity, dependencies can really obstruct
the value that we're trying to unlock. And Kevin is out there finding solutions,
tweaking things, blowing things up and rebuilding them all in service
of one thing, using Agile to get value to
people who in this case desperately need it. I think you'll really enjoy
this one. Check him out. That's this week on the Badass Agile Podcast.
Greetings team. Welcome to the Badass Agile Podcast.
I'm your host, Chris Williams.
Hey Kevin, how you doing, man? Hey, good. How are you? Very good.
Thank you for coming. I'm really excited to talk to you. Awesome. Yeah, it's great.
Glad to be here. Now, first of all, where are you from? Like, where are
you at right now? Where am I speaking to you at? I'm in the Des
Moines, Iowa area in a smaller suburb called Ankeny. Very
nice. Well, welcome. I'm just north of Toronto here in Canada. I want some
of your background. I, I have some things to tell my listeners about how I
know you or, or how we got to start talking, but I thought I'd let
you go first. Tell me a little bit about your background. Sure. I, uh,
started my career with Accenture out in California implementing these
large organizational and system transformations. Actually grew up in Iowa,
graduated from Iowa State, and made my way out there because my brother was out
there Long story there, but it was probably the time I
started was around the same time the Agile Manifesto was being signed.
So at that time, Accenture was still all in on full-out
waterfall methodologies. Accenture actually had a proprietary
delivery method that everyone was trained on called
Accenture Delivery Methodology. And it's kind of funny looking back
now 'cause you see a lot of these people talking about SAFe and complaining about
the structure and complexity. ADM was like thousands of pages
of how to explicitly execute a waterfall project. It
was really something. And so the first project I was on, we
got to see some of the results of that. I was on the implementation support
team, which I have a lot of crazy stories about, one of which
was we were doing implementation support for staff in the
offices where they were using the system that we delivered. We
arrived at their office and the staff were outside
picketing basically us. They had gone to the trouble of making
t-shirts with our system name on it, a big X through it.
They were chanting, you know, we hate your system, we won't use it, that kind
of thing. I mean, just think of how much you have to hate a computer
system to go to that level of trouble, right?
Anyway, that's just a story from my earlier days learning
about Waterfall, but around 2012, agile
approaches had made their way to places like Accenture.
So instead of going to this ADM training, we started sending folks to Scrum training,
we started selling projects as agile projects. We sold one of those
to the state of Iowa, and I relocated back to Iowa to deliver
one of those projects. And looking back at the contract that we
were working on, nearly the only thing that was agile about it was that the
customer could change their mind frequently about the 700-page
contract. The hundreds of system requirements that all still had to be
delivered anyway. And so needless
to say, after exhausting the entire schedule and
budget of that project, we were about 15% complete
with the actual contract scope. I ended up making a decision to leave
Accenture at that point, started my own company, Strategic
Innovation Consulting, with this mission of bringing better
strategy to these state government contexts to improve outcomes for
people rather than just focusing on the implementation
of systems. And so, I've been working more on the state side as
an independent consultant to help with this mission. You know, at the same time, I
became much more engaged in the Agile community, which offers
principles that I think are very aligned to that goal. And I became
a consistent listener of this podcast, of the Badass Agile
Podcast, which I think resonates very strongly with the mission
and gave me the encouragement to keep trying to change the world for
the better, even though the world isn't super interested in being
changed. So, Chris, thank you for that. Of course. Well, thank you.
Thank you for listening. So I want to touch on a couple of things there
that I think will be really valuable to this audience, because when we think of
doing agile in government, we think about resistance and we think about
problems at scale. But I want to hear it from you. You've been doing
work for the state of Minnesota lately.
What are some of the unique challenges that you found in that experience
and the ones prior? That large governmental
organizations carry? Yeah,
sure. So, you know, and actually it's interesting, I found that
in doing both work with state governments as well as
some work in my history of working with corporations, one
thing that's interesting is that a lot of the same big challenges that people
see and are concerned about are very similar across the two.
So these you know, having outdated legacy systems, these command and
control hierarchies, lots of bureaucracy that gets in
the way of decision-making, long planning and funding cycles,
you know, siloed teams that end up with order-takers as opposed to
empowered delivery practitioners. But I think there
are a few very unique challenges that are specific to
government that create issues that corporations don't have to deal with.
One of those is that the impacts are different in
how they're handled. You know, there's a lot of talk these days about outcomes, and
if you follow someone like Jeff Patton, they have really good content on
output versus outcomes and impact, which I think everybody should check out
his stuff on that. But if you look at what he's saying
there, when he describes impact
in his content, he's referring mostly to commercial impact, so whether
the business is profitable increasing market share, commercially
viable, and it's pretty clear where
everybody wants to be going in those environments. But in government,
it's quite different. There are, you know, we often don't have
paying customers. In some cases, we're talking about a captive
set of people who have really no other choice than to rely on the services
that they need from the government. And helping these people actually
costs money. So making the experience better for them
might mean we spend more money. And now we have this
dilemma because there's competing outcomes depending on
politics. If, you know, is it more important to help people or is it more
important to spend fewer dollars? So like if you imagine working at
a company and you had, in addition to all the typical
stuff you're dealing with, you had half of your leadership that's launching initiatives that are
intended to make it harder to buy your products. It's, you know, that's something that
it feels like often in a government environment. For an agile
practitioner who is rooted in and interested in
helping companies get results faster, some of the challenges that you
didn't mention that are under the hood in a governmental organization would be regulation, of
course. You mentioned politics, but really, we can't just do
things however. There's a strong element of
oversight and following the laws and the rules
and probably changing in response to changing economic
policy, among others. So that creates interesting
challenges specifically for agile practitioners who aren't just trying to get
the ball across the goal line. They're trying to do this
thing faster, better, with less waste, presumably, as a
starting set of principles. What have been some of the interesting
challenges in doing Agile in that environment that people who've
never worked in government might not know? Well, I mean,
this one's kind of interesting. When I talk a lot of these challenges that
are unique in government, I wouldn't say that any of these
specifically cause something that's different for Agile practitioners
in those spaces than in other spots. And I guess I
would say that in my experience, when I'm
looking at Agile and its practitioners, and when I say that, I mean
people that are bringing truly the mindset of
Agile principles to the table, what I'm encountering
is that most of these folks avoid these environments entirely
because they just don't support it. And it's for that reason that
I don't see many of those folks engaged
in these contexts. They just don't survive, which is, Really common
feedback I've gotten over the past 10 years when I've been really trying
to take this question to the Agile community, you know, saying, hey, we've
really got something here that I think could be effective and helpful in some of
these more complex government constructs where you have a lot of the things that
you just mentioned, the regulation and a lot of those issues, we could apply some
of these concepts. And a lot of the main feedback I get
is, hey, Kevin, you can't. I don't know why you
keep trying. You should stop. Or they'll say things
like, you know what, I'm rooting for you. Good luck, man, let me know when
you've found a path that everyone else can follow. And so
I do think that's one problem that all these issues cause is that
the true concepts of principles of Agile and product just
aren't welcome, and a lot of people are saying no thanks, which
means we're left mostly with folks that don't understand the
principles or don't mind them throwing them out the window, calling something
a product that's not a product, running sprints to write requirements, basically using
Agile and product theater and not really
adhering to some of those underpinning principles.
And so then the end result of that is a lot of the folks in
these environments just end up hating those Agile words in general.
And so one of the things that I try to do to address that
is to apply a lot of the concepts but not use any of the words.
Rebrand. That tends to be helpful. Well, so that
leads into my next question. You're talking about how are you gonna handle solve
that problem. So you mentioned, just to recap, that the
Agile principles are not necessarily cherished there, and they may even become a bad
word because there's been a lot of friction or maybe bad experiences.
So what are you doing then? What's been successful for you
that listeners might be able to leverage and try for themselves?
Yeah, sure. So I think there's two answers to this one.
One is around like the incremental answer that people could go and try this
for themselves, and the other being the transformational answer that is a lot of what
I've been working on in terms of putting strategy around how do we shift this
entire conversation to be different. And so I guess I can jump in on
the incremental answer. Sure. Which, you know, this is what I've found, you
know, how I've been trying to apply these, you know, these principles in the
way I've interacted. And I mean, I guess the easy way to explain
my thoughts on this is be useful, right? Become
a person that people think of when they need something to get done effectively.
With a good outcome and without angering everybody. And in
these government environments, people like that are fairly rare, so you'll, you'll stand
out if that's you. And also, in a government environment,
urgency— urgent emergencies can come up quite a bit. And in these emergencies, people
are often willing to forego a lot of that structure that they
are comfortable with and willing to grant autonomy to you to get
something done if they're backed into a corner and just are out of options.
And so that happened to me quite a bit when I spent a lot of
time at the state of Iowa and the PMO lead would come to me and
say things like, hey, you know, XYZ team has been working on this
for months and hasn't made much progress other than writing requirements. But now we're
at a deadline, we need to get something to the legislature in a month, and
we're going to come back and show you something in a week and get feedback.
Cool. And, you know, at that point,
now we're using all of the Agile fundamentals without saying any Agile words and
starting to deliver amazing results. And I guess the
challenging part about that is, you know, once the emergency is over,
the culture starts to just gradually undo some of these
behaviors and mindsets that we've instilled because it's what it's
designed to do. And then we might have, you know, a few people that could
keep these things going if they had support, but it's really hard to get it
to stick. Like lasting, durable change through that incremental
method is not something I've personally been able to make happen.
Which really takes us to that transformational answer, which is where I've been spending a
lot of my time and energy over the last 10 years. So before
you get into it, and I want to hear about it, the— there's something
important what you just said there. When I'm teaching teams, I frequently refer to the
Apollo 13 moment. You ever see that movie? Yep. Yeah. So they,
they realize all of a sudden, because the spaceship basically split in half in flight,
so they had two different filtration systems, and the one that they're sitting in has
the wrong filters for the one that they're sitting in. So they have to
radio down and say, we have a problem, we're gonna run out of breathable air
before we get home. So you see this wonderful scene where everyone
just clears the table and they sit down with all the parts that they know
that they have on the shuttle and none of the ones that they don't, and
they come up and construct a solution. And then they go test it on the
ground before they send the procedure or the protocol
back up to space because they don't wanna send them one that doesn't work, but
they have all the gear on the ground to test it. So it doesn't work,
they reinvent, and then they finally come up with one that works
They upload it and it saves their lives. Then
the panic is over and we go back to regular mission control, which
is kind of like what you just suggested. And the thing that you said
that was so revealing was that the minute the emergency's over,
nobody wants to let the guardrails down and work like a bunch of
high-performance cross-functional people,
experts dedicated to innovating and solving a problem quick.
Which begs the question, is it the right move always to try to
scale agile to the whole organization in every situation? Or
do you just use it when some kind of
urgency demands it? Because to go in and, like you've
said, you've had trouble being successful messing up their steady state
ops. It's really hard to do. They're going to show up and protest you, right?
They're going to lock you out the building. So talk to me about the transformation
part because I want to hear how you would respond to that. Is it maybe
the strategy isn't to try to scale it everywhere, at least at least not at
first, but to put it where it's most needed. How does transformation work
the way you define it? You know, I think that's a great point,
is that, you know, we can see agile potentially
working in some of these pockets that can't be scaled to the whole
organization. But what I think the critical thing
that I run into is that even if we have
agile in a smaller sense, we need an organization that can support it,
will often require, in what I've seen, a pretty significant
transformation to the organizational ecosystem itself,
which really brings us to that transformational answer and has
been what I've been trying to explore and trying to figure out ways
to accomplish over the last 10 years. You know, really answering
this question of what kind of strategy do we need to
execute and shift these environments from their current state
to one that effectively supports what you're asking about as having
pockets of or, you know, some semblance of agile
delivery mechanisms in the environment and providing actual
value to taxpayers from an enterprise standpoint.
And that overall question is probably not one about agility, but I think the
principles are a big part of the answer of how we get from where we're
at today to an ecosystem that does support
that. And I've spent a lot of time in states building out
and testing out strategies for those transformations,
accomplishing this as part of Medicaid enterprise systems
modernization programs. And recently, Minnesota
published their strategy for modernization, which incorporated a lot of these
approaches as part of a request for information, asking for
feedback from the public and vendor community in general. And
that was really cool because, you know, I don't think the response could have been
any more positive. The gist of those responses was basically like,
oh, holy crap, this is a real strategy for actually doing this. Every
state should be looking at this and taking things away to try to shift their
organizational ecosystem to something that can support
agile methods. Right. So tell me, are you willing to tell us about the
strategy? Like, how is it different from what they're doing today, what most
people might expect or experience? Yeah, so
there's, there's a lot to this, so I'll see if I can do this in
a, in concise way, but, you know, I think the
fundamental underlying premise of what we're looking at is that the way
that states are currently looking at modernizing their systems is
resulting in such a poor result that we should almost be
doing the opposite of that in most cases, which is, you know, a lot of
these agile practices actually represent the opposite of what's happening
today. And it may start— may be helpful to start
with, you know, what is the current state and what's typically done, because I don't
know that a lot of folks will be familiar with, you know, how large
state As far as the system implementations go, and there's, you know, for people that
are really interested in reading and learning about this, there's a
book called Recoding America by Jen Palca, which I think does an amazing job of
describing like how did we get to the state that we're at today
of, you know, the effectiveness of these systems and ecosystems in
government. But there's likely, you know, lots of
factors that have led to this. But when it comes to these large
programs like Medicaid or SNAP, or like child
welfare, most states are afflicted by just
decades of policy change and layered-on
updates that affect both policy and technology.
And a lot of them have— they still are using the mainframes that
were developed in the '80s or '90s and have been building that around them.
And legislation that comes through doesn't really focus on
removing complexity or removing rules. It just keeps adding over time.
So the structures just keep getting more and more siloed, more and more fragmented.
Everybody starts buying products and they all do the same thing and
there's money being spent in a lot of different places. So it just gets harder
and harder to maintain this. Data's fragmented and
people want to fix it, of course, right? So the way that people
typically approach this is seeing the problems and the
symptoms that are coming out of the environment, which look to them like, oh,
we have a mainframe, our people are still using this green screen, You
know, fraud is coming up because we don't have a good understanding or grasp
of our data. And the way that the problem
solver instinct in all of us wants to, wants to address those is by
having an easy button solution to that problem. So like, oh,
we're still using a mainframe, replace the mainframe, or we don't understand our data,
let's implement a data governance program, whatever, whatever that means. And then
in government, like, these massive efforts take a really long time to
stand up. So we'll spend couple of years asking for funding to do that.
We'll spend a couple of years writing these large procurements to buy someone
or a solution to go do it, and we'll spend a couple of years delivering
it and then spend no time actually fixing
or addressing the actual reasons that we have those problems in the
first place. And based on, you know, the conversations I've
been having with states over the last 10 years, I would say that probably 90%
of these either stop before they go anywhere or fail massively.
And when it comes to the 10% that make it across the finish line, you
know, we're really not hearing from people, we're getting the value
for the money we spent. And, you know, we spend, we spend a lot of
money on this. And so, you know, the prevalent thinking over the last 20
years has been fixing this problem using like enterprise architecture
methods or capability maturity models, which, in my opinion,
just provide like a more structured, more expensive way to step through that
failure lifecycle. And so, you know, that's a lot
of what's typically done. And so just to get into, let's
contrast that with the transformation strategy work in the state of
Minnesota. You know, I'd say a first difference is the challenges that
are targeted by that strategy. With these typical
approaches focused on treating those symptoms, like the staff using the
mainframes, instead what Minnesota's put together is
looking to really unearth the root cause challenges that are causing those
symptoms and then addressing those using a strategic
framework that focuses on that enterprise transformation, using
more of an end-to-end outcome-driven use case model
to learn about better ways to structure the organization itself
with like outcomes and principles as that primary focus.
And then really working through a backlog of those end-to-end use cases
in more of a discovery mode allowing the governance, the
architecture, the solutions to be more emergent and part of the learning
rather than prescribed up front until we've got something that
works. And then really pushing these decisions about
architecture and governance to the point of execution where this learning is
happening. And like you're saying, maybe we can't scale
agile to the organization, but we can create an ecosystem in which
the folks can execute following a lot of those principles.
So is that— is it this like a specialized unit where you come to for
certain outcomes when you need that pressure to get them
done and in market quicker? Or is this— do
you sit at the table of an enterprise architecture board, or what's the
strategy? It might be best if you can think of one without
betraying any confidence or confidentiality. Is there an
example of you walk in and everything is siloed
and everything is complex and everything takes 3 to 5 years to build, But
we want change. We want to do differently. Change is not going to spread through
the whole culture overnight, but we could start getting some results in
little pockets of high priority or high urgency. Can
you walk us through an example of how you found that problem or
opportunity, how you addressed it using more agile means and
got a result much quicker that made or might make the organization
go, oh, we should maybe do more of this?
Well, yeah, so one thing, this is all still being rolled out in a way
that we haven't gotten to the execution yet. But the, the example
that Minnesota published as part of their RFI for
accomplishing this was starting with, you know, picking
out an outcome focus area within the enterprise. So they chose
new Medicaid enrollment and ongoing benefit maintenance. So basically, you know,
making it easier and quicker for someone who's seeking assistance to
to get and maintain their benefits in that space.
And they chose an existing, a single first use case of someone
seeking Medicare Savings Program assistance, and then published
a series of subsequent use cases that could be attacked once that first
one met a full definition of done. And the concept there
is, you know, not to try to change the existing
organization, but to create an incubator discovery mode
within which that Medicare Savings Program end-to-end
use case could be applied from, you know, the point of
I need to— of someone saying like, I need to apply for this benefit, to
I'm enrolled, I can get assistance, I can manage it effectively.
And doing that in a way where that can be demonstrated and shown without risk
to the existing environment and built until a point
at which we can expand with other use cases and then start to
identify where and when a transition from the current state could
be possible. It's more of a transition strategy as opposed to an immediate
need fix, if that makes sense. Yeah, for
sure. How, how do you inspire the people
on the teams who are not used to agile ways of working to
snap into line and do this? Because they might be thinking, I'm going to lose
my job, you're going to get me fired, I'm going to lose my job. How
do you change the way that that institution thinks? Because
there's a cultural thinking to a legacy
organization who's done things that way? That's how they got all those silos and all
that complexity and all that rigidity. How do you, how do you move
those hearts and minds, or is that part of it? No, that's definitely
part of it. And I think you've talked about this in the past, which
I will— I'll get the phrasing wrong, but something to the effect of start with
the willing and the minds that fit. You probably can recall it
faster than I can, but start with the willing and incubate
with a group of people that are 100% bought in. And those
will most likely be people that are acknowledging
what's, what's happening today is not working for them and are interested in trying something
different or, or have seen something that demonstrates that
this is something they want to try. And showing a result back
and communicating a success back to the organization is critical
to continue growing that incubation mode So we haven't
gotten there yet, but I think that's a key part of this
is getting an identification
of who are those hell yes people who want to try something different and new,
and then engaging in that. Another thing that's a little different in state
environments is that there are very few,
very little capacity of people that can execute these transformation types
types of work. And so what's typically done is states are bringing in these
massive vendors to do this. And in this case, there
is likely an element of needing to bring in outside
expertise to be part of that incubator environment, which is a
lot of the strategy work that's been put into what Minnesota's published,
because one of those big challenges is procurement takes 2 years.
So if procurement takes 2 years, that doesn't work. And so we've
been spending a lot of time thinking through How do we make procurement take
a week and how do we iterate and how do we assess and performance
manage, which is a little bit of a different beast from how
do we execute with an in-house team? Yes, definitely,
definitely. And that's when you would get— even if you were working in a bank,
people will say we can do agile all day long, but I got a vendor
here who won't do anything without a 6-week runway and they want a full spec,
right? Yeah. So what are some I'm
going to back up for a second, come back to this question, because I want
to know what are some of the ways that you get vendors on board when
they have no motivation really other than their contract
to play ball. But when I did some governmental work on and
off throughout the years, I remember one of them was for a department of the
government that basically made sure people who needed money
got it, and they were responsible for enforcing, you know, family
obligations, for example. But they wanted to make sure that,
that single parents and kids got the resources they needed. And so
every day we would sit down and we would say, okay, we want to do
this better, but we can't. Why can't we? Well, because you got to check
here and do this, and we have a process for that. Okay,
well, why don't we take a moment and remember who we're here for?
Because there is a mom out there who's worried that she's not
going to be able to feed her kids, and work is hard to find. And
even if she could get a job, she can't pay
$3,000 a month for daycare. This isn't going to work.
She's entitled to this help. She's legally entitled to the help and she can't get
it. How are we going to help her? Because if it's not
tomorrow, then it's the next day. But the next day her
rent's due and the next day her kids haven't eaten. So how are we going
to fix this problem? That's the— that was the attitude that we sat down. We
visualized who we were helping, the pain that they were going through,
and what would be a bare minimum answer to
get her the help that they needed. Do we need people to sit down in
front of a bunch of screens and go, oh, look, oh, look, there's a payment
here that's late. Hey, we can't have that. Like, can we unlock that payment? Can
we do it now? Why is it on hold? Can we clear this block today?
I don't care what the solution is. This is a bunch of engineers and astronauts
sitting in a room saying, look, we don't fix this, these
3 guys don't come home. And that's not acceptable. It's not even on your
radar. So let's get to work. That was kind of the attitude and the
spirit that we approached it with. And the people that were selected for that team
were, as you said, a coalition of the willing, like people who already
wanted to do this kind of work. Because they could see their end
customer. So back to your, back
to your point, how do we then help? That's like, that's easy to do inside
an organization. But if you got someone from, you know, KPMG or Accenture sitting
there outside, they may not get it. They may not want to play ball. How
do you handle that? Yeah. So, so that was one of the big
questions that came up as we were starting to plan this
strategic work, which is in many ways very different from the way vendors
behave in the space. And so You know, people were
asking the question, would vendors even do this crazy thing?
Which was, which is why we put out the RFI, which asked two basic questions.
One, you know, what do you think of this strategy? Give us your feedback.
And two, would you do this? Is this something you would be interested in
participating in? And, you know, I think given the way
the strategy is structured, it resonated very well with the
vendors. And I think it's for a lot of the reasons that you mentioned.
You know, one, it's focused on the strategy, is focused on outcomes instead of just
deliver this system no matter what happens, whether it's good or bad. So I think
that's appealing to vendors that they actually get to make a difference,
which they're not used to in these environments. Second,
it, it's looking at intentionally clearing away a lot of the
red tape and the hurdles that vendors often have to go through and saying,
we're going to give you the autonomy, we're going to give you the empowerment
We're going to, we're going to work with you to build this together in a
collaborative sense, as opposed to making you an order taker and giving you requirements.
So I think that's very appealing to people as well.
And, you know, so there are lots of questions around how the procurement approach would
work, which is, you know, a lot of what is going on right now is
continuing to have engagement with the mechanics and logistics
and how does payment work and how do we make sure that we're
incentivizing correctly and performance managing correctly. And,
you know, I've got a lot of content that's out out there that would love
engagement from everyone that's listening to say, you know,
here's some stuff you've put out there that makes sense. Here's some stuff that doesn't,
right? And we'll keep working through it. I don't know if everyone caught that out
there as you're listening to this, but sometimes as Agilists, we feel like we're expected
to know all the answers. Like you're not a consultant if you can't come in
and say, oh, do this, this, and that. And that leads to the
often comical McKinsey report where there's a whole bunch of
recommendations in there that nobody would ever be able to execute. So they don't,
they just leave you with the report. Right. So what's
happening with you is, okay, how are we going to manage vendors differently
so that they plug into this kind of initiative and ambition? And your answer is,
I don't know, let's go find out. Why don't we go ask them? Let's start
there. And so that's a really important thing that Agilists need to
remember is that you don't need, especially when you're facing a big challenging
problem like this one, you don't need all the answers up front. The
framework allows us, the principles allow us to say, I don't know,
but we're gonna experiment until we figure it out.
You got it. And that's like underpinning this entire strategy is this
notion of when it comes to the solutions, the architecture, the
governance, the things that we need, the answer is we don't know, but we're gonna
create a mechanism by which we can find out, be
confident about those things before we invest heavily in big decisions.
Yes. Which is very different from the way this happens today.
Evidence-based management, empirical learning, those kinds of things that we always talk about
but often don't do well. Let me ask you this. Anyone listening now
might be saying, well, this sounds great. I'm going to try this. Willing minds and
projects that fit. Let's start there. Let's not worry about having all the answers.
Let's acknowledge that this will be complex, but we're going to find a way or
make a way. Wonderful. What goes wrong? Like,
to be— let's be brutal and honest. What are the biggest challenges that have
been hard for you to address that maybe you're still working on?
Well, yeah. So the challenges in this space are really also
the same things that cause the 90% of those efforts to fail that I
talked about earlier that are solution-driven. And, you know, the strategy tries to
call those out and come up with mitigations for them. But I would say that
there's two that are primarily in the way at the
moment, one being just
that something that's transformational really requires the ability
and capacity for leadership to commit to and support something
that that can move forward. And specifically in
Minnesota, many might be aware that the state is under a particularly
intense set of pressures right now, which is putting, you know, just everyone
in the organization into more of a reactive mode rather than a strategic
transformational thinking one. So it's possible that something like this
might be on a little bit of a hold mode until some of that subsides
or we get to a bigger tipping point of things.
So yeah, executive commitment and ability to support, protect,
defend, and, you know, remove blockers is a really important
thing that is tough to get in this space.
I think every Agilist out there would be listening to this and saying, okay, great.
How do you get that leadership commitment and support? Great
question. In terms of how we're
approaching it is we keep at it, right? So, I mean, the RFI was
a big step that I think should turn people's heads to
say, you know, even though this is very different, it's something that we should be
paying attention to and listening to. It was public. So there are
legislators out there that are, you know, seeing it, are able to watch the
videos, are able to read the content, are able to advocate for it.
Just being out there and communicating on it, I think, is important. And
then, you know, just continuing to tell that story as we're working through things
that aren't working and, you know, holding up examples of ways we could try
this differently. Is something we're trying. But again,
in a current reactive mode, it's really tough. And
speaking of reactive, something else pops to mind. We're in an age of great
technological change, probably one of the biggest technology changes,
meaning AI, to really impact us in,
I don't know, a couple of decades maybe. And
if that's the case, what I talk about these
days is the fact that I wouldn't try to solve the AI problem because you
talk about lack of guardrails and lack of consistency and
strategy. And those things are all true, but we're really in the gold
rush days of AI. It's not going anywhere, but we really haven't figured out the
important stuff yet. And when you're in that state, the only thing that's
true, the only thing you have to figure out is the fact that it can
already do some things faster, which means people are getting
prepped around the idea that technology should work
for us quickly. Yeah, like it used to be the case
if you, I don't know, sent a request out
somewhere to a, like a SaaS system or something like that, maybe you, maybe you
don't get an answer overnight or you don't get it till the next day. And
now everyone's expecting very, very high levels of low
latency and immediacy. So one of the things that we need
to help when it comes to AI is not knowing the implementation strategy
so much as What are you going to do about the fact that people now
want things even faster than they did yesterday?
So how are all of these rapid changes in tech swarming around you
factoring into this while you wait for some of the political landscapes
to calm down and the, the moment to be right to
really— like you had said earlier, we kind of got into the
RFI process, but we had to pause it or hold it while we
work on the real burning fire bleeding neck
problems. How, how do you see those kinds of rapid changes in
tech factoring into what you're doing? Well, I definitely think
that, that they're, you know, this— the, the pace of change
right now really only increases the need to
figure out different ways to, to achieve some of this transformation and is,
is very relevant to the, the procurement innovation that I talked about that's
necessary, right? If we're locked a 6-year contract for something that was
built 6 years previously, it is just very much out
of date and something that could be done way more effectively if we had the
ability to engage something new and different quickly,
which most states currently do not have. And so, you know, being
able to take advantage of some of the capability that's coming out, it
will be a huge game changer for states. I mean,
just, I mean, just looking at the pace of software development is nuts.
I mean, not long ago, a non-developer couldn't create any software
at all. Today, a non-developer can build and maintain about any isolated
capability. And it's, you know, my prediction is, you know, we're
1 or 2 years away from enterprise-grade stuff being possible
without a huge amount of technical knowledge. I mean, of course, that's always going to
be necessary, right? But well, we're having people just having people
clickety-clacking keys to comment their code and things that even a developer
would say, I don't want to do this anymore. So fast. I mean,
the pace that it takes to develop and deploy something that's
good and high quality and works very well and can
incorporate user feedback, 'cause you can show 'em several options and
get their opinions. I mean, the pace of being able to do this with
software is just exponential right now. And
it's really amazing.
I think it's— if I'm correct about how fast
this is going, which if it stays on the trajectory it's on, I mean, we're
only a little bit of ways away from being able to create
entire Medicaid enterprise systems very rapidly
or even multiple options of those that could be
evaluated as part of transforming from what
we have today to something new. And there— you
know, a strategy like the one that Minnesota's put out is a way that, that
we could really take advantage of that, and very few are prepared to do it.
I want for people to understand better what it is you've
done. Is there a place where they can go and look at what you have
built? And, you know, you shared some videos with me, and I was really happy
to engage with some of these meetings just out of interest. Is there, is there
a place where people can go and look at all this stuff? Yeah, absolutely.
So the, the RFI content was all posted on a mural board,
which kind of steps through the videos, the documents, the feedback from all the
vendors. That's, that's, I mean, that's an easy place if someone wants to really go
deep. I mean, people can look at my website, which does have examples
of some innovative procurement contracts and RFPs that we've
put out there for feedback. And again, interested in anyone's comment
and thoughts on, on anything that's there as well. Is the
best way just to give you links and put them in the— Yes, absolutely. I'll
put them in the show notes. But what I wanted to say is that
agilists out there who are struggling with these problems, government or
not, would be really, really interested in hearing how you've managed to overcome
them. And what I like about you is that you don't pretend to have all
the answers, but you are willing to share what you
tried, what worked, and what didn't. I think that's how we learn. I think that's
how we learn best as agilists, right? Stop pretending that we're some kind
of Sherpa on the mountain and we have answers, because when you get into the
field, we often don't. And that's okay, as long as we
take to heart the principle that that failure creates an opportunity to
learn and do better. And that's the opportunity most people don't take, but you're
doing it. Any last thoughts, Kevin, about, you
know, we're in a time where the state of Agile is very much in question.
It's shifted. Agile coach, Scrum Master is no
longer necessarily even a role, but the duties
and the philosophy still remain, even if it's in fragmented
format. What is your take on that as your organization is really just
starting? With agility, a lot of other companies and practitioners are feeling,
oh, maybe this is ending. What's your take on that? Well, I
think that also comes back to some of the AI question a little
bit. And when I look at LinkedIn and a lot of the people that are
talking about the end of agile, what I'm really hearing them talk about is the
fact that roles like the Scrum Master role are no longer in
demand, things like that. And that makes total sense. Makes tons of sense
to me because, you know, I can now build an entire software product as
the user, the developer, the tester, the BA, you know, all things. And
so if a Scrum Master role was— has a
big element of it is coordinating lots of people that are going to need to
build that product, and that can all be done now by one person, that
role is much less needed. Yes. But
the principles of Agile still apply in however
this software or this environment needs to
evolve. To take advantage of technology because it's, it's
an emergent thing that we only learn once we try
something. And having a mindset where we know the answer
up front is not going to serve us well. And so however that, however that
turns into roles and things that people need to be employed doing, you know, I
think that's going to look extremely different. Yeah. But the principles
are, in my opinion, won't go away because
the, The problem still exists. You know what's interesting is one of
the crew in Forge Genesis, which is the entrepreneurial side of
what I do, was just saying the other day, all of a sudden, for reasons
I can't explain, there's like a resurgence of demand for
agile coaches. Slightly different context. It was more of a
hardware kind of implementation as opposed to pure software. But the
point is, I don't think the principles are going anywhere once we've
lifted the curtain. And said, you know, we can deliver stuff a
lot faster than we are now. And as more eyes are on speed
and ROI, a slight shift of focus on
our part towards ROI, yes, but most
importantly, not ROI in terms of your velocity
or how many more stories you can complete in a sprint compared to
last sprint. It's more about the ROI for the end user,
the stakeholder, the organization. Yep,
outcomes. Outcomes completely. But one of those outcomes in government, as you mentioned before, is
these are people needing services. They need help, right? We're not
making widgets. We're not making widgets where you can take it or leave
it. We've got a system that is put in
place to help and serve the people. And if the pace
of change raises the bar, then
we have to raise ours too. And all of a sudden people are like, oh,
maybe we shouldn't have fired all those agile coaches. I don't know, it might just
be a blip. Maybe, maybe it was just specific to his company
or this moment, but I feel like we might start seeing
a demand for some of the great things that we were a little too quick
to lay off. We threw a lot of baby out with a little bit of
bathwater. My thought. Yeah, I think it does depend on the, on the value that
those coaches bring. If there's someone that can isolate an outcome, that
can mobilize people around achieving that outcome, can show it, demonstrate
it, and expand upon it once it's, once it's there and get
people moving. Yeah, those people are employable at any
point, any time, using anything. If it's agile coaches that
are talking about how you should run Scrum ceremonies, unlikely
that those coaches, in my opinion, will continue to be employable. I
agree. Kevin, thank you so much for spending time today. I
really enjoyed just getting to know you these past couple of months and learning more
about what you're doing. I think it's fascinating. I hope you keep it
up. Any final thoughts before we close? No, I think we covered it.
Awesome. Thanks for having me, Chris. Good luck. Good luck with the initiative, man. And
thanks for making time to come on the show today. Good to see you. Thank
you. Good to see you. I hope you enjoyed that one. I've been talking to
Kevin on and off lately, and I've really enjoyed our conversations. And
most importantly, you can go and check out his work, as he mentioned, and I
put the links to those resources in the show notes below. If you'd like
to find out more, check him out at
worldwideweb.si.
Delivery.com. I think this stuff is the future of Agile, where the badge
doesn't matter, but the work that we do and the change that we make and
the value that it delivers still lives on and burns
bright. My friend, thank you for joining. I look forward to seeing you next time,
and until then, stay badass.