Creating the Conditions for Sustainable Change

Every time you patch a problem instead of solving what causes it, your business gets weaker.

VIDEO TRANSCRIPT

Mike Cottmeyer

I’d be curious from your point of view, nobody adopts agile for the sake of adopting agile. Nobody goes through digital transformation for the sake of digital transformation. From your point of view as a CIO, Len, what problems are people trying to solve where they might have a hypothesis that doing something in the agile space is going to solve it for ’em?

Len Greski

Well, there are categories of problems that are related to product development. There are categories of problems that are related to production operations and running the IT shop. And then there are categories of problems of delivering on a company strategy. And any of these may be jumping off points for the kinds of improvements that are enabled by agility. So in the product development or application development space, the only thing senior executives agree on is that software development is too slow, it’s too buggy and too expensive,

Which is why CIOs and CTOs are often in the position of being blamed for why the company’s not hitting its sales goals. And the first thing that you have to do is become predictable. And then when you become predictable, you can begin starting to take out waste. And then as you take out waste then and improve quality, then you can begin to reduce delivery times. And then in the operating space, in many organizations that they have frequent production outages, they solve symptoms as opposed to root causes. They’re in reactionary mode as opposed to proactive. And their technologies are sort of disconnected from the front office where the front office may be very rigorously managed in terms of a conversion funnel. But those conversion funnel stats don’t seem to make it into the IT shop to predict when growth in the business is going to cause problems in the production infrastructure. And then finally relating the strategy execution is that many technology organizations don’t understand the business strategy well enough to know which specific technical capabilities need to be best in class versus which ones can just be industry standard and use commercial off the shelf software. And all of these can be addressed through various approaches to improving agility, starting with systems first. Because if you pit good people against the bad system, the system almost always wins.

Mike Cottmeyer

Yeah, it’s interesting. Okay, so there’s a couple threads I want to pull with you there. One of the things that I think is fascinating is that when I feel like we’re going old school here and it’s super cool, one of the things it’s like people say, I want agility. So then they go to I want Agile, and then they hop to I want Scrum. And I can’t tell you I have at least three different client contacts over the last few months where somebody is trying to implement Scrum in an operations framework. And I’m going to bias your response a little bit. I think there’s some things in IT operations, especially maybe smaller IT operations, but maybe larger ones too, where the idea of complete cross-functional teams backlogs delivering something of working tested value every two weeks. What I see is that there’s more specialization at the individual level and I see that there’s a lot of interrupt driven work in the system. So talk to me a little bit maybe what leads to the mentality that agility equals agile equals scrum and what are some of the pitfalls of seeing it that way and not taking a more broader approach?

Len Greski

Well, as I’ve worked with a variety of companies as a leader in a company and clients as a consultant, it really boils down to planned versus unplanned work.

And what’s the best approach to manage planned work versus the approaches to managing unplanned. And if you use the wrong approach. So if you manage unplanned work, it’s basically interrupt driven on a, you’re getting work in that comes as small requests that can be handled in minutes or hours rather than days. The best approach to handling that is probably Kanban, not Scrum, because you don’t need all the overhead. And as we talk with our clients, we talk about you use the minimum amount of rigor that is necessary to deliver the results you need and manage the risk and interrupt driven basic requests. Those organizations are more like work groups than multidisciplinary teams. So if you’re just managing a pool of call center or first line responders in your operations center, you probably aren’t managing a lot of planned work and therefore you don’t need the overhead of something like a scrum.

Mike Cottmeyer

Yeah. So I think somebody who is steeped in Scrum might say, but Len, Scrum has the ability to introduce new work. The product owner brings it to the sprint planning meeting. What’s different about an operations team that makes that kind of two week or even one week planning cycle somewhat untenable?

Len Greski

Well, often these are requests that can be handled in minutes or hours, and they just don’t need the rigor of stories and acceptance criteria and prioritization in a backlog. And if you don’t need the overhead, it doesn’t add value.

Mike Cottmeyer

Well, I start to think about the ideas of classes of service in Kanban and certain things can’t wait two weeks. You have an outage, you have a critical client request that has to come in and interrupt the system.

Len Greski

Those are additional scenarios where a bound approach is going to be more effective than Scrum. Yes.

Mike Cottmeyer

Let’s pull a thread. So one of the things that sometimes we’ll talk about in the agile world is the idea that you have build run teams in the sense that the team that builds the software should support the software inherently in that you end up mixing work that needs to be predictable with work that’s inherently variable. What strategies have you seen implemented for either buffering or segmenting the planned work from the unplanned work?

Len Greski

Well, some of ’em are, you create teams that specific teams to handle the planned work and teams to handle the unplanned work, and then they work within the same product team. And since the product team is going to be managing multiple delivery teams, you can segregate the planned from the unplanned work and allow the unplanned work to come in on a queue. And then as you notice patterns in the unplanned work that suggest the need for planned improvements, then you can identify new features and run them through the planned process and augment the business in a planned way.

Mike Cottmeyer

Okay. So you’re working on a client with us right now that we’ve done something that we do occasionally, but we don’t do a lot of where you’re performing an interim CIO role for them. And what’s interesting is that it’s created some synergies from what I can tell. So we have basically the CIO in place and dealing with the back office and the infrastructure and such like that, but we’re also doing what you might call a legacy modernization project as well for this particular client. Tell me a little bit, now that we have both sides of the equation in one engagement, what have been some of the benefits of having the CIO organization integrated with the modernization extraction strategy that we’re implementing there?

Len Greski

Well, I think that there are at least two or three categories of benefits. One is focusing on making the legacy system stable, reduces distractions for the modernization team. The second is agreement alignment on the priorities reduces the degree to which the modernization team members get cannibalized on the legacy development labor and impacting deliverables in the modernization. And then the third thing is what I would call software archeology of finding things that are not obvious that are either limits or potential broken areas of brokenness that need to be made visible to the modernization team.

Mike Cottmeyer

Give me a couple four examples of that.

Len Greski

So, for example, there’s, well, without getting too much into the details, businesses often have multiple versions of multiple ways to do a particular activity within an application that create inconsistent results. And one common area is tax handling. There is an application that I was involved in where the underlying software could calculate taxes in half a dozen different ways, and if the teams building new software aren’t aware of that, then they could either miss scenarios that they need to cover in the new system or they could build things that don’t work in the downstream processes. For example, integrating a front office application with the financing controls software in an ERP.

Mike Cottmeyer

Okay. So what advice, if you had a CIO that had this dual responsibility legacy applications, infrastructure ERP and some front office modernization going on, what kinds of things, what advice might you have for that CIO?

Len Greski

I think one would be to allocate specific staff to the modernization and have the discipline to not pull them back into legacy work. And it’s really hard because often the people that you want to put in the modernization effort are your subject matter experts on your legacy systems. And then it’s hard to have the self-discipline to reduce work in the legacy systems.

Mike Cottmeyer

Yeah, it almost seems like it’s a special case of what we were talking about before. You have variable work that is having to interleave with project work, and when you pull one for the other, you end up destabilizing the big business strategic thing that you need to be able to get done. 

Len Greski

Then another thing would be to figure out to the degree that you can, how to document the operational procedures for your key legacy systems so that you can expand the pool of team members who can solve problems without accessing your subject matter experts. And a lot of this is just really basic stuff like the security mechanisms and the user ID information about how you install and start up and restart your applications, the vendor contacts for the vendors whose software is included in your applications so that you can reduce the cycle time when an incident occurs for getting it mitigated

And then another area is to get really aggressive about root causes to production problems. Many organizations that either that I’ve either led or served as a consultant, they do not solve the root problems when they have production incidents, they medicate symptoms and getting to the root causes allows you to permanently solve problems and reduce the probability that they’ll recur, which then frees up labor to do more valuable stuff.