In this episode of SoundNotes, our two in-house CSTs get together to talk about the importance of sprint goals. They dive into everything from what they are, why they’re important, and how to go about creating them—even in the absence of an explicit business goal.

Want to Listen Instead?

Contacting Vic Bonacci

If you’d like to contact Vic you can reach him at:

LeadingAgile: https://www.leadingagile.com/guides/victor-bonacci
LinkedIn: https://www.linkedin.com/in/vbonacci/
Email: Victor.Bonacci@leadingagile.com

Contacting Dave Prior

If you’d like to contact Dave, you can reach him at:

LeadingAgile: www.leadingagile.com/guides/dave-prior/
LinkedIn: www.linkedin.com/in/mrsungo
Twitter: twitter.com/mrsungo
Email: dave.prior@leadingagile.com

If you have a question you’d like to submit for an upcoming podcast, please send them to dave.prior@leadingagile.com

Interested in CSM or CSPO Training?
You can find all the details at www.leadingagile.com/scrum-training/

Andrew Young comes from a strong product background and is considered our resident expert on OKRs and KPIs. Today, Mike Cottmeyer sits down with Andrew to discuss how LeadingAgile is talking about OKRs and KPIs, the impact governance and teaming strategies have on your ability to run them effectively, why your project mentality might be getting in the way, and how you can get started using them in your business.

Video Transcript

I’ve got a client that I’ve been recently working with, and for them, they feel that organizationally they have not invested into the employee experience and employee happiness. And of their top 10 OKRs right now, three of them are all somewhat centered around or adjacency to around employee experience in an employee workplace and employee effort score. And so they’re really signaling to the employee front. We know that we’ve been short on this for the past four or five years. This is where our attention is going. Clearly there’s still two or three around market penetration where they need to go and revenue targets and those things, but they’re spending 33% of their top level strategic objectives on internal employees. They really want that story to come through. And so you see the KPIs have shifted a variety of things. Now you can argue if that’s the right or wrong strategy. OKRs are not declaring that your strategy is good or bad. It’s just a way for you to articulate to the organization where you want your strategy to go.

(Musical Interlude)

Creating Clarity Around OKRs and KPIs

Mike Cottmeyer

Okay, everybody, welcome. We’re going to do something a little bit different today. Normally I get on these videos and do a little bit of the talking head stuff about things that I consider myself a domain expert in, but we were having a conversation with my leadership team a couple of weeks ago around the idea of OKRs KPIs. I talk about those things thematically quite a bit when I’m on client sites or in a sales call, or maybe even in an onstage presentation or something. But it’s not something that I consider myself like a really deep expert in. So I brought Andrew Young onto the call with us today. Andrew is one of our advisor level consultancies that’s on my leadership team. Helps me go out and set up new accounts and set strategic direction on the different accounts that we have. And so today, Andrew and I are going to have a conversation around OKRs and KPIs. Hey Andrew, how are you doing, man?

Andrew Young

Well, Mike, great to chat.

Mike Cottmeyer

Thanks for joining me today. I really appreciate it.

Andrew Young

Yeah, of course. It’s a fun topic.

Mike Cottmeyer

Yeah. Well, so tell me a little bit about your background. And I don’t, maybe passionate isn’t the right word, but how did you come to develop an appreciation for this topic?

Andrew Young

Yeah, I’m a little bit maybe more of an outlier than some of our other consultants. I’ve got a design and a product background, and you’ve heard me say this, and I’ve said this publicly on stage before that I think that the first product and the first artifact that an organization’s responsible for putting into the world is their teams and the way teams operate. And you can assess a lot of an organization by how they structure their teams, how they talk about it, and most importantly, how they drive alignment. And so if I just apply my design background and my design thinking background, how we create safety and space for teams is really important. And I think that there’s a lot of popularity coming back into right now around team, team, autonomy, all stuff. We’ve talked about, the persistent ness of teams, but there’s new flavors and new attributions, and there’s a lot of momentum around these things. And so I got really curious at just like what is the uniqueness and difference in it? And lo and behold, most of it’s the same stuff we’ve seen just packaged differently. But there is some nuance and some flavors of stuff that deeply aligns with leading agile. And so that intersection, Mike, has been really interesting for me for the past four or five years.

Mike Cottmeyer

One of the things that you brought up as we were preparing for this talk was the idea of teams and teams autonomy as it relates to OKRs and KPIs. That’s something I want to explore with you in a minute. But before we go too deep into that, why don’t you bring us up to speed on maybe what an OKR is, what a KPI is, how are they the same? How are they different? What are your thoughts on that?

Andrew Young

Yeah, we’ve recently had a large inbound question around OKRs. What are they? How are they different? And what really is this thing? At the end of the day, I think we can overgeneralize OKRs. It’s just another goal setting framework if I subordinate it. But the power in OKRs is creating space for hypothesis. So it could be similar to a project plan, but I want to make sure that we don’t call it a project plan. An OKR becomes an objective and just as we do with our teams backlogs at the team level, there’s just a stack rank of these objectives, a thing we need to actualize an opportunity, we can capitalize on a place we need to go. So it’s an objective. And then there’s key results along the way, and the difference between the KR piece of OKRs and a lot of the other goal setting frameworks. These aren’t output milestones. So they’re not just project leads, they’re not delivered this service at a certain time. It’s what impact on the business doesn’t make. So our key result says we expect to see a shift in X, Y, and Z. So key results unlikely hire five people or unlikely deliver the new CRM on certain day. But the key result is that team members or the activities needed with that CRM can now be deployed and they can use it. And we’ve created efficiencies or CIE or optionality.

Mike Cottmeyer

So I’m going to take a little bit of a risk here, but one of the hallmarks of our methodology that if people have been following our approach for a while, we talk about the idea of expeditions moving to base camps up underneath that we have a notional idea of an outcomes, outcomes-based plan where every two or three weeks through the course of engagement, we want something of tangible value being delivered. Is there a parallel there in an OKR? Is that what you mean is almost like a work package and a traditional P M I project plan, something that has value, something has economic value?

Andrew Young

Yeah, I think there’s a lot of overlap, Mike, in the way that we have internally used the branding of outcomes-based plans. I would assume if there was an overlap between an OKR and an outcomes-based plan, the OKR, the O of the OKR is the equivalent of the headline. We give a chunk of the outcomes based plan. So objective form teams, outcomes-based plan form teams, both of those could carry the objective title. And I would assume that those major cluster of activities that we do, or what we call plays or events inside of our outcomes-based plans would be the pieces of the key results story. But they wouldn’t actually be the headline of the key results. The headline would be what they can do now that play or that activity or that event has occurred. What new, I don’t necessarily want to call it a capability because I don’t want to index of the word capability, but what new behavior or capability outcome has been emerged because of that. I think that’s super true.

Mike Cottmeyer

Yeah, it’s crazy how it’s so easy to overload all the words that we’ve got going on here.

Andrew Young

One we didn’t clarify is what’s the difference with the KPI? And so I think this is the fascinating one for me, that when I’m with teams and with leaders, everybody understands what an indicator is, right? You say KPI, oh yeah, I’ve got it. I’m a seasoned career professional. I know what indicators are. I think that the piece that falls apart is people mix up a metric, something you can measure with a KPI, something that’s the most important thing to pay attention to. And so we use that language. KPIs are the indicators that help us understand how our business or our department or our team is performing. Some of them might be output metrics, but we want to continually operate them as much as possible as outcome metrics. So customer satisfaction, customer retention, customer behaviors. We get into the nuance of leading and legging indicators at different parts of the organization.

They’re going to feel more legging. The higher up you go in the organization, those KPIs are more legging revenue forecast versus actual, those types of things. But what happens? And so getting people aligned with, oh yeah, the things you can measure that are important are KPIs is not the hard part. The hard part is helping teams and organizations understand when your KPI list is a manifest of 10,000 KPIs, are you actually able to pay attention meaningfully to any of them and respond to them? What we see with teams is they put future project changes or future desires as a part of a KPI, and maybe that’s an aspirational state you want to get to, but the work to change our organization to where it wants to be tomorrow, that’s objective work. KPIs for us are really focused on what does it take to operate the business?

And we advocate for a language that says a KPI has a healthy value. And so if we use weight, I think this is a really good one. If you take it to your personal life, then a KPI, we all fluctuate in weight. I know what my healthy range is. I want to be between 185 and 195, and if I’m in there, I don’t really pay attention to it much. I just kind of know that I’m performing where I need to. But as soon as I cross the 1 95 threshold, it goes yellow. Hey, you’re kind of at that outer skirt of where you want to be. You’ve broken past the healthy value. You might want to start being more sensitive to your behaviors. And then at some point, we’ll call it two oh five, two ten, you say that’s the red value. As soon as I hit that, I need to take urgent and reactive behavior shifts in my status quo. And so we talk about those as traffic lights, red, green, yellow with KPIs. And I think that’s what’s missing for a lot of people. If they can’t identify the red, green, yellow, the healthy, the slightly unhealthy, and then we need to react values. They just have a metric. They just have something they’re measuring and they’re not actually using it to make daily decisions. That’s what we’re really focused on with the KPIs is can you identify a small subset of metrics that are super important to the near term performance and health of the organization?

Mike Cottmeyer

So you characterized the idea of a KPI as being almost like in the realm of keeping the lights on. So to use your analogy, day to day, just going about my business, living my life, then use example weight. Weight gets in a certain range. I’m not paying aton attention to it outside. I have a caution indicator hits red. I have to take drastic action. So if KPIs are like to keep the lights on and how we’re measuring the performance of the organization, giving an analogy for the OKR, would that be an intervention something that we want to do, or is it like, Hey, I want to go pay attention to my metabolic health and my blood work or something like that? Mean?

Andrew Young

Yeah, it could be both. We tend to think about the OKRs as two patterns. I’ve got a KPI that has once turned red, but I was quickly able to get it back to green again, kind of ignored it. But if I have a KPI that’s habitually performing yellow, red, you use the word intervention. That might be a good word here. We need to change what we’re doing. We might need to invest new approaches, new workflows, new people even to that, keep the lights on shift. And so recovering KPIs could be objective work. You have a red that’s habitually red, intervene with it, change the team, change the investment, change the processes of tool. All of that’s a reasonable thing. But then you also have the other one. If we stay at the personal level, let’s say weight is something that I pay attention to.

It’s my keep the lights on thing. And let’s say I have been an avid basketball player my whole life. I play pickleball every weekend, don’t really care about it, but with my weight, I’ve noticed I have an interest or there’s an opportunity in this whole pickleball movement that’s coming up. So everybody’s playing pickleball, but I’ve never done it. And so that’s a new thing for us. But my weights in check weight’s not my limitation. So my KPIs are performing well, but I need to go learn this new thing or we need a new capability. I’ve never picked up a paddle or a racket sport. And so an objective might be become a amateur pickleball player or at least win my local clubs pickleball tournament championship. Underneath that. There’s a whole bunch of work I have to do. I have to build some establishing capabilities. I need to do some repetition on practice.

I probably need to figure out where to go and do all this stuff. And at some point I might turn that into a KPI. Once I’ve learned pickleball and I’m playing on a regular basis, I might have some sort of KPI around my pickleball performance to figure out if I need another intervention or not. But it’s a new thing. And so objectives can be innovation. If I throw that word in there and I think about our world, I assume some of our objectives in K o work would go to a Basecamp five innovation team. Those are the horizon three type things. But there’s also just things we know on the horizon that will make our organization better, that are different than the way it’s operating today. And that’s also objective work. And so major shifts in tool or services could all be objective work.

Mike Cottmeyer

You want to have some fun with me for just a minute? Yeah. So your ski instructor? Yeah, past life. So I learned how to ski three years ago. I started skiing when I was 50. So that in your analogy is that was a new outcome that I wanted in my life. So now that I know how to ski, what would be a KPI? Help me think about, yeah,

Andrew Young

So there’s a whole bunch of fun ways we could think about this. It all gets into the where do you want to take it. So what is the vision? If I try to stay loosely aligned to a company, what’s the vision of Mike as a skier? Is it Mike wants to be an all mountain skier or Mike wants to do those half pipes and all the flips and tricks, two different flavors. All mountain. All mountain,

Mike Cottmeyer

Mountain, different conditions.

Andrew Young

So, Mike’s got an all-mountain different condition approach, and so probably a KPI that’s just reasonable to pay attention to is how many days are you getting out in the season or a month, right? So there’s an output thing. We talked about some output still early in your career. Mike, I think was skiing. So I might throw in a KPI. How many times have you fallen off the chairlift? That might be an indicator. We need to go back to basics on some things, but we need some of those super safe green KPIs. It also might be just a ratio. How many times did Mike in the late afternoon after lunch choose to take the green rundown versus challenge himself through a tree run? So there might be some sort of ratio of post-lunch behaviors because we know Mike gets lazy after lunch.

Or maybe there’s a pre-lunch. You don’t warm up and therefore you’re constantly finding yourself in too much fatigue and hurt. So maybe we actually put a KPI in that. When is the average first black run of the day? Is it your first run, your second run, your third run, and we set healthy targets for those things, all things that will incrementally get you better, but towards your objective. Yeah, you check the box, you can label yourself as a skier. Now your next objective is an all mountain skier, and so maybe your next objective is how do I ski outside of a groomed or patrolled run? How do I get into your next objective? Might be my first back country ski or your first heli ski. And so we’ll have some things we have to work up into. So you’ve got your KPI showing you on a daily basis, but one of the things in that new OKR or the new objective, and here’s some key results.

Mike has successfully completed 10 trips down a side run at a resort. So you took the chairlift up, but you might’ve done side trips, so that might be a milestone. Your other milestone, Mike, I don’t even know if you know this yet. Most people who are backcountry on mountain skiing, they don’t have chairlifts. So do you even know how to walk up a mountain and skis? So maybe that’s a key result. Mike knows how to go up the mountain on a skis. He only knows the skis go down the mountain. Things that we’re adding to the future world all shifts kind of in the same domain, but you’ve never gone up a mountain on ski. So how could I have a KPI for you yet? You got to establish that learning.

Mike Cottmeyer

Okay, that was a fun diversion. Thank you for that. I appreciate it. Now you’ve given me a whole new set of things to think about in December when I did my first trip out to Colorado.

Andrew Young

That’s right. I think the simplest K P I is how many pairs of skis do you have? Right? Because all mountain skiers have multiple skis. So if you only got one, might need something else.

The Role of Governance in OKRs and KPIs

Mike Cottmeyer

Yeah. Okay, cool. So let’s get back. That was awesome. Thank you. So we were talking about, right, so leading Agile is really in the encapsulation orchestration business. If you think about it, the change management business, taking big things, breaking them into small things. I think about that a lot. One of the things we were discussing was the idea of teaming strategies and ownership and things like that. So talk to me a little bit about why OKRs and KPIs are so important in the agile transformation space and why are teaming strategies and governance models so important to the successful articulation and execution of these metrics?

Andrew Young

Yeah, I think this is probably the biggest invisible part of the conversation right now. So I’m going to meander for a second. I’m going to drop through four topics and then tie them back. There’s been a lot of dialogue and traction and movement around where OKRs are developed and in the world today, there’s a couple of schools of thought, right? There’s the whole, they were created at the top. You decompose them, you tell the team below what their new objective is and then that gets decomposed and you tell. So this story of hierarchical telling is an objective approach. There’s some schools of thought out there that says start at the lowest level, the organization, the things closest to the team members or the customers they know, have them build objectives, and then you aggregate them back up to tell a big story. So there’s risk in both of those approaches.

If you only take the top-down approach, you’re missing a lot of the feedback loops. And we talk a lot about feedback loops. So we can build in some compensating controls, but at a certain point, if it’s just one direction, your feedback loops are weak. But if you start with the teams and let them develop it, we’ve found, and it’s time and time again, it’s not always aligned work. And what we’re trying to do and what the world is trying to do with OKRs is not to be prescriptive with what’s to do, but give outcome oriented alignment framework, tools, statements, methods to teams so that they could drive it.

Mike Cottmeyer

So the idea is that maybe the organization sets the outside boundaries and then as you cascade that intent, the lower levels or teams get to decide how to implement within that boundary is

Andrew Young

Yeah, that’s close. We definitely use those languages. And the misinterpretation though that I could hear in what you said or possibly hear is as you get lower, we’re not getting any more prescriptive. We’re tightening the guardrails of where you can play, but we’re still creating opportunity statements for teams with the objective. The objective is to actualize on this. It’s not to deliver the CRM if the new CRM is the most critical thing, sure, we need to be prescriptive about it, but the more we can write these things as the outcome of the new CRM and have the team own that,

that team fills to ownership of the work. And then it also allows to where you started the orchestration to occur because one downstream risk and problem with OKRs where teams are allowed to establish them and they create them from the ground from the closest to the customer up is there’s a lot of duplication and there’s a lot of waste because you’ve given teams this autonomy and they’re getting to make decisions and move quickly and swiftly, but at the cost of low orchestration, at the cost of duplication, at the cost of not having all the right information. And so what we’re trying to create with the OKR framework, and this is the enhancement in shifting that maybe some literature right now is a little soft on, is as it relates to transformation, as it relates to change, as it relates to healthy systems of delivery, we want OKRs to be the guardrails you called it out.

We want them to be able to talk about opportunity within constraints, but we also want them to be so that teams know where to get other information and how to cross-functionally work. We’re not trying to create siloed departments with this. We’re not trying to create siloed functional projects. We’re trying to get, if the objective is for Mike to go skiing and be the best allbound skier, your wife probably has some work in there and how she’s going to support you. Your kids have some work, your ski instructor has some work. It’s not just about Mike and his silo of myness, right? It’s the other things that need to come together in those key results that emerge. It also gets into this notion of, one of the things we talk about Mike is backlogs, and this is just a backlog at the highest abstraction of objectives should be treated like a backlog.

Now, you’ll run some in parallel because you’re servicing a whole organization, but we’re not trying to identify that there’s 85 number one priorities and 85 number one objectives. Common failure pattern we see is too many objectives. And so what we’re trying to get the leadership teams to understand is this is their backlog, this is their backlog, and your objective might be an agile operating model that might be an OKR. You guys are project oriented and burning a lot of it, and maybe your largest outcome and objective is a better way of working. It also might be we need to shift into this new market because the market is completely changing and might need to be that we need to exploit our cash cow. All of those are reasonable objectives from an investment lens, from a top level of the organization, and we teach that you stack rank OKRs, they need to be stack ranked and there’s relativity in them.

And at some point you can’t invest in everything. And what we really want to teach is the same way we teach the delivery teams or product teams or portfolio teams. You got to make a trade-off decision. It’s your trade-off decision because you don’t have enough resources or because of orchestration costs or because of a lack of clarity. What we’re trying to do, and this is something when I’m coaching all this, I talk about OKRs and KPIs being just a storytelling moniker. It’s the way the organization is telling a story. The number one objective right now is this. The second most important strategic objective is this. It should signal to the organization where we’re going, our KPIs, we’re paying attention to these things. This should be the narrative. Hey everybody, this is what’s up here. I’ve got a client that I’ve been recently working with, and for them, they feel that organizationally they have not invested into the employee experience and employee happiness.

And of their top 10 OKRs right now, three of them are all somewhat centered around or adjacency around employee experience in an employee workplace and employee effort score. And so they’re really signaling to the employee front. We know that we’ve been short on this for the past four or five years. This is where our attention is going. Clearly there’s still two or three around market penetration where they need to go and revenue targets and those things, but they’re spending 33% of their top level strategic objectives on internal employees. They really want that story to come through. And so you see their KPIs have shifted a variety of things. Now you can argue if that’s the right or wrong strategy. OKRs are not declaring that your strategy is good or bad. It’s just a way for you to articulate to the organization where you want your strategy to go.

Mike Cottmeyer

So a lot of times when we’re thinking about system of delivery within the leading agile, large scale, agile operating model stuff, we tend to think in tiers, right? There’s the team level execution tier, there’s a program or product tier, there’s a portfolio tier. And so what I’m hearing you say is that at the top level really OKRs in KPIs or an investment tier token moving through a combine, something like that.

Andrew Young

Yeah, that’s right. I guess it’s implicit. When I say stack rank, it means that something’s going to move because it can only be in a state and only so many things. So yeah, this is for me in our model, the top tier and at risk of getting a little messy for a second, if we say it’s a four tier system, the three tiers you just said, the system of delivery and the system of delivery is putting, working, tested stuff to customers and users, the difference is at this top tier, we’re starting to blend where hopefully a lot of the objective work is trickling into the system of delivery. We want that to be there, but there’s some other work that’s being invested into at that top tier that we need to represent that doesn’t end up being visible or aware to our client’s customers.

Mike Cottmeyer

What I was hearing, this is kind of where I was heading with the question. It’s almost like there’s a little bit of an in the system, on the system kind of angle. There’s things that we’re doing to the product that would be first order concerns, epics features, user stories kind of a thing. What I’m hearing you say is that there’s room for on the system, OKRs, KPIs. Absolutely. So in all world, would that be like system of transformation work?

Andrew Young

Absolutely would be. And I think it’s probably the biggest missed opportunity for some organizations implementing OKRs. They make it just about the stuff that’s in the system of delivery and they forget that they still investing hundreds or millions of dollars over here on what you just called system of transformation. So this could be coaching services, this could be investment into communities of practice or guilds. This could be as complex with some of our clients of we need a whole change management office or some of our clients and some organizations maybe have never invested in their internal communications capability, not something the customers of that organization will ever see, but it is still taking a large investment. We need to reflect that as an investment token as well. So all of that gets put into that top tier for us.

Mike Cottmeyer

Interesting. Yeah. I’m kind of riffing thinking out loud a little bit for everybody listening to this. One of the things that we talk about internally quite a bit and language leaks out probably needs to be a little bit more explicit. We talk about like when we think about agile is scale as a system of delivery. It’s like how do we run the software factory or the product factory, for lack of a better word, but we distinguish the idea of system of transformation, system of continuous improvement, system of engagement, and it gives us an internal pattern language for really distinguishing things that often get blended. And so I guess just to geek out for a minute, it’s almost like there’s system, there’s OKRs for the system of delivery that feed the system of delivery. Epics features user stories. There could be system of transformation, OKRs, KPIs. There could be system of continuous improvement, OKRs, KPIs. That’s fascinating. Okay, cool.

Andrew Young

So, there could be, the only risk though, Mike in the way that I heard you just present it. So I’m going to regurgitate back because I wouldn’t classify that. I wouldn’t classify them and say, I need so system of transformation OKRs and I need system of delivery OKRs and I need systems. What I would do is, and the way we coach this when we’re implementing it, is what’s the biggest gap in the organization that occurs today and we don’t have a product in this market or we’re failing it effective delivery, therefore we need to go through this transformation at the O K R level. Those are all interchangeable and where they stack rank. And so we’re going to create this apples and bananas and monkeys prioritization model that normally doesn’t get stacked ranked together, but we’re forcing the organization to say, what we need to invest in is our delivery capability or our research capability, or this product is just underperforming and we’re losing customers because they’re going to our competitor at the top tier of our system.

We’re going to stack rank them and then we might want to attribute them so that you at least look at the ratio. So not all of our objectives are system of transformation. If you had all of your top 10 objectives as system of transformation, you’re signaling to the organization, we’re kind of falling apart and we got to get our house in order, or you’re signaling our product’s so amazing in market that we don’t actually need to pay attention to it. I don’t know that any of our clients have ever said that. And so we do need the attribution, and I would love to see the ratio, like 70% of stuff at the OKR level is going to trickle into the system of delivery. But that’s not a steadfast rule. But what I do see other companies do is put 100% of their objectives for system of delivery stuff and forget, and then it gets devalued and then it forgets never invested in. And this is why a lot of organizations that are playing with OKRs right now end up with two classes of OKRs. These are the OKRs for our products. These are the OKRs for organization. And I would just challenge why the separation if it really is your investment strategy.

Mike Cottmeyer

What I’m really hearing about is it’s a common queue, right? Because we’re all taking organizational capacity, so it’s like we just have to decide how they prioritize against each other.

Andrew Young

And I think that’s one of the biggest values as we’ve coached leaders through this is what you just said is it’s a common queue. It takes money, it takes people, it takes time. And if you put all your money, your time and your people into building the next product, including your SVPs and your executives, you’re never going to invest into your organization, and you need some of that blended story.

The Importance of Teaming Strategies for Effective OKRs and KPIs

Mike Cottmeyer

So, I don’t know if we got to a final place on this, but why is the organizational design, the teaming strategies so important for effective OKR satisfaction or KPI satisfaction? We were talking a little bit about is it an orchestration problem? Is it a clarity of purpose problem? Is it an ownership problem? Explore that. Just one click down for me if you wouldn’t mind.

Andrew Young

Yeah. Yeah. And I’ll start with the last one. I think it starts with an ownership problem. If you don’t have effective team and teaming structures or persistent natures, this OKR world can divulge into all teams get to create whatever they want, and then there’s many instances of a thing versus going to the sanctioned thing that exists and talking about it with the team that’s responsible for owning that and enhancing and advancing that. So persistent teams important to understand where the objective will most densely be concentrated around teams versus team members having to go find, learn, and reinvent those things.

Mike Cottmeyer

Okay, I think I got it. I think I can tie it back to what you’re saying because normally when we think about teaming strategies in an organization where typically we roughly use the metaphor of a business capability, and so we organize teams and technology people process around these business capabilities that ultimately get decoupled from the rest of the organization can operate autonomously or independently. So what I’m hearing you say is that if I cascade an OKR into a capability, it’s very clear that that capability is owned by that team. If I cascade an OKR out into an organization isn’t capability aligned, I might get duplication of capabilities because ownership isn’t super clear around it.

Andrew Young

That’s right. And then I’m going to Yes, and that, yeah, cool. When you don’t have teams that have domain ownership, and so now I’m going to go even larger than just delivery, the concept of winning in a new market isn’t just building a good product, it also is inclusive of the go-to market. It’s inclusive of the sales, it’s inclusive of the customer support. And so that’s a highly cross-functional domain that’s now needed to participate in this objective. The objective isn’t authored at go deliver new product, it’s go deliver new product the customers love and are successful against. And so the other purpose of the teaming as it relates to OKRs is you get the right representation from the different functional domains so that you can do something truly cross-functional because we’re trying to write every objective as a cross-functional outcome, not as a functional delivery.

And so if you don’t have persistent and a clean or at least aware teaming structure, I could see teams trying to go do all of that. We built the product, we’re going to do the go to market, we’re going to sell it. It’s such a small team responsible for something that they’re probably not capable of doing or it becomes over the wall. We built it, now you guys sell it, you guys sold it, now you guys support it. And we don’t actually have that true outcome oriented mindset. It moves back to more of an output by function.

How Project Mentality Gets in the Way of OKRs and KPIs

Mike Cottmeyer

Okay, cool. Probably related, but we talked a little bit about the idea of project-based work versus product-based work, and you were telling me that the idea of project-based funding sometimes gets in the way or maybe a project mentality gets in the way of effective OKR implementation. Talk to me a little bit about that and tell me why projects can sometimes be a problem for us.

Andrew Young

Yeah, I think it’s actually the largest limitation in mindset for people to feel comfortable with this OKR stuff. What I hear, I’m going to tell you, the fable is, oh, we have to deliver this thing where also our company’s going to fall apart new institutional tool, new CRM platform, whatever. It’s cool. I don’t know that I disagree with that, but just delivering the thing isn’t yielding the right answer. A lot of the times when we see project bound funding our project bound prioritization, we see two things come out of that. Here’s the scope, you’re going to deliver all of it, and we don’t give you an option to change that over time. And OKRs are a hypothesis driven with what we know now, here’s where we’re going, here’s what the key results look like, tell you with the OKR framework, it should be pretty common that the original envisionment shrinks over time as you learn because hopefully you’re in a divergent moment when you offer that OKR, you’re kind of boiling the ocean and over time you’re converging into the right cone of uncertainty vector. And so project-based funding typically doesn’t support that. If I think about it, it’s the

 Mike Cottmeyer

A lot of times I think of a project as like a token in an investment portfolio or something that moves through a Kanban, right? Is it that the conceptualization of a project as time cost and scope, so it has an expected investment, an expected duration, and a specific set of things that we’re going to go do. It’s almost like the hypothesize, the hypothesis has already been translated into requirements. That’s right. And what we’d like to do is to delegate intent rather than a set of things to go do or go build.

Andrew Young

That’s exactly right. The project, and let’s say the project and your narrative, there was a two year long project. It’s fixed time, fixed scope. We know how many people, we know the requirements for that same, I’ll call it outcome over two years with OKRs. The way that we would coach that is what’s your outcome? What are your key results? And do you want to invest into this? And every quarter or every six months, we’re going to ask the same question. Is this still the number one premise opportunity thing to capitalize on that we want to invest into and do we have the right makeup of the investment? And that might ebb and flow because of other things that occur. We want to create that optionality within the construct of the project where a lot of project prefixed time scope requirements just don’t allow for that.

The second thing maybe with projects is you have a dedicated group of people focused on that project, and it’s less likely, I think this is my premise, that they then take ownership of that thing and then are persistent with whatever that thing is. OKR is trying to create autonomy for that team to say, look, we built the thing cross-functionally or functionally, it’s ours. We retain it. We have delivered it from an OKR lens. Here’s the KPIs now to showcase that it’s still healthy and happy and we’re responsible for it. So we took it from the envisionment to the operationalization of it, and it’s within a contained group of people. Now, you might rotate people in and out of that team, and that team might change over time, but in concepts where from a teaming structure where the center of that gravity lives,

Mike Cottmeyer

It’s really fascinating, man. Like I think you alluded to this earlier, but it’s all fundamentally the same concept. It’s like the difference between a user story and a requirement. If you go back to just the earliest agile, the most basic agile concepts, user story was a placeholder for a conversation. I’ve got a customer, I have some capability or function I’d like to have in the app, and this is how I know it’s done. And the team collaborates on an ongoing basis with the product owner or the customer, whatever the actual thing that gets built is emergent. It almost seems like KPIs and OKRs are almost like investment tier, organizational level user stories. You could almost take that conceptualization. Am I thinking about it the wrong way?

Andrew Young

Yeah, I’m not going to say almost. I’m going to say it’s, and so I’ve got a smirk smile on my face here because I don’t come from the agile background. I came from the design, the product side. So leading agile was my grand reveal in the foray into the agile stuff. And I’m going to make an unpopular opinion claim here because of my background. I’m going to claim OKRs. And what you just said is the rest of the world adopting all of those things that the agile movement was trying to create, and it got maybe constrained into system of delivery software, IT delivery. I think this is just, and I’ll quote the business or the other side of the house or the other parts of the organization who don’t have a relationship getting caught up with those beliefs, and I’m with you. It’s just the same patterns of belief branded or story told underneath the moniker of OKRs and KPIs, but it’s trying to create optionality. It’s trying to create alignment. It’s trying to create hypotheses. It’s trying to move tokens across the board. I am with you on that, an objective and okr, do we want to invest in it? We’re now investing into it, we’re now delivering on it. Now we’re measuring our effectiveness. And that choice, that’s just the top level, the super simplified version of a user story. But in a complex world, you

Mike Cottmeyer

We’re talking about something about persistence of the hypothesis, and it’s a little bit like maybe I go off to build an epic. I break it down into features. I break it down into user stories. I start building the user stories, I start to validate the hypothesis. And as long as that hypothesis is winning in market, maybe I keep going down that path. At the point that I learn that I need to shift gears. I have that optionality to either change the OKR change, the epic, change the feature change, whatever, because, okay, so projects fix that mental mindset. This is what we’re going to go do, where an OKR creates space for the business and technology, whatever cross-functional team is necessary to really inspect and adapt their way into the actual outcome or the actual performance indicator that they’re trying to achieve.

Andrew Young

Spot on. Yep, that’s exactly the way we coach all that. 

Two More Key Takeaways

Mike Cottmeyer

Okay, awesome. So any takeaways that you want to leave our listeners or our viewers with before we wrap up here today?

Andrew Young

Yeah, there’s something we didn’t deeply hit on, and I’ll leave it as a takeaway because it’s pretty straightforward forward. It’s OKRs, KPIs. The initial work to get these things established is high, right? It takes time, it takes debate. We all have opinions, but once you establish that and you have a working platform, one of the common things we see is it becomes additive. We release some new things, we add some new KPIs, we release some more things, we add some more KPIs, and then at some point that KPI list is no longer the top 20 things to pay attention to. It’s growing back into the top 500 things. And with OKRs it’s, oh, we learned something about a market. So we’re going to kind of slide this thing in here because it’s also important. And then we’re going to slide this one in and we’re going to slide this one in.

And so KPIs, OKRs, just like every other backlog process has to have a limited amount. You can only focus on where your capacity will allow you to. So how many KPIs, if something’s performing healthy for two years or it’s fading away, I don’t need to see our fax ability to accept facts. KPI, we know it’s healthy and green also. Nobody’s using it, so we should just take that one out. So one of the things in this process, in your incremental and IT with feedback loops is it’s okay to remove things. It’s okay to remove things as long as the statement is no longer the most important, or we have actualized. So

Mike Cottmeyer

Always, I think the operative word and KPI then is key, right? Because they’re all performance indicators. We just clear about which ones are the key performance indicators

Andrew Young

And key doesn’t mean everything, and I think that’s been the biggest, for me, coaching this stuff, the hardest activity to get people to go through is K P I rationalization, and it’s not everything, and at the organizational level, it’s legging and at the team level, it’s leading. That takeaway is really important. You don’t need to be tracking everything, and even though you can, we’re in this maybe insurgence right now of we can track it, therefore we do track it and we put it in a data lake and at some point somebody might look at it, okay, cool. Those aren’t KPIs. Those are just things we’ve measured. We’re going to put them over there. What are you going to, I use this phrase when I coach, what are you going to obsess over when that thing goes red? You’re going to obsess over my weight, your happiness, the uptime of our system, revenue, customer churn, whatever those things are, that becomes the item you index towards.

The other thing I might do as a takeaway and just kind of the headline here is it doesn’t have to be time bound like projects, right? These things ebb and flow. What is good? I get this question all the time as we’re coaching Mike, is this a good OKR? And my response is, well, is that what your organization needs? Now, what might be the perfect KPI or OKR for LeadingAgile as an organization will look different to our clients, will look different to even another consultancy. It’s where we’re going, the vision, the direction, the story we’re telling, and that’s going to change over time. An acquisition might change your KPIs. A merger might change your KPIs. A collapse of a market might change your KPIs and organizations. We have a client, the real estate world might dramatically impact how they can focus their attention, so their strategy might shift, therefore, their KPIs and OKRs need to be able to shift with it. These have to be dynamic in nature. I think that’s the other big thing.

How to Get Started with OKRs and KPIs

Mike Cottmeyer

So, at the risk of injecting a shameless plug here. How do you typically get started? What does it look like to get kicked off in the development process of this thing? And then maybe if you want, what does it look like to maintain them over time?

Andrew Young

Yeah. We have been finding, again, shameless plug, we’ve been finding our most success when we can start with leadership teams. We have so many organizations we’ve seen where the middle parts of the organization and even teams are advocating for these things. They’re reading about it in a blog. They’ve got a friend at an organization that are using it. It’s not advocation the organization that’s needed. It’s getting a group of wildly successful leaders who are lighter into their career, who have never seen this style or have used alternative models before, get comfortable with the dynamic nature. And so just as we talked about teaming structures, starting with the leadership team and getting clear on what is the organization strategy? Can we articulate it in 10 or 15 OKRs? Can we identify the top 20 things that the organization needs to pay attention to? That can take days, weeks, months of internal debate and just good facilitation with a leadership team to find agreement on, here’s the story you want to tell.

Without that, it’s almost impossible to go down to the team level unless you just do team bottom up first approach. And again, we’re going to see wild divergence in that. So establishing it takes committed time by a leadership team to whiteboard, which is sometimes an activity that they’re used to delegating out, and we are asking them to actively participate in it. Don’t delegate three levels down and have them tell you what the five KPIs are. We want the organizational KPIs. We don’t want the most important functional KPI. We want organizational KPIs. That’s been the toughest part of getting these things started. Once it’s established, I’ll tell you the sustaining piece is, and I’m going to use our language governance moments that bring up the KPI dashboard for the organization so they can all get a look at what’s happening with this organization.

It can’t be a tool that’s on a shelf that the PMOs looking at or leader X and Y are only looking at if it’s not integrated into corporate governance in the town hall, just flashing it up. Look, our heat map mostly green. We got a yellow density here. We need to talk about that. If the whole organization doesn’t have access to it, the sustaining stuff’s hard. But to sustain it, visual access for most teams and team members has been a really important sustaining factor. And then just how you think about what a team prioritizes with. And so getting that into the prioritization model, team-based prioritization, how does this team make their decisions for the next two weeks? If they are reinventing their own prioritization model and they’re not using the KPIs and they’re not using the OKRs and they’re not using that decomposed cross-functional strategy, I don’t know that it sustains. You have to get teams to buy into, this is where we’re going strategically. Here’s what we have to influence. And as soon as that flywheel has started for most teams, it then becomes the limitation of can people write in a language of outcome versus output? And that’s probably the hardest teaching moment at the team level.

Mike Cottmeyer

Okay. I’ll tell you, one of my biggest takeaways that I really appreciated out of this conversation was that a lot of what the software community started figuring out in 2001, maybe 10 years before that, encapsulation and orchestration, small batch, more emergent behaviors, more product thinking over project thinking, your observation that this is really kind of companies and businesses kind of coming up to speed with the same kind of ideas. So maybe as Agilists, maybe we can figure out how to be, I don’t know, not so scared or maybe conversant in these ideas. Because in a way it’s just user stories at a company level, and it’s probably an oversimplification, but it sounds like that’s what we’re sniffing down.

Andrew Young

Yeah. I’ll invite anybody who self-identifies as an Agilists to have this chat with us because that’s exactly right. I’m not trying to take anything away from those movements or those perspectives. What I think this and people are leaning into here is, oh, for 20 years, for 40 years, we have had this separation of lean manufacturing, optimize, lean out, and then incremental iterative delivery of things, and that we can actually bring it all back together into a common language, common tool, common framework that isn’t feeling threatening to the non-ag because there is 20 years of baggage at this point for a non-ag Agilists to have Agilists language. It’s just a new home field we’re playing on that we can all come to. And I would invite any Agilists to have this chat because if I look at my LinkedIn feed, I’ve got two cohorts of people talking about this Agilists who say, this is just the same stuff, the conversation we just had. And they’re now starting to say, look, I can use this as my advocacy in my bridge to be a better partner. And then I’ve got the other non-ag world saying, this is just another version of goal setting frameworks we’ve done for years. It’s just branded differently. Why is this one working better? Oh, it’s because it allows us to connect back into fast incremental software delivery, and people are starting to see that connection.

Mike Cottmeyer

Right. Well, Andrew, thanks for your time, man. We really appreciate it. Absolutely. It was a great conversation. I know I learned a few things. Hopefully everybody else learned a few things as well. So we’ll do this again sometime.

Andrew Young

Yeah, thanks for having me, Mike. Fun chat. Yep, you got

Mike Cottmeyer

Okay, talk to you later. See you guys. Bye.

Why are so many Agile coaches and ScrumMasters getting laid off? Is it because Agile is disappearing? Or is it becasue they’ve gotten so dogmatic about the rules and cermonies surrounding Agile that they’re more of a burden then they are valuable? In our latest espisode of SoundNotes, Mike Cottmeyer and Dave Prior explore the competing priorties of many Agislists and the leaders they’re trying to help and talk about how to bring balance to the bigger picture so that companies can get back succedding with Agile.

Want to Listen Instead?

Contacting Mike Cottmeyer

If you’d like to contact Mike, you can reach him at:

LeadingAgile: www.leadingagile.com/guides/mike-cottmeyer
LinkedIn: www.linkedin.com/in/cottmeyer/
Twitter: twitter.com/mcottmeyer
Email: mike@leadingagile.com

Contacting Dave Prior

If you’d like to contact Dave, you can reach him at:

LeadingAgile: www.leadingagile.com/guides/dave-prior/
LinkedIn: www.linkedin.com/in/mrsungo
Twitter: twitter.com/mrsungo
Email: dave.prior@leadingagile.com

If you have a question you’d like to submit for an upcoming podcast, please send them to dave.prior@leadingagile.com

Interested in CSM or CSPO Training?
You can find all the details at www.leadingagile.com/scrum-training/

“Technical agility is the underlying precondition for process agility, which is the underlying precondition for organizational agility, which is the underlying precondition for business agility. No amount of leadership attitude or mindset will change this.” — Mike Cottmeyer, CEO LeadingAgile

Video Transcript

We want a culture in the organization that is safe and is collaborative and does empower people and does enable the people closest to the technology and to the customers to make the decisions. But we also want to be in a system that makes and meet commitments that we can deliver against the sprint objective. And we can have multiple teams that are integrated in such a way that they produce integrated deliverables on regular cadences and where we have our portfolio items that actually move through our portfolio at a predictable rate. And ultimately that enable us to inspect and adapt and market and achieve our business goals.

(Musical Interlude)

Preconditions for Business Agility

Okay, everybody, how are you guys doing today? I am going to try to unpack a tweet that I put out for my team a couple weeks ago. Can you still say tweet? Is it a tweet anymore? Now that Twitter is x? I don’t know, I guess I’m behind the times. But we put out a tweet and it said something like this. It said that technical agility is a underlying precondition for process agility. Process agility is a precondition for organizational agility and organizational agility is a precondition for business agility. And the follow-up comment was that there’s no amount of attitude and mindset that is going to increase your level of agility if your core underlying infrastructure, your core underlying operating model is not set up for it. So that’s kind of the set up for what I want to try to do today. And so, let’s see if we can explore this a little bit.

When Scrum came out 20 some odd years ago or whatever, I guess it got popular 10, 15 years ago with the advent of the CSM, one of the things, it was a good thing, and it was a bad thing. And the good thing is that it made Agile a lot more mainstream. It kind of got the certification out to the masses and it opened up the doors for the relationship with the PMI and the PMIACP. And it got a lot of people thinking about the attitudes, the mindsets, the principles, and the practices associated with Agile. Now, when we were putting together the PMIACP certification, I was actually on the group of 8, 7, 8 people that did. Of the things that I thought was interesting about it is that if you think about the PMI and the PMBOK, the traditional project management methodologies were very organization, it was very technology agnostic, it was domain agnostic.

These were generally accepted practices that could be applied by most project managers. Most of the time it didn’t really matter what you were doing when you started getting into the agile methodologies. A lot of the things that I talk about really start to begin to matter. What does your organizational structure look like? How are you organized around value? What is your requirements, decomposition practices look like? Are we operating in small batches? Are we able to get fast feedback? Are we able to continuously integrate and continuously deploy? And I think a lot of that is what we’re fundamentally missing in most organizations when we talk about agile. So getting back to the tweet, it’s like if I have a code base that is not continuously tested, continuously able to be integrated, continuously able to be even potentially shipped, it’s like all the process agility in the world doesn’t really matter if I can’t get to a place where I get fast feedback from a real customer if I don’t know that I’ve fundamentally got to a definition of done if I can’t actually ship that product and make it actually work.

So the point being is that without the ability to do the technical stuff, regardless of the domain, whether it be manufacturing, whether it be software, whether it be marketing or collateral or whatever it is that you’re using agile for, if I can’t get to a place where I can produce something that can be validated technically, then all the process agility doesn’t really matter. And how that manifests in a lot of companies is imagine a situation where you’re doing something on some sort of legacy assembly line and there’s a bunch of analysis, there’s a bunch of design, then there’s get the assembly line put together, then then you have the assembly line itself, and then you’re producing something that shows up as value on the back end of that process. You could use Scrum all day long to manage the work that gets done, but you don’t actually achieve agility because at the end of the day, you’re doing large batches, you’re doing long assembly lines, you’re not able to test until you get to the very end of the system.

And so the technical agility, the ability to produce the product in small increments that are testable and validatable is a precondition for all the requirements, decomposition and all the tracking and the managing and the burn down and the velocity and all that kind of stuff. If I can’t get the technical agility and the process agility, it’s really hard to get organizational. It’s really hard to get the parts of the organization to start operating in small batches. How can I do two or three month projects if they get shipped into market on regular intervals? If I don’t have the teams that are able to operate that way, if I don’t have the platforms that are able to operate that way, if I can’t get my organizations within my enterprise to be able to operate with agility, how do I get the overall organization to operate with agility?

The Role of Culture in Agile

And one of the things I’ve been thinking about a lot lately is the role of culture and why so much that we see culture as a first order concern. And I’ve been unpacking culture a little bit. And the angle that I’ve been thinking about it from is this idea of, I think we think about culture in two primary ways. I’ve done a little bit of anecdotal research in some of the talks in rooms I’ve been in over the last couple months. And one of the things that I find is there’s kind of a split. There’s a certain group of people that define culture really as the environment, how people feel, how they interact, do they feel safe, do they feel empowered, things like that. And then there’s another kind of branch of culture, which is a little bit about accountability in making and meeting commitments and do we get things done and what do we do when we’re behind schedule?

What do we do when things are at risk? So, there’s this kind of feelings and more emotional side of agility. And then there’s also kind of culture. And then there’s kind of this idea of culture as the ability to get things done and how do we respond in the face of adversity? And one of my underlying hypotheses is that I think a lot of times in Agile, because we haven’t created the conditions technically for the process agility, and then because we don’t have the technical, don’t have the process agility, we’re not able to produce measurable products every two weeks. We don’t get a lot of the organizational agility and then we don’t get the business agility. And in that kind of an ecosystem, that hard side of culture where it’s about producing things and getting results and making and meeting commitments often falls by the wayside.

And what we end up doing is we end up going more towards a best effort kind of mentality. And it’s like I showed up, I did everything I could. I operated from the Scrum framework. I really loved being there. It was very collaborative. It was very just a good environment to work in. I felt very personally safe. That’s an aspect of culture, but without the ability to actually produce things on regular intervals and to know that we’ve gotten to a definition of done and to actually be able to burn down against the known backlog and be able to make and meet commitments and actually deliver against our business objectives, it’s kind of like, what are we doing? And so, we find ourselves in this conundrum where it’s like we want a culture in the organization that is safe and is collaborative and does empower people and does enable the people closest to the technology and to the customers to make the decisions.

But we also want to be in a system of delivery that makes unique commitments that we can deliver against the sprint objective. And we can have multiple teams that are integrated in such a way that they produce integrated deliverables on regular cadences where we have our portfolio items that actually move through our portfolio at a predictable rate. And ultimately that enable us to inspect and adapt and market and achieve our business goals. And so there’s just a lot of things that work together. I don’t have the technical agility, I don’t get the process agility, I don’t get the organizational agility, I don’t get the business agility. And then I think what that does is that breaks the ability in the culture to say, Hey, we’re going to be accountable. Without that process agility, without the organizational agility, it’s very hard for us to make and meet commitments.

It’s very hard to do what we say we’re going to do. So, we lean pretty heavy as Agilists on the environment that we’re trying to create in the working conditions. And at the end of the day, I think what the goal is, is to have both. I think we want to have great work environments. I think we want to have great cultures that respect people, but we also have to do it within a framework where we can make and meet commitments and we can do what we say we’re going to do and we can deliver against customer promises and we can deliver against market expectations. And so, without the attention to the technical agility, in addition to the process, agility makes it really, really difficult. And so that’s where a lot of the transformation work that we talk about comes in because you can do a lot with the process agility, but if you’re not working to create the underlying conditions for the technical agility to be a thing, everything above it starts to break down the organizational and the business agility and the culture of accountability, the culture of making meeting commitments.

And we kind of devolve into this best effort kind of a thing. And I think that’s a problem. So if you’re in an environment where you’re over-indexing on process and the softer side of culture, maybe look towards the technical agility side and see what can we do to be able to actually deliver this product in small increments so that we can start making immediate commitments and start managing the expectations of our business partners so we can actually run a business and we can actually get a solid return on that investment and we can actually produce things when we say we’re going to do it. So that’s my thought for the day and I hope you guys enjoy and we’ll catch up with you later. See you. Bye.

Today, we’re talking about the triple constraints; time, cost, and scope. In Agile, we fix time, we fix cost and vary scope. But that requires a high-trust environment where the product development teams and the business are working together toward a common goal. Watch this video to learn more about the triple constraints in Agile and what you need to do to make sure that your teams can successfully vary scope in a fixed-time, fixed-cost environment.

Video Transcript

In Agile, what we’re trying to do is fix time and cost, get the business and product development teams to strategically decompose work, prioritize strategically, and focus on the minimally viable product all the time and optimize our chances of being successful as an organization. It isn’t productive for the business to fix all three aspects and demand that the product development teams pull a rabbit out of their hat. Sometimes that works, but it’s a low-probability endeavor. The counter-reaction is, “We’re Agile; we won’t make any commitments.” That’s a non-starter too. After all, we have businesses to run.

(Musical Interlude)

The Triple Constraints in Agile

Okay, everybody. Today I want to talk a little bit about the idea of the Triple Constraints. For those familiar with project management or those who grew up in that field, including myself, as I’ve been involved in Agile project management for about 15 to 20 years, the blend of traditional methods and Agile practices has been a long-standing interest.

The concept of the Triple Constraints holds significant importance for me. This concept essentially revolves around three variables in project management: time, cost, and scope. The essence of the Triple Constraint idea is that while you can choose two variables to fix, the third must remain adaptable.

If you decide to fix both scope and time, then you must be able to adjust the cost accordingly. Alternatively, if you opt to fix both cost and scope, then the time component must be flexible. Agile, however, introduces a unique approach. It dictates that time and cost remain fixed, particularly the sprint or release duration and the team size applied to them.

With this framework in mind, Agile proposes variation in scope. The Agile backlog empowers us to generate requirements, features, or system behaviors and prioritize them in a manner that allows us to start with the highest-priority items. This way, even when we exhaust our allocated time and budget, we still have a high-value deliverable that can be shipped.

Should priorities shift and the need arise to replace elements, we retain the flexibility to adjust scope within the defined time and cost constraints. Within the industry, an intriguing aspect, one I empathize with as a CEO, is the presence of uncertainty, particularly in software and product development, which often involves a software product.

The tension faced by business leaders revolves around constraints. They must deliver a product within a defined timeframe and budget, which isn’t limitless. This situation forces them into a gamble. This wager can be framed like so: by summer, when the new product must be launched, the trade show requires a demo for clients, or even when a promise to a client needs fulfillment – these scenarios highlight the financial and human resource limitations.

These limitations signify a cap on the workforce that can be allocated to the project. However, the requirement remains steadfast: deliver what’s necessary at the appointed moment. Particularly in the face of considerable uncertainty, leaders often feel compelled to assign deadlines, teams, and expectations for deliverables.

Yet, the challenge emerges when leaders fixate on time, cost, and scope. This fixation inadvertently introduces a concealed fourth variable. Some refer to this as an “iron square,” deviating from the traditional iron triangle concept. In essence, this transition transforms the three variables into four: time, cost, scope, and quality.

When time, cost, and scope are rigidly defined, a cascade of consequences unfolds. Trade-offs are made, shortcuts are taken, and even unintentional coding defects arise. These actions collectively erode the intrinsic and exceptional quality of the system over time, even if glaring defects aren’t present. The accumulation of technical debt within these systems becomes burdensome and inevitably requires repayment.

The essence of this principle, the “iron triangle,” dictates that two variables are fixed while the third is allowed to float.

Managing Variable Scope in Large Organizations

A noteworthy point I often share with teams in this context is that it’s unreasonable to approach the business with the notion that after receiving time and cost parameters, the team will build whatever they want within these bounds. It’s not a mere best-effort scenario.

Around 15 to 20 years ago, I collaborated with an architect who succinctly conveyed this concept. He told me, “Mike, this is Agile – you get what you get when you get it.” While I’ve cited his words over the past two decades, this belief, though common, embodies a detrimental anti-pattern and a significant failure mode. This perspective isn’t conducive to success.

In cases where you’re operating within a confined environment with discretionary funds and the timing of market entry isn’t critical, and you possess a high-caliber team with deep knowledge of the solution space, you might manage to navigate certain aspects more flexibly within Agile methodologies.

In certain scenarios, we manage a small team that collaborates on internal products. In these cases, I don’t impose deadlines or demand roadmaps. Instead, we convene weekly and discuss priorities. We allocate resources at a comfortable pace and ensure alignment with a budget I’m at ease with. This approach makes sense in specific contexts.

However, it’s important to note that this pertains to non-mission-critical software where customers aren’t waiting with anticipation. On the opposite end of the spectrum, we encounter situations with vital dates, crucial timelines, and multiple teams necessitating joint efforts to deliver an integrated product promptly. We must meet stringent time and budget constraints.

The challenge in such situations lies in the management of scope. It’s not about adopting a “get what we get” mentality. Instead, in an environment characterized by fixed time and cost but variable scope, we need to strategically break down the work. Our aim is twofold: maximize value and enhance the likelihood of having a valuable product to release.

Our strategy involves a constant focus on epic, feature, and story decomposition. We keep the concept of a minimally viable product at the forefront. Consistently, we opt for the simplest solution that can feasibly work. We aim for the fewest user stories to fulfill a feature, the least number of features required for an epic, and the minimal amount of epics necessary to enter the market.

Our dedication to this approach is relentless, ensuring that when time and funds run out, we still possess the strongest opportunity to launch our much-needed product. This approach entails a degree of compromise on both ends. In Agile, we acknowledge the fixed nature of certain parameters: sprint and release durations, roadmaps, team sizes, and organizational scale.

It’s analogous to understanding that nine women can’t collaborate to deliver a baby in a month. There’s a limit to the scalability of development efforts. Consequently, certain aspects like time and cost are indeed fixed. In response, the business must recognize the need for strategic trade-offs. They should approach the product development organization with an awareness of how to optimize their chances of success.

If the business fails to grasp this perspective and rigidly adheres to the constraints, two unfavorable scenarios unfold. The first involves compromised quality, as previously discussed. The second entails missed deadlines and dates, both of which are commonly observed. These outcomes aren’t conducive to a healthy work environment and leave no one better off.

From the developers’ standpoint, they must collaborate with the business to aid in decomposing the work optimally. Through this collaborative effort between the product teams and the business side, a strategic work breakdown can be achieved. This collaborative approach enables teams to stabilize their velocity and operate at a sustainable pace, with no death marches.

The business possesses all the drivers governing what is constructed, how it’s constructed, and the priority of construction. The business holds the authority to decide how to optimize its chances of entering the market efficiently. Simultaneously, we collaboratively engage in trade-offs along the journey.

Creating a High-Trust Partnership for Success in Agile

Ultimately, both the product development teams and the business must view themselves as partners.

Historically, this partnership presents challenges due to the frequently low levels of trust within the organizations we engage with. Product development teams often lack confidence in the business’s set direction, while the business is skeptical of the product development team’s ability to deliver on time. Hence, trust must be established early on during transformations.

More often than not, I urge teams to cultivate trustworthiness. This involves the ability to deconstruct tasks, establish consistent velocity, and maintain stable throughput at the feature and epic levels. This way, they gradually build the business’s trust by fulfilling their commitments.

Upon involving the business, the collaboration entails their participation in the task decomposition and contribution to strategic trade-offs. This participation acknowledges their role in working alongside the product development organization to optimize delivery within time and budget constraints – the crux of the matter.

In the realm of Agile, the objective is twofold: fixing time and cost while fostering collaboration between the business and product development teams. This collaboration manifests through strategic work decomposition, consistent prioritization, and a steadfast focus on achieving the minimum viable product. This concerted effort enhances the prospects of shared organizational success.

This approach thrives on pragmatism. It’s counterproductive for the business to rigidly fix all three aspects and expect the product development teams to miraculously overcome challenges. While this strategy may yield occasional successes, the probability remains low. Conversely, dismissing all commitments under the banner of agility is also untenable.

After all, businesses are in operation – generating profits, satisfying customers, and driving revenue. Thus, a pragmatic path emerges: fix time and cost, initiate a strategic collaboration between business and product development, strategically deconstruct tasks, emphasize prioritization of the minimum viable product, and allocate time for additional development.

Should a significant element be overlooked, addressing it transparently in the subsequent release remains an option. This methodology encapsulates the approach to managing time, cost, and scope within the Agile framework. Any alternative approach would be counterproductive. I encourage you to reflect on this approach and remember we’re here to assist if needed.

Have a great day. See you guys. Bye-bye.

There’s been a divide in the Agile community for a while now. On one side, you have the camp that’s all about team-based, iterative and incremental delivery. On the other side, you have the camp that sees Agile more of a social movement; this side is all about empowering the teams and building a culture or a mindset of Agility. Meanwhile, as the debate rages on, a lot of the executives and leadership teams we talk to don’t even want to talk about Agile at all. It’s become a dirty word, they tried it and it didn’t work,  and now they just don’t believe in it anymore. So, how do we get these leadership teams back on board with Agile? Watch this video to find out.

Video Transcript

Maybe it’s just the callers, but I notice a frequent occurrence: many individuals avoid mentioning Agile nowadays. I frequently interact with leadership teams. You know, I often engage in sales. Subsequently, my teams inform me, “The leadership wants you to have a conversation with them.”

However, you must avoid using Agile, Expedition, Basecamp, team strategy, and “velocity.” Why? These concepts have suffered misuse. Leadership teams are becoming weary of them. They initially believed in the potential, yet the results were lacking.

As Agile professionals, it’s our responsibility is to bridge the gap between cherished practices, our culture, and the essential business benefits. This bridge is attainable through structural changes, alignment, and harmonizing intellectual property with business objectives. It involves breaking significant tasks into smaller components, eliminating dependencies, and similar actions.

That is what Transformation entails. In essence, Agile isn’t the main concern. The true focus is on agility.

(Musical Interlude)

Companies Don’t Care About Agile

Hello everyone, how’s everyone doing today? Today, I’ll discuss a recent tweet of mine. It highlights the notion that Agile itself isn’t the ultimate goal. What truly matters is agility. The emphasis isn’t on adopting Agile practices, forming Agile teams, or establishing Agile ecosystems.

The key concern is the capacity to introduce products to the market, receive feedback, measure progress, and adapt to the market’s needs. A week ago, my team posted something on LinkedIn that gained substantial attention. We even created a response video.

Perhaps we can include a link to it below this video. Essentially, the image conveyed that agility hinges on alignment. Getting team strategies right, synchronizing backlogs, and efficiently producing working software at scale are crucial. Without this alignment, even the best Agile practices and culture won’t suffice.

Alignment takes precedence. Interestingly, these concepts are closely intertwined. Comments on the post included feedback like, “tell me you know nothing about Agile without telling me you know nothing about Agile.”

It was fairly interesting to observe the various perspectives people held. At one point in the response video, I mentioned that if you aren’t actively pursuing agility through systems, governance, metrics, and the endeavor to introduce measurable products to the market, then you aren’t truly sharing the same context as I am.

There seems to be a divide in the current Agile community. One branch of Agile focuses on team-based, incremental, and iterative processes. This approach centers around optimizing for smaller batches and hastening market entry. Much of this can be accomplished in a planned and predictable manner.

Then there exists another branch, and this isn’t a recent divergence. This distinction has existed for quite some time. This perspective views Agile as a form of social movement, emphasizing the empowerment of teams, enabling teams to make decisions, and fostering an environment for developers to fulfill their responsibilities.

However, the challenge lies in the desire for both perspectives. Drawing from my 13 years of experience in this field and the seven or eight years I dedicated to leading Agile, my belief is that businesses ultimately require the capability to consistently and predictably release software to the market.

Agile introduced a fresh metaphor for conceptualizing how to structure systems and teams, determining the work allocated to these teams, gauging progress, and executing transformation initiatives that facilitate the formation of Agile teams within organizations.

Consider an Agile team, composed of 6 to 8 individuals. They possess some autonomy regarding their technical framework. They collaborate with a product owner, at the very least. Their backlog is well-defined. They deliver functional, incremental software at the conclusion of each sprint, followed by feedback.

Certain conditions must be established within any organization to enable the delivery of such characteristics. Once these conditions are met, methodologies like Scrum or SAFe offer effective approaches to managing tasks, gaining visibility, and tracking progress through burn downs. The presence of teams with minimal interdependencies, operating with a degree of autonomy, is a key factor.

They’re operating clearly with the direction of a product owner, but they have a lot of space to be able to make decisions and decide who and how does the work and all that kind of stuff that is like a byproduct of the ability to get people into the right ecosystems. And so I think to some degree, right as an agile key to this one fork of the Agile community, what they’ve done is they’ve overindexed on the practices of agility like the daily standup review and retrospective, the burn down, the collaboration techniques or if it’s at scale, the big room planning and the different techniques associated with that.

And, you know, a lot of times that side of the world tends to index on culture and how people feel and are they happy or not and everything. And again, like I feel like a broken record to some degree, that stuff is important. But that stuff is a byproduct of being in an ecosystem that can deliver.

And one of the things that I’m really passionate about and the reason why I’m kind of hitting on this in some form or fashion almost every week is because there are a lot of places that we go nowadays where people don’t want to talk about Agile, right? It’s like we’re burning that word out in the industry because what people see it as is, they see it as a social movement, they see it as a way of empowering people.

They see it as a way of trying to change the culture, and culture and everything is great, right? We want it, but only if we can deliver reliably and predictably and get fast feedback. So, what I’m really trying to say with this tweet and with this article is that we have to pay attention to both, or we’re going to continue to marginalize ourselves in many of these organizations.

Enabling Social Movements in Agile

And so, if we want to have empowered people on teams that have local authority to make decisions and to work directly with customers and to get feedback and to collaborate and to do all the cool stuff that we want to do with Agile, we have to create the right ecosystems within those organizations to be able to do that, right?

And so, at the very minimum, at the team level, it’s a complete cross-functional team, few if any dependencies, backlogs that are clearly articulated, they’re broken up into user story-sized increments where you can actually put something in front of a customer at regular intervals and get feedback from it. And the point that I’m trying to make with all of this is that is what enables agility.

The practices that we put on top of it and the culture we create are enablers and byproducts of that. Because, you know, I’ll tell you just candidly, at the end of the day, as a business owner, the CEO of Leading Agile, I care deeply about my people and the work that we’re doing for our client. I want to make sure that our people have a great environment and that they’re supported and that they have the ability to operate somewhat autonomously and to decide.

And, you know, we strive really hard, and we work diligently to be an agile organization. But if we don’t deliver for our customers, if we don’t produce value for our customers, then, you know, our customers can’t pay us, and then we can’t make payroll. And then, you know, you have to lay people off, and there’s just no way to do it unless you’re running the business of it.

And so, this idea that nobody really cares about Agile, all they really care about is agility is is what I’m saying is that if we don’t achieve agility with our agile right as defined by teams that can put things into the market and get fast feedback and inspect and adapt. Right. And to do that in a relatively reliable and predictable way, then we don’t really have a business to run.

And if we don’t have a business to run, we can’t keep people employed. I had an employee one time when we were forming as a company and she said something to me to the effect I guess I was losing my mind or something, you know, Again, early days New CEO. I’ve grown up a lot in the past 13 years, but she said something to me to the effect of, you know, if you keep acting this way, you’re going to damage our culture.

And I was like, well, if we don’t figure out how to run this business profitably, we’re not going to have a culture to dismantle. Right? And I stand behind that, right. And this is what I’m encouraging the Agile community to think about, is think about are we aligning to the goals of the business? Are we able to help the business to be profitable?

Are we able to put things into market on a on a on a regular recurring basis and be able to make money from it? Right. Because at the end of the day, if our Agile isn’t enabling that, if we’re not producing software that our companies can sell, there’s just no amount of practice, no amount of culture is going to overcome that.

We have this kind of notional idea that if we empower people, that if we give them permission to do the right things, that that they’re going to self-organize and they’re going to overcome and they’re going to figure it out. But again, guys, that’s just not the way it works in a lot of situations. There are a lot of things that are going on in some of these large organizations that are beyond the control of an individual team.

So, if you can’t get some of the systems architecture, some of the way that the businesses organized work out, if you can’t get some of the governance to comply and things worked out, you guys are really slugging in an uphill battle.

Adopting Agile is Never About Adopting Agile

So, at the end of the day, right, I think a lot of us want to operate within our sphere of influence, right? We understand the practices and we can teach the practices and we want to encourage the people who do the practices. And we can also encourage people to have better attitudes and to be more adaptive.

And all that stuff is great. But at the end of the day, again, I’m going to keep coming back to it. If the end of the day, if that doesn’t produce working tested increments of software that are tested and validated and able to be shipped and able to be used by a customer and consumed and in actually the company can charge money for it and reduce risk and satisfy its customers and get feedback and all those kinds of things.

It just doesn’t matter. So, when you hear me say things like Systems first are agile is about alignment, that’s what I’m talking about. And and again, if that’s not the problem you’re trying to solve, like we’re living in really different worlds. Okay, So I’m going to just beat this drum, you know, probably week to week and just talk about this a little bit.

So, you know, at the end of the day, what I’m encouraging you guys to think about is that it isn’t about Agile, it isn’t about the practices, it isn’t about the ceremonies, it’s what business benefit that those practices and ceremonies and things were designed to achieve. And if we can’t get the ecosystems right and the companies that we work in, then those practices often kind of fall flat.

And I’m telling you, I see it a lot, and maybe it’s just the people that call us, but I see it a lot as there’s a lot of people that don’t even want to say the words Agile anymore. I go in and talk to leadership teams a lot, have like will go on and we’ll do a sale of something.

And then my teams are like, Hey, the leadership team wants you to come in and talk to them, but you can’t say Agile, you can’t talk about exhibitions, you can’t talk about Basecamp, you can’t talk about team strategy, you can’t talk about velocity. Well, why not? Because those ideas have been so misused. The leadership teams are really getting tired of it, right? They bought into the promise and then they didn’t get the reward on the backside.

So what we have to do as agile professionals is we have to bridge the gap between the practices that we love and the culture that we love and the business benefits that the companies require. And it’s possible to bridge those two, but we bridge them through structural changes in alignment and alignment between IP and the business and breaking big things into small things and breaking dependencies and all those kinds of things.

That’s what transformation is about. So, nobody really cares about Agile. What they care about is agility. So, if your Agile isn’t resulting in actual agility, then we have a disconnect and it’s up to you guys to bridge that disconnect. And as always, let us know if there’s anything we can do to help. So anyway, you guys have a great day, and we’ll talk to you next time.

Teams, backlogs, and working tested product. Without these 3 Things, you’re not really doing Agile. The problem is that you can’t wave a magic wand and have these 3 Things overnight. It’s going to take some work. It’s going to require a planful approach. Because when the ideas behind Agile meet the reality of what’s going on inside large organizations, it’s going to run into some roadblocks. But that doesn’t make the need for teams, backlogs, and working tested product any less real.

Video Transcript

Approaching this systematically, there are methods to engage the organization in considering how to establish a team-based structure within the enterprise, correct? How do we manage the flow of work to provide small batches to these teams? What should we measure and control to encourage efficient flow, avoiding completing work before starting new tasks?

This concept, typically, when we engage, comes down to analyzing the business capability model, domain-driven design, product hierarchy, various organizational structures, governance approach, and metrics. We form a hypothesis for the changes needed in advance to support different teams, teams of teams, and networks of teams with interdependencies, ensuring the best chance for success.

(Musical Interlude)

Why Are You Adopting Agile?

Greetings, everyone! How’s everyone doing today? Today, I’ll discuss a recurring theme. I often talk about the significance of teams, backlogs, and working tested software. We’ll delve into tailoring Agile methodologies to suit your organization’s unique circumstances. However, I’ll focus on a comment we received on TikTok.

In that context, my team extracted a clip discussing the requirement for Scrum to involve complete cross-functional teams, equipped with a prepared backlog, capable of producing functional tested software by each sprint’s conclusion. The comment was intriguing, along the lines of, “Sure, easy for you to say, but it’s quite challenging in real-world scenarios.”

I wholeheartedly concur with that remark. However, does the challenge negate the truth? Does the difficulty involved make it any less true? Ultimately, I return to the fundamental question regarding Agile adoption—what are our objectives?

Whether it’s delivering small product increments at regular intervals, leveraging these for customer feedback, learning, and adaptation to enhance our products, or aiming for innovation by offering products customers might not even realize they want yet, the core principles hold. Even if customers know their desires, the key lies in inspecting and adapting to meet their actual needs.

Considering Agile’s essence, it’s inevitable that we must employ complete cross-functional teams—teams encapsulating the value stream within, working from a backlog containing small user stories or backlog items that embody tangible system behaviors.

If we can’t achieve functional tests in increments by each sprint’s end, what can we demonstrate to our customers? The challenge lies here. It’s like saying, “Sure, Mike, easy for you to say, but in real life, it’s genuinely difficult.”

I always consider the alternatives. So, the alternative scenario involves having ScrumMasters and product owners, yet we might merely execute Scrum mechanics, right? We could handle daily stand-ups, conduct reviews, retrospectives, track burn-down charts, and story points—various activities typical of a Scrum team.

Let’s assume we’re even implementing XP practices. We might decide to practice test-driven development, pair programming, or other software craftsmanship techniques. But fundamentally, if we lack the ability to present a working tested increment in front of a client, at the end of the day, what are we doing, right?

On Customizing Scrum to Fit Your Needs

So, what I would suggest is that most tailoring or customizations of Scrum revolve around addressing the less-than-ideal circumstances within the organization, rather than tailoring Scrum to the team’s local needs.

In essence, we accept the organization’s constraints and limitations, using Scrum to maneuver within them. Imagine, for instance, a Scrum team dedicated to a specific product, which is actually a subset of a legacy monolithic system. Let’s say this team attempts to work on a feature within a COBOL mainframe application, a system now six or seven decades old.

The scenario implies that the team engages in Scrum, constructs a controlled backlog, and operates as a complete cross-functional unit. However, technical challenges hinder regular software deployment and feedback collection due to tight architectural coupling within the monolith.

Consequently, the team’s Scrum process becomes a driving force. Effectively, their velocity remains at zero until they undertake the necessary work to extract that specific component or feature from the monolithic structure. This is how it theoretically functions—addressing impediments to Scrum implementation, in this case, the legacy monolith, which obstructs the desired delivery process we’re discussing.

The concept is to apply Scrum, which reveals your impediments. Over time, you work on removing these impediments. Essentially, leveraging Conway’s Law, we structure ourselves around what we want to hold architecturally significant—paraphrased. Subsequently, the designated team extracts and detaches from dependencies within the broader organization. However, as both I and my commenter noted, this is indeed challenging.

This is why, in most cases, though not necessarily all, we do not advise commencing with Scrum, its practices, or cultural mindset. Organizational obstacles are bound to obstruct your path, obstacles we are aware of. To execute Scrum effectively, you need the authority within the organization to proactively address these hurdles. We might acknowledge it sounds straightforward, yet it can be complicated when agency is limited.

Typically, this is the rationale behind not initiating transformations within organizations at the surface level and attempting bottom-up change. In practice, what often occurs is adopting Scrum practices, encountering immovable roadblocks, and then attempting to tailor Scrum to accommodate the enterprise’s dysfunctions, which, in essence, often deviates from true Scrum.

However, such an approach is usually ineffective. A common outcome involves redefining the purpose of Scrum. It shifts from being about delivering business value, innovating in the market, and embracing iterative learning from customers, to focusing solely on team dynamics, culture, collaboration, and workplace satisfaction.

While these aspects hold significance and are commendable goals, they alone might not warrant an entire overhaul of your company’s operations.

How to Engage the Company and Do Agile Right

Our chosen approach, therefore, is distinct. This approach drives us to create videos, deliver talks, and share content on platforms like TikTok and LinkedIn.

Why do we put forth these efforts? It’s because I wish to convey that there’s a systematic approach possible. It entails engaging the organization in developing a team-based structure within the enterprise. Furthermore, it involves orchestrating the workflow to deliver incremental batches to these teams.

So, how can we measure and control to promote a seamless flow that eliminates the tendency of completing work before initiating new tasks? Right, that concept. And so, when we engage, it frequently revolves around examining the business capability model, domain-driven design, product hierarchy, distinct organizational structures, governance strategies, and the metrics in place.

We establish a hypothesis regarding the necessary pre-emptive changes to facilitate success for different teams, teams of teams, and networks of teams, even those with interdependencies. For the TikTok viewers who find themselves on a team without the authority to enact change, that becomes their reality.

However, my intention is to have more individuals in our industry truly understand the foundational workings—complete, self-contained teams operating from well-defined backlogs, capable of generating functional tested increments biweekly. Likely, these teams function within a 3 to 6-month roadmap, all aligned with broader strategies, long-term roadmaps, connected OKRs, and KPIs.

This isn’t something that can easily be achieved from the ground up. I’m not implying that viewers of these videos can magically bring about these changes. Yet, I want them to grasp that Agile practices alone might not automatically create these conditions.

It involves making deliberate trade-offs. What slightly saddens me and proves a bit frustrating is that Agile is gradually being perceived as a methodology primarily geared towards team collaboration. There’s a risk that Agile is becoming synonymous with a set of practices, which is something I notice increasingly in the market.

The transformations we’ve been advocating for the past three decades are now being absorbed into the digital transformation realm. The idea of composable enterprises, adaptable organizations, is taking shape, evident in mature strategies around cloud migration.

Ultimately, someone else might take up the mantle of organizational redesign. This burden of change might shift to another entity. It’s becoming apparent in conferences that the concept of transformation is being relegated to a backdrop, while the emphasis is placed on adopting best practices.

This is acceptable and holds its place, but I doubt it will entirely solve the issue. Thus, it’s simple for me to verbalize, yet the implementation in practice is undeniably complex. This is precisely why we are committed to educating, communicating, and sharing insights through various platforms. This is why we assert what we do.

Yes, I address you as both a practitioner and a prospective leader. My aim is to equip you to communicate with your own leaders. I hope this resonates with leaders who may be watching and finding that Scrum isn’t effective for them. I want them to comprehend the underlying reasons because there’s a pathway forward and a systematic perspective to adopt.

I realize that I might sound repetitive week after week. Yet, this is the reality we face daily. I trust this information proves beneficial. I value the feedback you provide. My team keeps me informed about the comments, and while my responses might sometimes be a bit delayed, I’m genuinely committed to interacting with all of you.

Hence, if you have any thoughts to share or feedback to offer, we eagerly await your input. Looking forward to our next conversation. Until then, take care and goodbye.

We recently got a lot of comments on one of our LinkedIn posts which generated a lot of discussion. So, Mike made a video clarifying some of his points and expanding on what we mean when we say Agile is all about Alignment; and why that should always be the the place you start an Agile Transformation.

Original Post on LinkedIn

https://www.linkedin.com/feed/update/urn:li:activity:7094293615258017792/

Everyone wants to focus on practices first. That’s because it’s easy. We can get trainers to come it, we can get coaches to come in, we can teach practices. But we don’t really have to make any hard organizational changes when we do that. Maybe it works sometimes, but in most large companies practices first is never the right way to go.

Join Mike as he debates the general consensus on Agile and encourages you to start thinking about Agile through the lens of systems so that you can finally achieve the change you’ve been searching for.

 

Transcript:

The idea here is that there is no way from here to there if we are only thinking about Agile practices or we are only thinking about Agile mindset, because at the end of the day, those practices and that mindset is going to go head on into like the skeletal system, the infrastructure of that organization, the way that it is structured, the way that it is governed, the way that it is measured is going to be told.

We are orthogonal to the practices and cultures that you’re trying to get to. So you can start with practices and cultures and try to back your way into the structural elements. But what we believe is that if you start with the structural elements, you take the big things, you systematically break them into smaller things. You work on reducing batch size and breaking dependencies and increasing local autonomy and giving those smaller objects some degrees of freedom through that core transfer nation effort.

You get the fundamental underpinnings of digital transformation. You get the fundamental underpinnings of the composable enterprise. You get the fundamental underpinnings of the product driven organization. You get the fundamental underpinnings of a project to products type infrastructure.

Okay, everybody, welcome. Welcome to our show today. And just to give a little bit of context, one of the things we’ve been doing for the last couple of weeks, months, something like that, is probably two or three months ago, I listed a group of about 20 different tweets for my marketing team, and they were just basically things that I talk about all the time structure, governance metrics, teams backlogs, working tested software dependencies, things like that.

And then one really cool thing happened is I posted it up into our internal Slack channel and one of our one of our senior engineers took them and ran them through, ran all the tweets through chat. And and the first thing he asked is he said something like, why is this statement controversial? And then and then he asked Chad GB to rebut the comment.

So why don’t you start with today is just a really explicit treatment of that. And then I’m going to branch off and I’m going to do I’m going to connect the dots to a few other things and I’m going to try to see if I can open up the conversation all that. So so bear with me here. So the tweet was trying to apply Agile practices and into an environment where they weren’t designed to support or enable is a recipe for disaster.

Alignment is everything. It is always the systems first structure, governance and metrics, then practices, then culture. It doesn’t work any other way, right? So basically trying to make the case in a short 140 characters, even though you can do more than that now that that you know LeadingAgile’s core approach that if we don’t get the teaming strategies right, we don’t get the ability to produce backlogs right.

We don’t get the ability to produce working tested software, right? We don’t put the RAID governance strategies in place, we don’t put the right metrics, strategies in place. You know, our core belief is that there is no amount of scrum, there’s no amount of scale to Agile, there’s no amount of large scale scrum practices that are going to help you be successful.

And so one of the big challenges I have with our industry is that is that we want to try to do practices first. And the big reason is, is because it’s kind of an easy button, right? We can get trainers to come in, we get coaches to come in, we can teach practices, but we don’t really have to make any hard organizational changes when we do that.

Does it work? Maybe it works sometimes. Maybe it works in pockets. But for enterprise class stuff, practices first is never, in my opinion, the right way to go. Obviously, the other thing I talk about a lot is the idea of culture first, that if we can get attitudes, mindsets, beliefs, behaviors to change, then agility will happen, you know, again, in the presence of dependencies and presence of large corporate systems and the presence, the presence of legacy monoliths, all that kind of stuff, it just doesn’t work that way.

So so that was like my core point. And then so the controversial the controversy statement said this tweet challenges the conventional idea of implementing practices first, proposing that systems structure governance should come first. So that was catchy and and what I thought was interesting is that based on all these large language models, it kind of agreed with me that this idea of practices first is an dede are conventional wisdom.

That’s what the preponderance of information on the Web has to say about it. And so then the rebuttal to that was while alignment of structure and governance is important, the emphasis on systems first could lead to an overengineered, inflexible environment, iterative and adaptable practices can drive effective, Agile Transformations. So what’s fascinating is in some of these responses that Chad GPT gave, I understand why they gave them, but if you look at what the what catch up is doing is it’s taking the information that is publicly available in effect kind of the general consensus.

And it’s giving me a rebuttal based upon the general consensus. And so like so the way that I would think about this is that is that, yes, if you put in a large scale static structure, you put in a a governance model that was inflexible, you could absolutely create a rigid hierarchy that was not responsive to change. But but there’s kind of like two different things that are at play.

When you’re talking about Agile, There’s there’s like the agility of the product backlog, the agility of the work that we run through the system. And then there’s the agility of the organization itself. So a lot of times in an early stage transformation, what we have to do is we have to put a certain level of rigidity in place so that we can demonstrate to the organization that any new Agile world we have the ability to make and meet commitments.

We have the ability to do what we say we’re going to do. The thing is, is we just do it in much smaller batches at the team level. We’re talking about user stories and sprints and releases at the program portfolio layer, the investment tier. We’re talking about much smaller batch sizes of features, EPIX initiatives, things like that. When you do that, you can tie all of that up into OKRs and KPIs and connected strategy and and get a really clear idea of how the strategy of the organization, the investment thesis, is being cascaded out and articulated into the organization.

So you come in with a lot of structure and then you you increase the ability to adapt by breaking things into smaller pieces and creating a system where we can kind of sense and respond a little bit more. Now, the approach that we take to doing this is we tend to start with like business capability models. We look at kind of the domain driven design of the organization.

We look at product model hierarchies, we look at the org chart and we create hypotheses for how we want to form teams around this notion of things that the business cares about. Now, what’s interesting is that for the most part, not every organization, but for the most part, the preponderance of things that the business cares about are not incredibly dynamic.

Okay? But if you go through this transformation. So in our world, Basecamp, one, two, three, four and five, we put a fairly rigid hierarchy in in the early days so we can make any commitments. But then as we start to, you know, systematically reduce batch and break dependencies and change funding models and then change, you know, go to market strategies and things like that, what we do is we inherently decouple the the in effect, the organizational model, the legacy technical monolith into smaller objects.

Now you think about if you want an organization that is resilient to change, it has to be organized around individual elements that can be easily changed. Again. It’s just like, you know, think about like a 50 year old COBOL mainframe system. If you want to change one small little thing or change, you know, some behavior of something in that system, it’s inherently coupled to everything else in the system.

Same things with organizations. So this argument that if we start with structure that it’s somehow going to lead to greater rigidity, I would actually suggest it is the exact opposite. If you lead with structure and you understand what it is that you want to encapsulate, which big things you want to break into, smaller things you actually create a lot more fluid in the organization so that you can take those objects and you can point them at new things, new opportunities.

When those new opportunities exist. Now you could say if if the total business model is being disrupted, then you know, would that would that cleaning strategy? You know, we get into things like, you know, do you just have people float across projects dynamically and stuff like that? Like if again, I don’t dismiss that there couldn’t be an environment where that level of fluidity was required.

I just know through our experience with working with a lot of Fortune 100 and some Fortune ten companies, is that is that that level of fluidity is not the norm. That level of dynamic resource allocation is not the norm. And I’m not saying you can’t go there, but you have to meet the organization where it is. And so again, I’m going to to make the assertion that chatbot in this case is actually incorrect because it’s based upon this general understanding that if we start with practices, then we’re going to achieve the right kind of agility, Agile practices on top of a legacy COBOL mainframe, Agile practices on top of a functionally siloed hierarchical organization are

not it’s not going to work right. The reason why we believe it will work is we say if we just start with the practices and the organizational and spec and adapt and it will, it will deconstruct itself into objects. I just don’t believe that to be true. Right? It’s very similar. And this is the this is the bigger point that I was going to make.

There’s there’s a lot of things and a lot of things being talked about in the broader IP product development context that I think are super interesting. And I’ve ignored a lot of these words because I don’t I don’t fundamentally like the buzzword bingo that we tend to play in our industry. And so like back in the day, you know, we had, you know, whether it be rational, unified process or scrum or say for XP or whatever, but before that critical chain project management, we had Lean concepts.

You know, Six Sigma was, was all the rage. Nowadays we’re talking about digital transformation, we’re talking about composable enterprises, we’re talking about product driven organizations, we’re talking about projects to products, all that kind of stuff. What’s interesting is I finally decided over the last year or so that I was going to start engaging with some of that language a little bit with our clients.

And at the end of the day, like what? What organizations are hunting is exactly this thing that we’ve been talking about. It’s the technologies are largely legacy monoliths. The organizations are largely legacy models. And so my belief is that the key to breaking up organizations, the key to composable enterprises are product driven or PTO or projects. The product is this idea of taking monoliths and breaking them into services or taking monoliths and breaking them into smaller products.

Right at the end of the day, if I want to do a successful digital transformation, if I want to do a successful cloud migration, if I want to do a successful air transformation, that’s something that’s being talked about right now. If I want to do a successful cloud migration, maybe I already said that. But any of these things that fall underneath that umbrella, it all comes down to how do you systematically take big things and break them into small things?

Because at the end of the day, what actually allows for agility is small groups of people that are organized around a technology that have a singular focus on us, on a particular kind of business problem. And then, you know, again, think services oriented architecture, think, you know, smaller abstracted products moved to the cloud. Right. And and what we’re trying to do is we’re trying to get the people and the process and the technology and like everything encapsulated into a thing, they can make independent decisions.

They can respond at the speed of market. And again, in these large systems. Right. What the problem is, are you got all these dependencies. And so the the process of moving to Agile is about taking big things, breaking them into small things, minimizing the dependencies and then orchestrating the dependencies that exist. And I’m going to make the argument over time that it’s the same for digital transformation.

Like anything that we want to do with new digital products, new digital strategies, digital channels, digital innovation is going to require these same kinds of loosely coupled, the same kinds of loosely coupled independent teams, typically using Agile but not required. But typically in Agile, it’s the decomposition of the big things and the small things that matters. It’s inherent in the word composable organization, composable enterprise with it basically means is that we have an organized may an organization made out of services and those services can be composed into higher order things that we want to sell to our clients.

It’s inherent in this idea of product driven organization. It’s inherent in this idea of projects, the product in order to do projects, the products you fundamentally have to have your organizational design organized around those products. And what does that mean? Taking big things, breaking them into small things. The idea here is that there is no way from here to there if we are only thinking about Agile practices or we are only thinking about Agile mindset, because at the end of the day, those practices and that mindset is going to go head on into like the skeletal system, the infrastructure of that organization, the way that it is structured, the way that it is governed, the

way that it is measured, is going to be totally orthogonal to the practices and cultures that you’re trying to get to. So you can start with practices and cultures and try to back your way into the structural elements. But what we believe is that if you start with the structural elements, you take the big things, you systematically break them into smaller things.

You work on reducing batch size and breaking dependencies and increasing local autonomy and giving those smaller objects some degrees of freedom. Through that core transformation effort, you get the fundamental underpinnings of digital transformation. You get the fundamental underpinnings of the composable enterprise. You get the fundamental underpinnings of the product driven organization. You get the fundamental underpinnings of a of a project to products type infrastructure, right?

You want to do product innovation, you want to do digital, any of this stuff. It goes way better if you have an organization that’s just built natively to support it, right? So the core is this idea of transformation, whether it be Agile, digital, composable products or otherwise. And so I’m going to go on record saying I think, Chad, GBP is wrong on this one and LeadingAgile got it right. So you guys have a great day and we’ll see you next time. Talk to you later. Bye bye.

When people say they have a culture problem that’s preventing them from sustaining change in an Agile Transformation, what they’re really saying is that they have a cognitive dissonance problem. You have an inability to help people see how Agile is going to improve the organization. Blaming people and telling them they’re being resistant to change isn’t going to close the gap and make that cognitive dissonance go away. So, you’re going to need a better plan of attack. Join Mike as he makes the case for why you need to stop pointing the finger and start fixing what’s really broken in the organization.

Video Transcript

Yes, we want the organization to become proficient in whatever we’re asking it to do. However, we must recognize that they are new to these concepts. As change agents, it’s our responsibility to meet people where they are and help them understand and transition into the new ways. Blaming them for resistance to change or command and control only reveals our own ignorance in how we approach the situation.

(musical interlude)

Is Agile Transformation a Culture Problem?

Recently, I composed a tweet for our marketing team, stating that if we align our systems and practices around our customers and markets, a culture of agility will naturally emerge. Agile is essentially about creating alignment and ensuring that everyone focuses on the needs of customers and end-users.

I’d like to delve deeper into this tweet and discuss the idea further. In the past, I used to emphasize that leading with culture alone might not be the most effective approach. Many organizations we encounter operate in functional silos, have traditional PMOs, and rigid governance and control structures. Simply advocating for a culture of agility in such environments may not immediately solve the challenges.

Imagine if we could magically establish a culture of agility overnight. People embrace the concept, are willing to change, and are eager to embrace agile practices. Now what? We still have a business to run and products to deliver in the next few months. We must be able to make commitments and operate efficiently. Simply having an agile culture without addressing the concrete practices and structures might not lead to immediate success.

Early on, agile discussions often revolved around culture, as it appeared to be the primary challenge in most organizations. However, the focus on culture alone could lead to frustration. People may resist agile practices, and we might attribute it to a resistance to change or leadership styles. But in reality, we need to consider the practical aspects of implementation and ensure that the entire ecosystem aligns with agile principles.

But, a lot of times if you really get up underneath it, what’s happening is that, is that the people that are resistant really deeply understand how the organization is currently working. Some of the most interesting conversations I have I’ve had over the last 13, 14, 15 years are with like hardcore security engineers or architects that are responsible for like a 50-year-old COBOL legacy platform, something like that.

And, you know, they’re being told, Hey, you need to do Scrum. And there they’re looking at that methodology in the context of the complexity that they are that they’re dealing with on a day-to-day basis. And there is a tremendous amount of cognitive dissonance because they can’t see how that methodology is actually going to solve their problem.

And then, you know, fresh-faced ScrumMasters right out of CSM training or something like that is like, no, you just got to trust the process. You just got to do it. It’s going to work and it’s going to be great. And they’re looking at these systems that they’re in and they’re going like, Yeah, I don’t see it right.

So again, just a tremendous level of cognitive dissonance. And so sometimes I think that we mistake cognitive dissonance or somebody’s inability to see a credible path forward as a culture problem, right? And so, it’s I’ve unpacked culture a little bit, right? So, so I’ve been doing this talk. I did it up in Detroit. I did it in Raleigh a few months ago.

And I start talking to people in the room about what culture is. And about half the people think of culture really in terms of how the organization feels like what the vibe is, and then part of the room. Maybe the other half sees it as like the behavior is like the default DNA, like how the the organization instinctively reflexes in the face of whatever’s going on.

Right? And I think both views of culture are the same. So, we want to have a good vibe. We want everybody to, like, come in to work. We want everybody to feel safe. And we also want the default behaviors to be open to change. And we want the mechanisms and the tools that we adopt to be incremental and iterative.

And we want people to think in small batches. And all these kinds of different things. So so just know that culture is a lot of things and its different things to different people. I read a lot of the books and I mean, I think there are definitive definitions, but as individuals, a lot of times we’re using that word pretty loosely.

And so when we say we have a culture problem, my hypothesis is, is that we as we often have a cognitive dissonance problem or we have a failure to create a clear path forward problem, which is really a cognitive dissonance problem. So, we really have a cognitive dissonance problem, right?

Overcoming Cognitive Dissonance in Large Organizations

So, a lot of times the way that I talk about this, it’s like I understand culture is a first order concern and a lot of these organizations, but it’s not like the first place to start.

If we want people to adopt Agile practices, let’s consider that the culture may be the problem. Perhaps the resistance is not driven by people’s integrity or value systems. Instead, it could be due to entrenched processes or cognitive dissonance. Some may struggle to see how the proposed changes will make a difference given the current state of affairs. In such cases, this resistance is reasonable.

Imagine a world where the business architecture, business capability model, domain-driven design, product architecture, and key strategies are in alignment. In this ideal scenario, the way the business, technology, and product organizations see the problem, along with the organizational design, all work congruently, with nothing working against each other.

The main idea is to organize systems and practices around customers and markets. If we could achieve alignment between technology, business, product, and organization, creating a composable enterprise or product-driven organization, the question arises: is there business value in it, and is that value worth investing in?

Having established that there is indeed business value worth investing in, the next step is to assess the current state of the organization and identify the gap between the current situation and the desired idealized end state.

The gap represents the cognitive dissonance. To address this, we can create a plan for incremental and iterative changes. First, we need to decide which parts of the organization to start with, and then plan for transition patterns in an iterative manner.

The question is whether making incremental and iterative changes, organization by organization, workgroup by workgroup, and team by team, would be worth investing in. The answer is yes, it might be worth investing in.

Now, the focus shifts to putting together an Agile Transformation Roadmap and timeline for implementing the plan. We need to create intermediate outcomes and measure progress. Additionally, it is possible to hold people accountable for the structural, behavioral, and process changes required for the transformation.

In summary, we know where we are, and we have a clear vision of where we want to go.

We know our initial conditions. We know our desired conditions. We have an incremental and iterative plan for getting there with outcomes-based metrics driven. We understand at least where we would like to be. We might get there, but we at least know where we like to be. So we have a baseline, and then we actually start making those changes, right?

And then as we systematically make the changes and start to adopt more of the Agile practices, what I believe happens is that over time the cognitive dissonance begins to lift, the resistance to change begins to lift, people’s openness to new ideas and ways of working begins to open up. Because now they start to see not only that you’ve acknowledged the gap, but you’ve also addressed their cognitive dissonance.

You’ve given them a plan for helping them to resolve that cognitive dissonance. And now, over time, they’re actually starting to see the new process practices and processes start to have a positive effect on the business. And then what happens is hearts and minds start to open up, behavior starts to change, the kinds of cultural things around, like your default DNA.

Your default behavior patterns begin to change, the mood begins to lighten, people start to become more empowered.

Meeting The Organization Where They Are

But I think part of the problem is that as Agile as we get really, really excited about where we want to be, and we want to get there overnight, and sometimes it’s a process. I’ll tell you guys a funny story.

I have Tim, our marketing guy, on the phone with me right now, and I just came out of jujitsu class with him, and I roll jiu-jitsu together, and we were working on some moves, and the instructor that was doing the moves was an expert, right? And he’s trying to show us everything all at once. And like everybody in the class is getting really lost.

And so, we were talking about at the end of class, like yes, we want the organization to be a master at whatever it is that we’re asking it to do. But we also had to realize that they’re really, really new to these concepts. So what we as change agents, were we as Agile as have to be able to do is we have to be able to meet people where they are with the level of skills and understand that they have, and it’s up to us to bridge them into the new world, pointing at them and telling them that they’re resistant to change or command and control or whatever, and actually exposes our ignorance in terms of how we’re thinking about things rather than inviting the people we’re talking about. So that is my encouragement to you guys. So if you’re in an organization that’s resistant to change, just align around a possibility, what might be true and then really get a clear plan together for how we might make that true and get agreement to maybe run some experiments and try.

Because if you can run the experiments in a way that really works and try, then you can start opening up hearts and minds. But this idea of saying, okay, it’s culture first, it’s everything or nothing, that just doesn’t work. It’s just not how people learn, and it’s not how organizations change. So, I hope you guys have a great day and look forward to engaging with you guys in the reply.

The Agile industry seems insistent that practices, agile methodologies, and frameworks will be how large organizations achieve Business Agility. But, the clients and companies we talk to seem to have a different opinion. Many of them are saying, “yeah, we tried Agile. It didn’t work.” And they’re looking for something else. Is the Agile industry in a rut? Everyone knows Agile works. We’ve seen it. For many, it just doesn’t work when they try to scale it. But what if we took the principles of what makes Agile work in the small, and applied that to the broader organization in a way that wasn’t so dogmatic about the roles, ceremonies, and artifacts of Agile? What if we descaled the organization and created the conditions for the practices to add value? We might find that a whole new world of possibilities opens up.

Video Transcript

So, there are two options to consider. First, you can choose to get started and clearly define what success looks like. Any obstacles that hinder success should be actively addressed and changed. However, in practice, often we find ourselves engaging in unproductive activities within the Scrum framework without truly driving organizational change.

Alternatively, you have the opportunity to assess the organization and strive to align it as closely as possible with the desired behavior and characteristics, even if it’s not perfect. It may not be feasible to change everything at once, but starting based on the right principles and practices is crucial. There is a middle ground between simply adopting Scrum and figuring everything out on the go, and the pressure of getting everything exactly right and flawless.

(Musical Interlude)

Defining an Agile Team

Now, although I’d love to delve deeply into Agile transformation and Agile at scale in each conversation, it’s essential to understand the fundamental building blocks of an Agile organization. The cornerstone of an Agile organization is an Agile team, and most Agile teams are structured around a combination of Scrum, Kanban, or other technical practices like XP (Extreme Programming). The Scrum Guide provides well-established guidelines for operating in this space.

Let’s briefly review some key reminders. The concept of a Scrum team typically involves around five to nine individuals, though variations exist. It’s crucial to have a cross-functional team that possesses the necessary skills to deliver increments of the product being developed. For a software product, this may include developers, testers, and business analysts, or variations depending on the team’s composition. The team operates based on a well-defined backlog and follows Agile practices such as estimating and planning, building in small, valuable, testable increments, and employing techniques like Ron Jeffries’ card, conversation, and confirmation. You can adapt your preferred user stories or use case scenarios accordingly.

But basically, what we want to do is we want to feed those teams The the features or behaviors that we want to be able to see in the software. So we’re not feeding them activities. Go write this database table, go build the screen. We’re doing things like user needs to be able to log in. And so, we have this backlog, we have this team, and that team needs to have the ability to produce a working tested increment of software at the end of every sprint.

It’s kind of like agile one on one. But what’s interesting, right, is imagine you go off to CSM class and you decide that you want to do Agile, but you come back, and you can’t form the kinds of teams that are necessary to be able to do Agile well. So, what do you do? Right? So what a lot of people do is they start taking their existing sting practices, their existing cleaning strategies, their existing functional silos, and they start to they start to do Scrum on top of that.

And a lot of times, you know, I mean, it might even kind of seem like it’s pretty cool, right? The team kind of gets likes getting together and doing daily stand-up meetings and like the visibility of the boards and they like the collaboration. Maybe a team room if such a thing exists. They like the big visible radiators.

All that stuff’s pretty cool. But at the end of the day, agility really comes down to can we continuously produce things that our customers care about so that they can get value from them, and we can get feedback? Okay. And so if we leave, if we if we lift that constraint off the system and we say, okay, we’re doing scrum on top of what I might call like a legacy ecosystem, again, we might get some value out of Scrum, but we’re not getting the benefits of being agile in order to actually get the business benefits of being agile, I have to create the conditions to be agile.

When You Can’t Form Agile Teams

Now, what’s interesting, right, and this is this is like a fascinating, I think, kind of human condition problem, right? So let’s say you’re you’re operating at the work surface on a team. Let’s say you’re maybe a middle manager and you’re in this organization and you report into a higher-level entity that just maybe isn’t as open. Maybe they said you could do Agile, but you can’t actually make any changes to the ecosystem.

The idea in adopting Scrum in that kind of ecosystem would be that you would have to get agreement on some level from those people that are operating above you on what the objectives of adopting Agile are. Do they want to be able to put things in market faster? Do they want to have a collaborative team-based environment? Do they want to create teams where like the value stream and the constraints are confined within the team?

Do they comprehend the principles of cost accounting versus throughput accounting? Are they inclined to deliver smaller batches to the market to gather feedback and allow for changes? Ultimately, that’s what Agile is all about. If there is agreement on these business outcomes associated with Agile, and Agile is implemented within the legacy ecosystem, the idea is that Scrum and Agile would expose the impediments. The Scrum Master or designated person would then take those impediments to the organization and systematically work to dismantle them. In a sense, Scrum would be used to build a business case for change.

Unfortunately, what commonly occurs in practice is that the team either fails to recognize the constraints or does not fully understand the impact these constraints have on their ability to deliver. They may also feel powerless or indeed be unable to make the necessary changes. Consequently, they may simply suspend disbelief, resulting in what is known as “Scrum in name only” or a superficial adoption of Scrum where the team lacks empowerment.

How to Get the Business Benefits of Agile

In my view, the only way to truly derive the business benefits of Agile is to pursue one of two approaches. First, gain agreement with the leadership team regarding the objectives of adopting Agile. Even if immediate changes cannot be implemented, starting with Scrum can reveal impediments. Through regular meetings, the team can explore the potential benefits of removing these impediments, building a case for justifying the necessary changes.

Alternatively, the Agile Transformation process can be challenging. Organizations often cannot halt product development for a year or two to undergo a complete transformation. It involves continuously making and meeting commitments, experiencing failures, identifying and systematically eliminating impediments. This can be a painful process. However, the basic rules of the game, the fundamental principles and practices of teams and backlogs, working software, are generally well understood and applicable across organizations, despite each organization’s uniqueness and specific business problems.

Ideally, in an organization, there would be alignment between the business capability model, domain-driven design, product hierarchy, product architecture, organizational design, and more, creating an idealized end state for an agile ecosystem. However, achieving this level of congruence from the start can be challenging. When transitioning from a legacy organization to a more modern, composable, or product-driven organization, it requires deliberate effort and adaptation.

That’s really what we’re talking about. There. And so that’s sometimes hard to get to on day one. But if we can get agreement that we’re going to have teams around different aspects of the architecture, different areas of the product or something, right, where those teams can start to operate with some autonomy, then we can start we can start putting those teams in place and they’re not stubborn their toes so much.

Right? We kind of understand the dependencies between those kinds of teams and we can orchestrate those dependencies. So there either has to be one of two things. You either have to say, okay, we’re just going to get started, we’re going to know what success looks like, and then anything that gets in the way of success, we’re going to be committed to changing again.

In practice, what typically happens is that we just kind of sit there and do goofy things in the scrum instead of actually changing the organization or you have the opportunity to take a look at the organization and say, okay, let’s get it as close as we can, get it to the behavior characteristics that we would like, understanding that maybe it’s not perfect.

We can’t change everything all at one time. So we get started, but we get started based upon the right principles and practices. So I think there’s something in between just adopting Scrum and figuring out everything as you go and having to get everything exactly right and perfect. If you understand the principles behind the TV strategies, right, the principles behind the back, like the principles behind the idea of producing working tested software and you thoughtfully look at your organization and make some decisions about how to get as close to that as possible.

Now, a little bit of a caveat is that when you have dependencies, you got to have some structures to manage dependencies. That’s where something like safe comes in. Safe isn’t my favorite thing. It’s not something I implement, but that’s the reason why SAFE exists in the presence of dependencies. You have to have a mechanism for orchestrating dependencies so we can give safe all the grief we want to give safe.

But if you’ve got dependencies, you’ve got to do something. I typically like wrapping collections of teams and in kind of a common type flow system, you know, wrapped up underneath some sort of portfolio level governance model where I’m flying epics in the portfolio of features through a middle tier command. And then they’re feeding user stories out of the Scrum team.

Not ideal agile, but in the presence of dependencies, in the presence of complex systems. Typically, you can get a lot of the business benefit out of it. So again, you guys have two choices. You either start doing Agile with a commitment to removing the impediments that are getting in the way of how that methodology is supposed to operate, or you take a thoughtful approach upfront and get it close.

By taking a thoughtful approach upfront, you can avoid unnecessary challenges and obstacles. This approach allows for a more effective implementation right from the beginning, even if it’s not perfect. It builds credibility and enables you to make more refined decisions, leading you closer to a pure-play agile ecosystem, which is the ideal environment we all aspire to work in.

That’s the key idea I wanted to share with you today. I hope it provides some clarity. If you have any questions or need further assistance, please leave a comment, and we’ll be more than happy to engage in discussions about the challenges you’re facing. Wishing you a fantastic day! Goodbye for now.

Join us for today’s podcast where we dive into the world of Kanban and Agile methodologies to unravel the thought process behind large organizations who want embrace Kanban. If you’re considering Kanban, or you’re currently grappling with workflow challenges, this video will equip you with some Kanban strategies to help you seamlessly implement and optimize Kanban in a dynamic enterprise environment.

Want to Listen Instead?

Contacting Tom Furland

If you’d like to contact Mike, you can reach him at:

LeadingAgile: https://www.leadingagile.com/guides/tom-furland/
LinkedIn: https://www.linkedin.com/in/tfurland/
Email: tom.furland@leadingagile.com

Contacting Dave Prior

If you’d like to contact Dave, you can reach him at:

LeadingAgile: www.leadingagile.com/guides/dave-prior/
LinkedIn: www.linkedin.com/in/mrsungo
Twitter: twitter.com/mrsungo
Email: dave.prior@leadingagile.com

If you have a question you’d like to submit for an upcoming podcast, please send them to dave.prior@leadingagile.com

Interested in CSM or CSPO Training?
You can find all the details at www.leadingagile.com/scrum-training/

Agile needs to be tied to business-driven results. If not, then we start measuring things like people trained, teams doing Scrum, or the organization’s sentiment toward Agile to tell us if we’re succeeding. But, in the absence of measurable business results, none of that matters. Agile is all about the ability of an organization to deliver in small batches, get fast feedback from customers, and quickly respond to change. If your Agile isn’t helping you do that, then it’s not really Agile at all.

Video Transcript

There are many people at the practitioner level who think Agile is about social aspects like engagement, interaction, and joy at work. While these aspects are important, they need to be linked to business outcomes. This brings me back to the topic I frequently discuss.

Whenever we witness Agile practices not working or see an engaged team that loves their work but still feels like they are failing, it always comes down to three fundamental factors. First, how are we forming teams? Second, how are we building backlogs? Third, how are we reproducing working tests in software? Additionally, we need to consider how we organize teams in the presence of dependencies, how we orchestrate and govern those dependencies, and what we measure and control around the team.

(Musical Interlude)

The Ultimate Success Criteria of Doing Agile

Over the past 13 years of running leading Agile, we often receive an intriguing phone call. The caller will say something like, “We’ve adopted Scrum, SAFe, or LeSS, but we’re not getting the desired business benefits from it.” This leads to a thought-provoking question: what does it mean to be doing Scrum well and still not achieving the desired results? When people make such statements, they usually mean that they have trained product owners and a proficient Scrum master, and their team consistently follows the cadence of sprint planning, daily stand-ups, interviews, and retrospectives. They may also be writing user stories, using burn-down charts, and practicing agile estimating and planning. Despite having the roles, responsibilities, ceremonies, and artifacts in place, they find that it’s not really working.

This creates cognitive dissonance for me. I question why they would implement a process that doesn’t yield the desired business benefits. It leads me to ponder what makes it challenging to achieve the business benefits of Scrum when they are indeed practicing Scrum. This dichotomy and separation of concerns often arise in conversations about Agile. Sometimes, I emphasize the importance of culture in an Agile ecosystem.

Certain individuals strongly believe that Agile is primarily about collaboration, team interaction, behavior, and how the team feels. While these aspects are indeed significant, I frequently emphasize that they are just a part of it. We also need to define the acceptance criteria of Agile. What is the acceptance criteria for Scrum? What is the acceptance criteria for SAFe? How can the business determine if it’s working?

The way I perceive it is that the business can gauge Agile’s success if the teams consistently and predictably release market-ready products in short cycles and regular intervals. These products should have well-architected, well-tested, defect-free code. The teams should effectively utilize their capacity, create opportunities for innovation based on new information, and build products in collaboration with customers to ensure the right products are being developed. Every businessperson I’ve spoken to considers this the ultimate measure of Agile’s success.

Some companies aim to engage their employees, modernize their methodologies, or improve their net promoter scores. They put effort into creating open and collaborative workspaces. While high net promoter scores and collaborative workspaces are beneficial, they are truly valuable when coupled with the ability to meet commitments to clients, receive regular feedback, deliver excellent products on time, operate within a reasonable and agreed-upon cost profile, build the right products, and disrupt the market.

The Problem with Going Through the Motions of Agile

When people ask such questions, they usually mean that they are going through the motions of Agile. They conduct Scrum ceremonies, have the Scrum roles and artifacts, or follow the Scaled Agile Framework (SAFe). They believe or have been told that by doing these things, they will achieve the desired outcomes. Unpacking this problem is intriguing as it delves into human nature. It’s similar to other significant topics such as religion, politics, or countries. Initially, these topics are vast and abstract, but underneath the surface lie scientific principles and thinking patterns that underpin agile methodologies.

Over the past 20 to 25 years, I’ve come across various books and resources that I believe people should read. The interesting aspect is that the early thinkers in the agile space were focused on uncovering the underlying theory of agile software development. Over time, these theories were transformed into practices, taught, and certified. However, as time passes, people tend to remember what they were told to do without necessarily understanding the reasons behind it. When you engage in practices without grasping the underlying theory, you may be led to believe that it’s solely the practice itself that generates results.

That could be that what you’re thinking or the other. The other challenge could be is that you’re doing the things that worked in one context, but because you don’t understand the theory or the underlying thinking, you don’t know how to adapt those practices to a new context. And so I think the challenge they were having in the Agile community right now and candidly for the last 20 years is that is that as certification took off and as interest gained, there’s a lot of folks that know the Agile stuff and they know the Agile words, but they’re not getting the business agility that they want out of that.

And because they’ve detached from the outcomes, a lot of times what they’ll do instead is attach to the practices or how those practices make them feel on the account.

Creating an Agile Culture vs Achieving Business Benefits

So sometimes people will tell me things like, Yeah, we’re doing Scrum really well, daily standards, reviews, retrospectives. We have a Scrum master, we have a product owner and the team really, really likes working this way and that’s a great thing, right? We want the team to like the way that they work. But if the methodology and the team’s engagement and happiness being at work doesn’t produce results that the business can rely upon, then then we’re kind of lost. And, you know, it’s interesting, right? I mean, I’ve been saying these messages for a long time in the marketplace, and I think a lot of people get it.

But I’ve gotten out recently and we’ve done some talks were up at Agile and beyond up in Detroit. We were at the TriAgile Conference in North Carolina talking about like the role of culture versus practices versus structure, things, you know, the things that I talk about a lot. And I still think just a lot of people at the practitioner level in particular, they think Agile is about these, you know, I guess like social Aspen folks, right?

The engagement, the interaction, the people, the joy at work and all of those things. And again, all that stuff is really important, but it has to be attached to the business outcomes. Which leads me back to the thing that I talk about all the time. Every time we see the practices of Agile not working, every time we see a really engaged team that loves what they’re doing, but yet still feels like they’re failing, it always comes down to those basic three things, right?

How are we forming teams? How are we building backlogs? How we’re producing working tested software, how are we organizing teams in the presence of dependencies? How are we orchestrating and governing those dependencies? And what are we measuring and controlling around the team?

Getting Your Agile Teams to Be Agile

And it’s our belief that you, if you want your agile teams to really result in business agility, like we actually want our Agile teams to be agile, then we have to create the conditions for those teams to be agile; decoupled teams of 6 to 8 people operating off of really clean, well-articulated estimated backlogs with the technical capabilities, the release capabilities to produce working texts that are increments of software at the end of every sprint.

And the challenges is that is that the you’re agile will never really result in agility if you’re not able to create those conditions. And so, Agile Transformation really becomes about the idea of understanding the constraints of the current environment, what kinds of things do we need to do now? How might we adapt our methodologies and what compensating controls do we need to put in place while we change the underlying conditions in the organization so that we can create the conditions to actually achieve agility?

Walking in with a two-day certification or a one-week SAFe certification, even lots of certifications and not knowing how to adapt those certifications into the current reality, or believing that doing those practices is going to create meaningful change is really causing a lot of problems in our industry right now. And so it always comes down to is that every methodology was designed to work in a particular ecosystem and the active transformation is not to introduce practices or tell people that they need to behave or think or feel differently.

Transformation is about meaningful change. It’s about changing the organization in a way that that enables or allows for agility to happen. And then we enable and support that agility with solid practices and good discipline and behavior. And then all of that great teamwork and everything and all that culture emerges out of that. And that’s the way it works when it works, right?

And and, you know, sometimes, you know, if you’re in a small work group, you start doing Scrum like everything’s really clear. You’re in a big organization and you’re a small team and you don’t have a lot of dependencies. But in the presence of dependencies, right, in the presence of a lot of organizational dysfunction, in the presence of legacy monoliths, in the presence of technology architectures and organizational architectures that don’t lend themselves to Agile.

Agile is not going to do a whole lot for you. It will actually cause you problems. So what we do at leading Agile, right, is we figure out where you are and where you want to be and help craft a very structured, disciplined, outcomes based, performance based transformation strategy. So that over time you can achieve the business benefits because that at the end of the day is what we’re after.

We want great teams, we want positive work environments. I’m a huge advocate of Scrum, huge advocacy. I think those methodologies can work and I think they do work quite often, but they only ever work when we’re creating the conditions for them to work. And that’s the difference between adopting agile practices and doing an Agile transformation. Transformation is about changing the underlying organizational design, governance metrics, strategies, right, that are going to lead to true Business Agility.

The same principle applies when considering cloud migration or digital transformation. It also holds true for concepts like a composable enterprise, domain-driven design, and a business capability-aligned organization. There is a convergence of thinking around the idea that big things need to be broken down into smaller components with minimal dependencies. In the presence of dependencies, it becomes necessary to address and coordinate them. Over time, the goal is to reduce dependencies, allowing teams to operate with greater autonomy. This is the underlying physics of the situation.

I strongly encourage everyone to reflect on this concept. Although not everyone may have the authority to make significant changes within their organization, I often ask individuals what they would do differently if they had the opportunity. By looking beyond the current constraints, you can begin to envision the changes that would make a difference. When you hold a leadership position and have the agency to drive change, you will possess the knowledge required to make a substantial impact.

Even if you’re not currently in such a position, you can still be an advocate for adapting Agile practices to make them effective, rather than rigidly adhering to prescribed methods without fully understanding how they should be applied. The key question to ask is, “How agile is your Agile?” If the Agile methodologies you have adopted are not enhancing your business agility or enabling you to achieve your goals, there is a way to address it. There is a plan available, which you can explore on our website or by reading our white paper. It’s not a secret; it can be accomplished.

That’s what I wanted to share with you today. If you have any questions, please reach out to us through our website’s contact page. We are always happy to assist you.

Mike Cottmeyer delivers his talk on building a culture of Agility in a large organizations at Agile & Beyond 2023. Over the course of this presentation, Mike explores what really gets in the way of an Agile Culture and explains why people and leadership aren’t to blame for the resistance to change.

You’ll walk away with a firm understanding of what conditions you need to create to foster the kind of culture where the teams are empowered to go off and do great work. Additionally you’ll learn how leading with empathy can create an environment where Agile is a welcome change instead of one where it’s met with resistance and skepticism.

Want Mike’s Slides?

Text CULTURE to 33777

As more and more companies scramble to untangle the code of their monolithic legacy software and get it into the cloud, strategic priorities are shifting. 10 years ago, it seemed that a little Scrum here and some coaching there would suffice. But as companies scale, as the market shifts and more parts of the business become software-focused, there’s been an increase in demand for an end-to-end solution to help large organizations build infrastructure around sound technical practices.

Today, Agilists must have a plan for incorporating DevOps practices into the early stages of Agile Transformation. But what if we told you there’s a whole class of DevOps considerations that no one is talking about that’s secretly killing your ability to unleash the potential of Agile? Everything from testing, monitoring, and containerization to vendors and the skills of the IT people on your team.

In this talk, we’ll look at what’s left out of the conversation and discuss five non-obvious DevOps barriers to Agility in large organizations. Join us as we explore these obstacles and how you can overcome them. Leave with an actionable roadmap for aligning your technical practices with the work of the Transformation that you can begin implementing today.

Want the Deck

Text HIDDEN to 33777

Video Transcript

We will run into times where packing software makes it harder for us to transform the skills of our staff and external vendors. So how do we handle transforming our company when a lot of the work isn’t done by people who are directly employed by us? Career incentives may discourage people from being agile, and then we ask them to be agile. We’ll also discuss the lack of automation.

(Musical Interlude)

Alright, let’s get started. I’m Matt VanVleet, the Chief Technology Officer for Leading Agile. I also assist a couple of product startups. I used to have my own consulting company and have been involved in Agile practices since XP and before the Agile Manifesto. I used to run a company that developed unit testing software.

Then I joined Pillar Technology, where I spent 18 years and eventually became an owner of the company. Currently, I’m helping out various companies, including Leading Agile, in starting a software studio and other ventures. As a consultant, I’ve encountered many impediments or barriers to Agile transformation. How many of you here are consultants? How many of you work in the industry? And how many of you are in the midst of an Agile transformation?

I suppose to some degree, we’re always in the middle of it. Anyway, that’s the introduction. I’ll repeat this at the end, but if you want the presentation deck, it’s available. Let’s check if the volume is okay. Can you all hear me clearly? Okay, great. Now let’s move on to discussing the five things that can hinder an Agile transformation.

The 5 Hidden Agility Killers

Of course, the transformation itself is essential, but there are some factors that can slow it down. I’ll talk about these factors and provide techniques to mitigate or overcome them, and then we’ll move on to the next topic. But before I present my five things, what do you guys think are the five impediments to an Agile transformation? I don’t remember if they’re mentioned in the abstract, so you might be ahead of me. Share your thoughts.

Alright. Some of these aspects are already on my mind when it comes to Agile transformation. We need to obtain buy-in, address ambiguity, and navigate the process. Additionally, we may encounter challenges with packaged software that make the transformation harder. We can discuss why that is and the impact it has on the skills of our staff. External vendors are another aspect to consider. How do we handle transforming our company when a significant portion of the work isn’t done by our direct employees? Career incentives are also relevant. Sometimes, we inadvertently discourage people from being agile and then expect them to embrace agility. We can explore this topic further. Lastly, let’s talk about the lack of automation and address its implications.

Dealing with Packaged Software

The first one, it came up, right? Different change cadences. The package is changing at one cadence and maybe you’re trying to innovate and change at another cadence, right? Type of tightly coupled integrations. So you may have a system you want to change, but it’s integrated with the package or you may want to change the package, but you’re worried about all the downstream systems, you know, so you can’t upgrade without testing the integrations, you can’t do the integration without involving the team.

You know, one of the things about Agile is we try to do the simplest thing that’ll work, put it out in the market, test it, get feedback and change it. So that iterative cycle is hard when you get it’s hard to implement half or a third of a package or just these three screens, right? Because it’s set to do a set of things.

Now it also can accelerate you. So it’s not that you never should use it, but making good conscious choices of when to use it, when not in understanding that if it’s in your most innovative areas, it may not be accelerating it. Right? So, you know, standardize what you want to fossilize. So if we standardize on a package, those are areas of the business.

We just want to work consistently the same way all the time. Right? If we’re in the auto industry and we’re going from, you know, traditional vehicles, battery electric vehicles and from a hardware-based solution to a largely software-based solution, we may want not want to standardize that. Just there’s a lot of packages for how you would run a car.

But as an example, you know, I was at a customer and there you know, we ended up having a lot of requirements where we knew this was wrong, but we couldn’t change it because we’d have to go change the package. And it was a lot of work. So we just had to figure out how to work around or keep going with it.

So those are some of the constraints. What I want to do now is talk about what are some techniques because it’s not like I’m saying don’t use packages. We’re just saying be conscious of it. Right. And understand that when you’re trying to do a transformation, if you have a customer development team building a mobile app and you have someone installing a package, you’re going to have to have slightly different techniques for how you do things right.

So one is you really want to double down on testing. So at the edges of the package, any interfaces, integrations in and out, you want to be able to have automation around that. You want to be able to mark things that aren’t available because now you can move the package, something moving at different cadences. You need to be able to upgrade one without having to involve all the other teams.

The first time you put the package in place is something that’s, you know, you can get all the teams rallied together and figure out how to do it. But now one side is upgraded and the other side doesn’t. You know, you don’t want to have to the start, things change, right? You know, you want to make sure that your version updates can be tracked and version control, which seems obvious, but a lot of times where things are configuration based and maybe the last script that you’re going into a UI, you aren’t able to see all the changes you made and therefore upgrading and downgrading and changing becomes created.

And then, you know, understanding the business capabilities and which ones need to move and be innovative and which ones you want to standardize. So you select packages in the right circumstances. Okay, So how many people are dealing with a mixture of cost packages and custom code in their transformation? So get numbers. Yeah, hopefully if you if you can encapsulate them and isolate them and deal with the fact that they’re working at different cadences.

And then after that, you have to orchestrate and just manage and have, you know, good, good communication and all of that.

Lack of Skills on Staff

All right. The skills of staff. So what how do you see that as an impediment to your transformation? Right. Yeah, I’ve been in environments where I said we wanted to have a team and, you know, over the years we have outsourced all of development.

So to have a co-located team of ten people, they just didn’t exist that were available for the project. So you definitely can have that right. So the transformation is about learning. So you may not have the skills, you may have to get the team to learn, and that’s why we like to keep teams in place because they learn how to form and act as a team.

I was, you know, it was kind of reminds me of like there’s something like 10,000 chapters of Harry Potter on the Internet that are aren’t written by J.K. Rowling. And, you know, all those people who are writing those chapters are at work during the day. And they’re managers saying they’re not very creative. So one of the things is that we’ve gotten to the stance where we’ve put people into a role and said, do it this way, do this, and we haven’t given them, and then they go get their creative outlet at home.

And now we’re asking them to exercise different muscles during their work day and so forth. Another thing to do is like a lot of people will go through this transformation but not change how they’re hiring. So now you’ve got someone who’s gone through a six month transformation and someone leaves and someone new comes in and you have hired four people that have that experience and learned.

So you’re still now those people are coming in to a team that’s working differently and they haven’t actually had the opportunity to go through that journey right? So looking at that. So the skillset thing can be while bringing in new people. Right. And you know, I has to give people time to make the change, to learn, right? So there’s times where we just won’t have the right skills.

We have to hire, find them. But there’s also times that we’re teaching our skills and we need to make sure that we embrace and do that. You know, I, I was once have asked, you know, you know, the client was looking for someone that had 7 to 10 years of this Java testing framework, which had only existed for four years.

Right. And so a lot of times were hiring based on years of experience or knowledge of a tool. But we’re in a world where, you know, you know, if someone says, I want you to have ten years experience which had GPA or a language learning models like that’s not going to exist, right? So the speed at which you can learn, the speed at which you can do new things is going to be something that we should be measuring versus current knowledge.

Obviously, there’s going to be times, you know, you need some basis, need some knowledge, but we really need to kind of be bringing in people with the right skills that have that ability to learn and grow with the team. I may have just said all this stuff on the last night, but, you know, we’re learning over and over current knowledge upskill staff to take advantage of new technical practices.

They’re going to be teaching them things like TDD and refactoring and, you know, building things in isolation, you know, the ICD. So you’re going to be you know, you’re going to have to invest and teach these techniques, but they’ll let you move faster with safety. And, you know, ultimately the thing that slows software development down is fear of change.

So if I go change something, I’m going to break it.

Then I may be afraid of change, that I may decide that we should build two copies of this code so that I don’t break the stuff that used to work. So so building with these techniques are going to let us move faster. But you have to invest in the skillset of your people so that they know how to do those.

So they’re able to, to, to do that. You know, a real job this year talked about their new roles need to become more cross-functional. You know, ultimately, I think there’s kind of two roles on a team. There’s people who know how to automate things, especially like a software development, and there’s people who know how to automate things.

They can build business rules into code, they can make, you know, screens, but they can also make automated tasks. They can make automated things that set up your environment, just people who are good at automating things and whether they’re automating, setting up your server or your deployment or your business rule or what have you, you know, over time, people tend to be able there may be specialists in some of those, but they tend to be able to do those.

There are also individuals who deeply understand the business domain. They interact with the customer, comprehend the customer’s needs, and communicate these to the team. They can evaluate something we’ve built and determine whether it’s functioning as intended. Over time, your business and technical experts may even become cross-functional if they work in that domain long enough.

Often, we begin with very specific roles: a business analyst, a developer, a product owner, a product manager. However, as you progress through an Agile Transformation, these roles may become more fluid. It’s crucial to create a safe environment for people to grow in their careers without feeling confined to their initial roles.

External Vendors Slowing You Down

Let’s consider external vendors. As a consultant, one might wonder why consultants could potentially slow down your transformation. Ideally, they should accelerate it. But how many of you work with external consultants? If you do, why might a vendor slow down a transformation? They need to understand your goals to effectively contribute to the transformation.

Some consulting models may want you to become dependent on them. They might offer a service at a low price, but then you need their support indefinitely. This can be problematic if we’re trying to automate something, like testing, and we’ve hired a large team from an external vendor for manual testing.

The goal should be to help clients become independent, not dependent. A great consultant will solve a problem for you, and then you’ll hire them to solve other problems. Your companies won’t run out of problems to solve, so there will always be work.

The question is whether the consultants are engaged in a way that will accelerate your Agile Transformation. If you’re aiming for product-based, cross-functional teams working collaboratively, but your vendors are merely order takers who don’t participate in the process, then they’re not supporting your transformation.

If your vendors are writing code that doesn’t align with your desired practices, it can also hinder your transformation. For example, if you want to use microservices, but your vendor is free to code however they want, it can create conflict.

I had a client a couple of months ago who I advised to not just train their vendors but engage them as partners. If they’re not willing to adapt, then it might be time to find vendors who are.

I was asked, “Who could that be?” and provided a list of potential vendors, including us and several of our competitors. The question arose, “Why are you suggesting we work with your competitors?” The competition isn’t between companies, but rather about avoiding incorrect practices.

If you’re embarking on an Agile Transformation, it’s essential to communicate this to your vendors. Ensure they understand that their work methods may need to change and that this transformation is strategically important. Treat your vendors as partners, especially if a significant portion of your workforce comes from them.

Invite them to join you on this journey and invest in the relationship. If they’re unwilling, consider other options. Often, the issue lies in communication or lack of investment from management, which can set teams up for failure.

Consider incorporating these aspects into your vendor contracts. Focus on measuring output rather than input costs and prioritize results. If you want your vendors to be collaborative, innovate, fail fast, and deliver results, your contracts should reflect this.

Ensure your incentives align with your objectives. Ultimately, you want vendors who are accountable for your business outcomes, just as you want your teams to align with the business needs. If your business isn’t getting what it needs, despite having a product screen, that’s not an ideal situation.

Misaligned Career Incentives

Career incentives can also impact your Agile Transformation. Does anyone have examples or thoughts on how career incentives can slow down your transformation? I once worked with a group where we wanted developers to receive test cases early so they could address them before they entered the queue.

They were reluctant to do this because they feared it would eliminate bugs. However, the goal isn’t to have bugs. They were accustomed to a process where they would examine the requirements, build, and then test. This was more of a blind test rather than an open book test. But they were different departments, each with their own metrics.

I’ve also encountered a consulting company that believed moving to Agile meant eliminating QA. I’ve always argued that if we stop finding things, there will be plenty of other areas to explore. If there’s an incentive that encourages this, it’s problematic. We should encourage and value flexible roles.

You might not be a pure QA person; you might also work on requirements. Are your training, measurement, valuation, and promotion systems set up to accommodate this? If you’re transforming how your teams work, you may need to reconsider how you measure your teams and success.

Do you value people being subject matter experts or technical experts? Or do you need to move outside of the team and take charge of scorekeeping or orchestration to be valued? We’re trying to create teams that can align as closely to the customer as possible and produce results. We’re building teams with as few interdependencies as possible. However, our leadership structures and incentive systems might actually discourage team collaboration.

Early in my career, I was offered a promotion to a managerial role while I was a technical consultant. I wanted to remain technical for longer in my career. I was faced with a choice: stay in my role without a pay increase, leave, or become a manager. There was no technical career path available to me. So, I left and started a company that wrote software, which allowed me to stay technical. There are opportunities for those who wish to remain technical. For instance, I know of an automaker in town that has a technical career path in engineering for vehicle powertrains.

In some organizations, there are ten levels of engineers, with senior leaders having hands-on experience in building powertrains. On the software side, technical levels only go up four levels, and senior people are experts in orchestrating and navigating the system, rather than being expert technologists. We want to change this and encourage teams to grow and value leadership.

This has to translate into teams delivering more value and being more connected. It’s crucial to review the career path and ensure it doesn’t encourage people to leave your teams. Also, review performance measures. Are you measuring output or input? Are you counting defects or assessing the quality of your system? Can we measure how well the system is designed to meet customer needs? Are we measuring customer fit and satisfaction, rather than arbitrary count of velocity at the development team level, or the number of defects found, or tests run?

Lack of Automation

Why would lack of automation can impede your Agile Transformation. Automation can increase consistency, reducing mistakes, and can also increase speed. However, sometimes there isn’t enough time to invest in things that will make us faster. This could indicate that we’re moving so quickly that we’re not going to get significantly faster.

If you increase the frequency of releases and deployments, it’s going to cost more unless you automate. For instance, if you shift from releasing every six months to every two weeks or four weeks, the overhead of a release will increase. If you believe in weekly sprints and build every week, the cost will rise, especially if it takes three days to deploy. However, if you automate the most frequent tasks, the cost can be reduced. There’s a saying: “Take the hardest things and do them as often as possible, and they get easier.”

It’s hard for the organization to build it. It’s hard to deploy it. It’s hard to get to QA if it’s hard to get customer feedback, let’s do that more often. Let’s figure out how to get the cost out of there, because building it should only take as long as running the build strength. Deploying should only take as long as its place.

Yeah, but if there’s people, you know, if it’s a three-day process to get the QA know. So manual testing now there’s always a level of exploratory testing. Right. There are people what you want to do is I remember I did a project right past Y2K and we had 30 people whose job it was a test and they had you know, it took them two days and they had a set of manual scripts and they would go through and they would test it again and again and again.

And we still get in production and people would find the odd circumstance. Right. And we got to the point where we said, well, why? Let’s get that stuff automated. We got that stuff automated and we didn’t have the 30 people anymore, but we had ten or 12 and now we run the automated tests. And if there was a problem, they go tell us why, what the problem was.

But they just tested. And they would find the anomalies and the things you didn’t think about because they were able to use. You do that. We kind of got rid of the mundane stuff and they did. The more, more creative or more exploratory type testing. But the same thing with, you know, build even like you have security and compliance.

We had to do a penetration test. Well, again, let’s build into our build process checking for the known vulnerabilities so that our security people can look for the things that we don’t know. Right? We know that you should never write SQL code this way. Okay, then let’s just make it impossible to get that into the repository or into production and have them looking for the things we haven’t thought of.

Right. Or some of the more the things that are new are harder to automate. So, if things are hard, you know, do them often and automate them if you expect people to grow. So, another big thing we find is we’ll go on the projects. And we went on to a project just earlier this year and they assumed it would take us 21 days per developer to get up and running with our laptop and being able to build the system and run it, which seems like an enormous amount of time.

And it took our first person that long and but they write everything down in great detail by the third person coming on. They had most of that automated. So now if you needed to set up an environment, it takes about two days and there’s a set of manual steps you have to do. But it’s not like a million people join the team, so it’s probably not worth automating the last parts of it.

But just looking at that and having people whose mindset is, well, how do I get rid of all of this stuff? Because what you want is the value density of your software, the amount of time what you’re building in your software are things that customers are actually going to use. So it’ll go up, right? So that means the amount of time it takes to build, the amount of time it takes to deploy, the amount of time it takes to set up a laptop, the amount of time it takes to wait on another team that you’re depending on.

We’re striving to eliminate unnecessary tasks and focus on building what customers want. As customer needs change, we’ll continue to adapt. Automation plays a significant role in this process. I had a client who didn’t see the value in automated testing and viewed it as a cost. During a meeting, a department suggested changing the data handling process, but we weren’t sure if this would break the system’s rules. The client suggested using our automated tests to see what would break if we implemented the change. We ran the tests, identified four areas that would be affected, and were able to move forward. Automation provides the safety net that allows us to change more frequently and quickly without fear.

Alright, so that’s my deck. If you need to, you can get it by texting. And now I’ll open it up to thoughts or questions.

Q&A with the Audience

The promise of Agile is increased responsiveness to the market and faster software delivery. However, if it currently takes nine months to release and we want to do it monthly, but testing takes two or three weeks and deployment a few days, we won’t actually deliver more software in nine monthly releases than in a nine-month chunk unless we automate away much of the overhead. The goal is to spend as much time as possible on tasks that customers value.

The biggest impediment is often miscommunication. We’ve discussed communication with vendors, but it’s essential to communicate effectively with everyone. If a team is trying to transform and the surrounding teams are unaware, or if a team is told to transform without understanding why or what the new expectations are, problems arise. If leadership isn’t communicated with effectively, it can also lead to issues.

Communication is indeed a significant barrier. Trust is another crucial factor. We’re trying to build trust with the business by showing them progress regularly. If we consistently deliver what we promise in small increments, they’ll trust us with larger tasks. This principle applies to transformations as well. Demonstrating better results incrementally can build trust and create more opportunities.

Being able to measure and communicate progress is essential. If we can avoid building something the wrong way or if we become more efficient and need fewer developers, we can pay our team members more while still increasing output.

Leadership changes can also pose challenges. If new leaders don’t understand the journey we’ve been on or the way we’re developing software, it can cause issues. They need to understand the metrics for output. Dennis Stevens gave a talk about trust and how to communicate with executives about Agile. It often involves communicating in their language and continuously re-communicating as leadership changes.

There’s no shortage of constraints on your transformation. The key is to get feedback as often as possible, communicate effectively, and eliminate dependencies. Automation helps eliminate dependencies in software building, as does having a well-rounded skill set within your team. Most problems will likely be related to dependency, communication, or skill issues. Thank you.

What do we have to do to make Agile tangible for our executives? How do we get our executives to have more confidence than fear in the changes we’re trying to make? There’s a reason they don’t move with us. They don’t understand it, they don’t trust it. And by not addressing the factors that are required to build trust, we’re making it more difficult for ourselves.

Are Executives Getting in the Way of Agile?

When I was seven years old, we moved from Huntsville, Alabama, where my dad was working on the Apollo missile systems. My dad is a rocket scientist, and we went to Georgia Tech, where they had installed a nuclear reactor. That nuclear reactor had a PDP-8 computer from a company called Digital. Have you ever heard of Digital? It’s an old, old company.

At seven years old, I learned how to program on a PDP-8. It was attached to the nuclear reactor beneath the university campus in downtown Atlanta. I thought it was unreasonable that Dr. Harmer and my dad wouldn’t let me load the tapes that contained the programs into the computer. I thought I could do it. I was writing programs and could load data. It was cool, using paper tapes instead of cards because they didn’t have digital tapes back then.

Looking back, I realize there was probably some rational thinking on their part for not allowing a seven-year-old to arbitrarily load programs into a computer attached to a nuclear reactor. Did that make sense to you all? At the time, it didn’t make sense to me, and I couldn’t explain to them why it was important.

Later on, when I was in the Marine Corps, I found the rules imposed by my superiors to be ridiculous. I questioned why there were so many controls and regulations. But it turns out, those rules were actually quite important. When you put a 19-year-old in challenging and chaotic circumstances with significant responsibility for people and equipment, rules are necessary.

Does that resonate with all of you? As I grew into a professional and thought my bosses were absurd, I realized I am completely unemployable. That’s why I’m part of a company I helped found. We learned over time that there is a reason behind all those seemingly ridiculous rules when you’re the boss of a company too.

One of the challenges we face is the perception that executives don’t care about Agile. There’s a belief that executives are the number one obstacle to successful Agile transformation in organizations.

Have you all heard that sentiment in the community? Managers are evil. They intentionally try to destroy our ability to perform. But is it possible that there may be reasonable and rational behaviors behind the actions of those executives, managers, and people who obstruct what we’re trying to do? Do you think we should consider that perspective? It’s an important thread for us to follow because I don’t think we always pay attention to it.

In fact, at conferences, we often talk about how managers are bad and executives are foolish people who want to derail the company. But that’s probably not true, right? So what can we agree on? Organizations need to move at market speeds sustainably, and that pace is getting faster and faster. We agree with that, don’t we?

Old ways of working won’t solve it, and simply implementing practices like Scrum, DevOps, FinOps, or ProOps are not sufficient to create the organizations we need for the changes we must make. We need executives to buy into doing things they might not be comfortable with. Alright, with that in mind, let’s consider that executives are not intentionally trying to make you fail at your job. Do you believe that? Or does it feel that way? It varies, right? It’s a sliding scale.

Now, let’s explore why executives may not participate in our transformations or why they obstruct what we’re trying to do as we strive to build organizations differently. What experiences have you had with executives getting in your way, and what might be the reasons behind their resistance? Lack of understanding, too busy, concerns about cost, fear – these are all valid considerations. We need to speak their language, understand their different experiences, and address their concerns. Our goals and their goals may not be aligned.

So, who is responsible for closing that gap? Is it their responsibility to come to us, or should we participate and try to move them in the right direction? It’s a shared responsibility, don’t you think? We cannot simply claim that managers are evil or executives are foolish. That won’t bring them closer to us. Instead, we need to consider how our actions, conferences, and the literature we read can either bring them closer or push them further away.

It’s up to us to take ownership. So, based on what we know, what doesn’t work at this point? Have any of you tried to get executives to follow your lead, but they haven’t? Can you share an example of something you’ve tried that didn’t work? Let’s identify what doesn’t work. Remember, our actions play a significant part in this process.

It’s crucial to get the executives to stop thinking that way. Yeah, we’ll have a chance to discuss it further towards the end. Now, let’s talk about why estimating in hours is absolutely critical for what they’re responsible for and what cannot be done without it. Yep, speaking in a high-level manner, this is their mindset at this point. You mean they care about achieving profitability?

Yeah, I like this one. Just trust the teams. Yeah, they should just trust us, give us everything we need, and have faith in us. That’s what the Agile Manifesto says, right? How about we let the teams decide how to work? No controls, no accountability. However, it doesn’t make me feel entirely comfortable, especially considering the Equifax data breach a couple of years ago.

Alright, you’ll get what you get when you get it, right? Shareholders don’t care, markets don’t care, customers don’t care. Just work as hard as you can, and I’ll be completely satisfied when it’s done, right? Here are some books you need to read, try this article, attend this conference, or go to this two-day course. We need all of you to embrace agility yourselves. Start doing stand-ups and think the way we do. We need you to change your behavior, right

But do any of these things actually help us solve the problems that executives present? They mostly assign blame. Yeah, that’s what’s interesting.

How to Get Executives to Buy into Agile

What do we have to do to make Agile tangible for executives? How can we instill more confidence than fear in the changes we’re trying to make? The reason they don’t move with us is that they don’t understand it, and they don’t trust it. Moreover, by not addressing the necessary elements for building trust, we’re making it even more challenging.

We need to have deep empathy for the issues and problems they are trying to solve. We must understand what matters to our managers, directors, and executives. We need to have a point of view and show them how following our model will help them achieve more of what they need. Let me ask, are you all familiar with the ladder of influence? It’s a useful tool that explains how people act, what they believe, and what experiences and data they have.

We can’t argue with them at the level of what they believe. Saying “You’re wrong” or “No, I’m right” won’t resolve the disagreement. We need to delve deeper, understand their beliefs, and then present a reframed perspective of what might be possible if we try something different.

So we need to take their beliefs into consideration. If we don’t start with what they believe, we won’t make progress. Once we have reframed their point of view, we must create a high level of safety for them to engage in conversations about what we might try. We need to work our way up a path.

Now, I’m going to discuss four elements that I believe are crucial in that conversation to gain permission to try something and how we can earn the opportunity to attempt something more significant. It’s not a one-time switch; it’s a gradual process. I’ll provide you with valuable insights if you stay tuned.

Executives aren’t solely focused on delivering software to customers. They deal with numerous complex problems that often conflict with one another. Regulatory compliance can clash with speed, and having strategy goals and budgets that we can communicate to the markets and achieve may conflict with the need for continuous learning and adaptation.

Let me share an example. I had a client who used to say that their clients start growing in March, but they start selling in July, and the contracts begin in March. From the moment we start marketing, there is no optionality because people begin arranging financing, making purchases, clearing their fields, and preserving cash to prepare for the next season’s release. We can’t just say, “You’ll get it when you get it.” If we make a commitment, we need to fulfill it to make sense.

These problems are highly intricate. Our technologies often impede our ability to achieve our goals in infrastructure and operations. That’s why some people within your organizations may resist implementing DevOps. We haven’t created a safe environment for them to operate in. They have the responsibility to protect something that may directly conflict with what we’re trying to accomplish. It’s important to consider the bigger systems and all the concerns that come into play when we’re looking at Agile, Scrum, or solving small problems. We shouldn’t overlook the broader view.

When facing these challenges from an executive, manager, or leader’s perspective, it’s crucial to understand all the issues they’re addressing and where conflicts may arise. It’s also important to recognize that, like us, most of these executives are striving for promotion, bonuses, and taking care of their families. If they put themselves at risk for us and we fail to deliver, their personal interests are jeopardized. So, it’s a big win for everyone when we succeed. However, if we naively approach the situation without first putting ourselves in their shoes and considering the complex view they’re dealing with, we won’t be able to gain their trust and move towards a safer environment.

I find it fascinating to consider the big picture and all the interconnected pieces as we engage in these conversations. So, the first step in thinking like they do is to genuinely care about what matters to them. Executives are responsible for three broad areas, although there may be more, but let’s focus on these three for now.

Executives have a primary responsibility to generate revenue for the company both now and in the future. They are accountable for fulfilling commitments and getting paid for what they were hired to do. Making money is of utmost importance for the success of the organization in the marketplace. Executives are focused on acquiring customers, growing market share, and increasing brand awareness. They care deeply about the overall health of the firm, although it may seem challenging at times.

However, we often fail to provide them with answers on how to resolve conflicting concerns. In fact, many of the transformations we propose seem to jeopardize the organization’s health because we haven’t demonstrated how we can transition to a new state while maintaining or even increasing safety. We need to be more thoughtful and not simply assume that we have all the right answers while disregarding their perspectives.

To bridge the gap, we must truly understand and care about what executives prioritize. If we can establish a connection between our efforts and incremental, iterative market sensing, and sustainable adaptation, we stand a chance. We need to demonstrate how our approach aligns with their goals and addresses their concerns. If we can’t achieve that, we won’t be able to have a meaningful conversation. It’s crucial to recognize that without this alignment, our efforts will be futile.

Demonstrating the Benefits of Agile to Executives

So, how can Agile help us accomplish the objectives on the right? Let’s consider predictability. When we walk in and claim that estimating is impossible and we can’t determine when we’ll deliver, it won’t resonate with an executive who is responsible for making promises to the market, customers, and their own family regarding bonuses. We must be able to deliver what we commit to, as scheduled. Incremental and iterative delivery, gathering frequent feedback, creating options, and adapting early are essential for predictably delivering large and complex projects.

Allow me to share a story from my experience. I once worked with a large agriculture company that aimed to implement a software solution for their tractors in March. However, our project started in July, and a couple of months into it, I had to break the news to the board that we couldn’t fulfill their market promise in the intended manner. Nonetheless, I presented them with three alternative options that would meet their expectations. I explained that the desired outcome was scientifically impossible to achieve before March due to the intricate technical requirements. I provided viable alternatives, but one of the board members named Lyle responded by spinning his glasses on the table and stating, “I knew this agile stuff wouldn’t work here.”

By understanding the concerns and priorities of executives, we can better align our Agile practices with their expectations, demonstrating our commitment to delivering results in a predictable and dependable manner.

We never have these types of problems with our traditional projects until they’re 80 or 90% of the way done. So following my advice of not condescendingly scoffing at him and laughing so I could actually encourage his engagement moving forward, I said, I think we’re in a better place than right. And he thought about it for a minute. In fact, we moved forward.

He actually laughed about it later. He felt stupid saying it, but it was actually what popped into his head in the moment. Right, Right. I knew early that we were going to fail. We had driven down risk early. We had done it the way that we thought it was possible would fail. And I gave him some options. Now, who wouldn’t rather have that in their pocket?

Then going dark for nine months and coming back a week before it’s supposed to ship, we have a customer. I just flew back from Brussels Monday. I’m not even sure what day it is was today. Tuesday. I flew back Sunday from Brussels and one of the challenges they had, what they had a product that was supposed to launch and they found out two days before the launch $30 million of market branding in place that it’s a six-month delay.

Do you think that was knowable a little bit earlier on? Some optionality could have been created around it? Yeah, right. But because the way they’re running their stuff, they didn’t know. So predictability is critically important. Quality is critically important. We get better quality out of Agile because we test it more often, We do it more frequently. We understand the math and the science of smaller batch validation.

Is that a giant last minute validation? It kind of goes to the options and predictability side of it. So we get better quality out of Agile when we do it well than we do when we don’t. But if we go in and we try to sell automated testing and test driven development and pair programing and DevOps and test data automation, all those sort of things, those aren’t interesting to an executive, but improving my quality so I can make more money or be more successful in a market, have options in performing or increasing the health of my product, we can connect it there.

So these are things that I can create. This is a way more compelling story from an executive standpoint in every regard or from a management standpoint. If you try to get somebody promoted, you can go have these conversations and we can deliver on it. It’s a way more compelling conversation. Then tell them they need to have small teams or care about each other more, or all the Kumbaya stuff, which is critically important and matters.

I just went to systems of systems of compassion, totally agree with the concept on the content, totally agree that we have to design organizations to take care of our people. Right? But when we’re actually going and setting our teams up to fail, we’re not doing that, are we? We’re not building systems that executives don’t trust. They’re not going to be built systems of compassion to understand the systems of domination sort of model, right?

These things are all connected. So we have to get people to believe what matters. But at the end of the day, these things matter. So care about what they care about.

Speaking the Language of Business (Metrics, OKRs, and KPIs)

Speak their language. What is the language of business? Money. Money. It’s actually interesting. You know, 50 years ago. Oh, no. And some people are saying the language of business is the customer’s language, which I think is cool.

And it’s been it’s probably true and probably accurate, but it’s not what gets moves in most organizations. But I think it still matters. So I’m going to say down here, the language of the customer and market success is still critically important. But if if you do that, you don’t make money, you’re not going to move the organization. So these two things have to be connected as well, right?

So if we can do Agile and we can deliver more frequent to our customers and deliver more of what our customers want and less of what they don’t and have the ability to respond to market changes, they’re coming. We can increase the revenue for the firm. We have the will to make that connection end to end. So speak the language of the business.

We can do that through strategic objectives and OKRs and KPIs and things like that. How many of you all are doing like, okay, our work? Oh, fewer than I thought. It’s interesting how many people are doing like KPIs and measuring KPIs in your organization at the same hands. Pretty cool. How many of you all don’t have a way of measuring the ability of the organization to improve, to do a better job of making money?

What if we walked in and said, Here, here’s what is possible, right? We start talking about how we can keep track of the stuff in the changes we’re making. We connect it to more revenue for you may not be a perfect connect the dots. Maybe, but I can show you a model that will work consistently. Pretty interesting when we talk about productivity work in the system.

So we got market success, work in the system. Here’s how much we can produce in a period of time. Here’s how much we can produce in the next period of time. The things that you’re asking me to do, well, either increase the number of things that I can produce in that period of time or reduce the number of things I can produce in a given period of time.

Like that’s a conversation that you can have with an executive that’s meaningful. They’ll look at it and they’ll go, I’d like to produce more things for the same number of dollars in the next period of time. Well, these things will help you get there. Then we can measure it, improve it, face up to our productivity, our efficiency numbers.

I can reduce your risk of missing your mark. I can reduce your risk of building something a customer doesn’t want. I can reduce your risk of missing a commitment to the market. I can create tremendous transparency and optionality in the system to you to deal with the uncertainty in the marketplace. That’s what we’re doing with Agile. How many of you all are talking this way to your executives are making these types of moves or have an opportunity to have these conversations?

How many of you don’t think you have an opportunity to have these conversations in your firm around this stuff? And we say enough opportunities? Well, I think it’s interesting. Yes. So you can you can do in a small circle, but you won’t be able to do it in a bigger circle. It needs to happen in an even bigger circle to get some of the changes that we need.

So the plan over time is to figure out where you can operate, where you can have these conversations, make this available, leverage your partners level, leverage the the director is an executives and vice presidents that you’re working with. Help them be successful. Give them the ammunition to tell the story bigger and bigger and then deliver on it every single time or most of the time.

CapEx efficiency. Transformation. We’re going to make the output, we’re going to make the system work better. We can have less rework in it or have less overhead in it. We’re going to get things to the market with fewer non-consumable features, non-performing assets being deployed, not going to build stuff. You have to throw away as much. I can actually increase your balance sheet value with this model.

We can elevate the competency of the people in your organization demonstrably through our transformation, and that elevation of competency will result in better throughput. Your ability to achieve better strategic objectives and eventually connect to more revenue if your strategy is correct, this path making sense. So talk about what the business cares about. None of this is about Agile or Scrum or stand-ups or product ownership or DevOps or that stuff.

Right now, we have to get there and you have to know in your mind how you’re producing this. But every slice of promise we make has to be wrapped up in a bit of a business case.

Creating Safety & Coming Up with a Credible Plan

Create safety for your executives or your vice presidents or the directors that you can influence. And we create we align on purpose as the first step of creating safety because we’re not going to get to do anything if they don’t feel safe about it.

The risk of not moving has to be greater than the risk of moving. The fear of being static has to be greater than the fear of trying something new. Right? So what do we do? First, we agree on a purpose. How are you going to be able to prove what you need to prove with this move we’re about to make?

How are we going to do this in a way and tell the story around it? So when you’re done with it, it looks like we were successful in one of those top two stories. When you do this thing where this result and you’re going to look smart because we did it so aligning on purpose, devise a credible plan that I support.

Credible, right. That’s good. That’s good. It felt wrong at one point. I’m sure it was scary. The delight wouldn’t type a word Iran. So she wrote I typed in wrong from theory, but devise a credible plan. I hear a lot of conversation about agile should be organic. It should be bottom-up. We don’t know what is going to happen.

It’s a chaotic system. It’s a complex system. You can’t plan or predict things that just isn’t really a viable approach if you’re trying to get your boss to step into it. So what you have to do is you have to scope the change you’re going to make down to something. You know, you can commit, get a purpose of what you want to solve for to a small enough slice so that you can do a credible plan, come up with an answer.

We think about 90 days, 220 days. It’s about the horizon. You get to prove something in an organization, a relatively small slice, and it can’t put the entire organization in jeopardy. So what’s a relatively small thing look like? What it look like to be successful there? And then what does it look like? How would I check in every two weeks to make sure we’re making progress in it?

You know what’s interesting to me about this approach? So a lot of the executives you’re talking to are product people or business people and product people. And business people get this when they’re trying to sell something into the market or get a customer to move. Right, or change the relation with a vendor or supply chain, they get that you don’t know the perfect end state.

You can have a conversation how you want to shape this and move with them to Here’s what we think we have to do, here’s what we think we’ll get there. Here’s the plan I’m going to put behind it. Here’s our going to measure it, keep track of it, incorporate feedback. We’re going to learn as we’re going. We’re going to be able to get feedback from you if you think we’re off track or feedback for you.

So a cadence of reviews of the moves that you’re making and whether you’re getting progress or not and what you’re learning and what they’re hearing, keeping your executives or whatever level you’re working with involved in the shift that you’re making, because it’s got to be their play, not just your play or have them participate in it. You’re getting their feedback, then connect actions to their success.

The things that we’re doing produce this result, and that result was we won the thing that said we would win and we get more influence. So this kind of talk about the influence trust cycle, if you’ve ever seen that got some talks on I thought about putting their bets a whole hour talk on its own. We’re sort of walking that trust cycle, influence cycle because you got to earn your way up the influence cycle and then help them see how they contribute to the success and engage them in the pride.

Pride progress towards the goals. This is how we’re getting our executives to buy into where we’re heading and what we’re doing. So there’s a process you can put in place. And here’s something you guys kind of know. It’s a backlog with an objective slice up and relatively small slices with some really clear acceptance criteria where the team has together a plan and delivers, it demonstrates the value, gets feedback from the stakeholders.

You understand this model. You don’t know that your organization is a product and that you’re going to manage your stakeholders same way that our product and executive people are managing customers. So think about it that way. You understand this process. It looks scary, but it’s what you do. Here’s what’s interesting to me, by the way, and I struggled with this for a while.

I think that if you don’t understand that Scrum is a change management for your customers model incremental delivery with lots of feedback cycles, Is it creating safety for your customers? Model that’s really hard to coach? Scrum Well, it’s really hard to get into an organization and get them to move. We’re just going through the mechanics of it, but if you deeply understand that it’s a social thing that we’re doing as much as a technology thing, that’s why Scrum works when it works well and it’s why it doesn’t when we don’t know that’s what we’re doing, right?

It’s not the mechanics of it. It’s the creating safety for all the people involved. The team has some safety. They can stay in a box, get it going to get your product quality, customer has safety. We’re not going to run down the road and disappear for nine months and come back with something they don’t know. We’re not spending money wildly and not knowing where it’s going.

Scrum and Agile creates a lot of safety for people. We’re going to do the same thing with our change approach going to executives to buy into the moves that we’re making. So kind of cool. Y’all are really good at this already and then demonstrate results. We said we were going to do it. We showed up, was got to tie together.

We connected together, paying attention all the time to what you’re measuring, improving so that your management of the change or making progress on the roadmap. Here’s the work that we’re producing. Here’s the options we said you would get. Here’s the data. We said you would show. Here’s some simulations or examples are producing the type of thing that we said we would.

So managing the change and the connecting to value and look, we move this, okay? R And look, the customer bought that and look, we reduce this cost and look we had the lower quality. So when you’re planning that plan upfront, when you’re doing that reliable plan, you got to be making a plan about something you know you can deliver within the scope you have agency for because the goal is to work your way up.

And what’s interesting is you won’t have agency upfront to do all the things you want to because you’re executives won’t give it to you, but you can’t go tell them to give it to you until you prove that they should trust you with it. So we’re building up trust over time by making this be real and actual to them.

We’re letting them understand the changes that we’re making. So the reason your executives won’t trust you is because we haven’t given them reason to trust us in this work, even though we may be exactly right, but not in their language, not in their experience. And even if you all this might be this might be a far-reach who have really been involved in any kind of Agile or Scrum or DevOps implementation that didn’t quite deliver the business value.

It was promised. Right? So, they signed it up to trust you off of off the backbone of that, right. So, we can establish a new way of working into it that gives them a lot of safety and feedback to follow it.

Executive Buy-In Action Plan for Agile

So, this is kind of the how do we do it? And then I have time for questions here at the end.

Well, how long do I go till 40, 40? After that I want to leave 10 minutes. So build a business case, involve the business, spend time talking to your executives, Understand what is strategically important your division, your department, your executives. Depending on the size of your organization and connect this and make it be something that the organization must do to increase their chance of succeeding and what strategically important to them to build a business case make it measurable.

The number of ScrumMasters established is irrelevant. The number of Scrum teams is irrelevant, like the number of defects shipped to customers. Relevant right? The time to value relevant anecdotal stories. This major thing came in. It didn’t break the whole world. We’re able to bring it in, gave you options and you made the right choice relevant. All right, so build a business case.

Know where you’re going to call your shot, build an outcomes based plan, an outcome based plan are measurable changes in behavior that you can do within 2 to 4 weeks that you observe in the organization and the way the system performs or the people are operating. Elevated competence, new behaviors, things that you can measure, you can do every two weeks because we have to go to the table.

If you’ll have anybody read Carter’s change management stuff. Yeah, Carter talked about that. This is interesting because there’s like a -unintelligible-  whatever sort of debate in the world around what change management is. This is organizational change is like a cadre game. Get a small batch, go prove it, earn trust to go move the next one.

All right. We have to wrap personal individual change inside of it as well. We have take care of people’s feelings that where awareness, desire, knowledge, ability, the reinforces kind of go together on the back end of both. But you’re playing at least two games in this model. So building outcomes-based plan every change management model world and also how we build software calls for smaller chunks with measurable progress.

So outcomes based plan, you can’t run them all concurrently. You got to prove something, set up a change to review progress and result, and engage your executives in a purposeful way. Give them create a hole in their heart for this new world. Go win with the things that get in the way and ask for their help to move them, show them the benefit of doing it.

And once you get something moved, go deliver the thing you said you would because you can burn down trust faster than you can earn it in most organizations, especially early on. Right. So don’t overreach, don’t get dogmatic, don’t get to ivory tower pie-in-the-sky scope, prove something because the game we’re playing is earning trust over time and getting our executives to understand it.

The real wins early on, if somebody goes, I fricking get why we have these teams stable now. Like it never made sense to me before, but I’ve got that one show that’s like a real win for us in the change right? So all the things you all talked about at the beginning, executives don’t get it. You know, trust us.

They’re afraid in this model will burn in all those things down a little bit at a time. Not all at once. We’re very purposely paying attention to all the fears and concerns and resistance and obstacles. And our plan of these outcomes is not just to get a change in behavior in the organization, it’s to get people to believe it differently.

Like that’s the game we play and has no to do with Agile, except it has everything with Agile because it’s exactly what you’re doing with your product when you’re trying to move into a new market or new place in your organization. It’s the same game transparently demonstrate progress and refine the plan to ensure we deliver on the business case.

I can’t get this done and by March not going to happen. Let me know what you’ve got now that you never had before. I’ve got three options. I know it’s going to go sideways. I know exactly what trade-offs we have to make to make it work. What do you choose to do? Because I’m not going make the call.

It isn’t appropriate for me to make that strategic call at this point. All right. That’s your call. So you bring them into it. Let them make the shift that creates ownership and shifts ownership to your executives and your directors and your managers and makes it very tangible and real for form. Was that worthwhile? I got 10 minutes for questions and answers.

When are you guys going to make this real tangible? An offer to softer, actionable? Yeah. Let’s let’s, let’s take some questions to make it real actionable if you want the slides here. All right. I was just putting my hands up for a call. If you want the slides, they’re here. You can download them. A lot of the stuff is on our on our blog side of him to go to the blog site.

If you want to get a newsletter from now on, when you accept the thing, click on little boxes. Please send me stuff wherever. If you don’t, that’s cool. So get the slides. But this is a this is to me, what’s really interesting is the game that we’re playing now is an organizational transformation, organizational change game. The game that we’re playing now is is not just an agile game or tactical skills game or competence in the craft game.

All those things are critical. You can’t show up and not do what you say you’re going to do, but it’s insufficient If we can’t get the organization behind us to move, we’re going to continue to get boxed in. And then what’s interesting is when you don’t get to support that you didn’t ask for in an effective way and your initiative fails, whose fault is it exactly?

It’s not the executive’s fault. You didn’t ask them an appropriate way and didn’t buy them in and didn’t have them owning it. We end up carrying the weight for two, right? So this is a whole flipping of the game.

The rest of the video is a Q&A portion with the audience… 

Find out what’s really getting in the way of your Transformation as Mike Cottmeyer explores the single biggest problem preventing change inside large companies across the globe—dependencies. Regardless of the buzzword, process, or framework you’re currently subscribed to, watch this video and find out why dependencies are the exact problem holding you back and what you need to do to overcome them and start aligning your people, processes, and technology.

Video Transcript

They say, “Okay, if we’re going to adopt Agile, what are the necessary preconditions to adopt Agile?” And you said, “Okay, well, I have the whole complete team’s minimal dependencies. I have to have backlogs after we all have the ability to produce working, testing, test Software Corp, right? That’s the fundamental precondition for Agile. So what would I have to do to create those conditions over time?”

Right. That’s really the fundamental question you’re asking yourself because there’s no easy button. You’re having to pull this system apart and rebuild it differently. How do I take my people, align them with the business, take the technology, align it with the people in the business, minimize dependencies so folks can operate with more local autonomy and make good decisions on behalf of the customers?

Right? Because that’s what we’re really trying to do.

Dependencies in Agile

I’m going to explore something that I talk about quite a lot, and it’s the idea of dependencies and Agile. Our industry is circling around something that I think is really interesting. So if we talk about just pure play Scrum, right, we have the idea of teams, backlogs, working custom software. So what’s a team in Agile? Six to eight people that have some amount of autonomy over their technology stack and dependencies between them and other teams?

They can operate off of a backlog. They can produce a working, tested increment, a software every sprint or so. This idea of dependencies, right? Anytime we have dependencies between teams, we have to orchestrate those dependencies in some ways at the most simple level. If I have an occasional dependency, then I might walk across the room and ask somebody to help me resolve the dependency in the course of the sprint.

If they’ve got some capacity, they’ll probably help me. If the dependencies are heavy design dependencies, then those dependencies are really difficult to resolve during the sprint. Typically, when you have lots of dependencies between different parts of the organization, between different parts of the technology stack, between different requirements, it requires some sort of orchestration mechanism. So we’ve talked a lot about SAFe over the last couple of months.

And what I would suggest is that SAFe is really an approach to orchestrate dependencies across teams because if you didn’t have dependencies between teams, you wouldn’t need them. And so this idea that the industry is hunting around stuff. So last time I talked a little bit about this idea of Agile Open Digital that was part of this code aspect that we’ve encountered quite a bit, really similar to the stuff that Justice is talking about with how Tesla and SpaceX are building cars and rockets.

You know, there’s been, I’ve been getting turned on to from some of my tech teams, some of the stuff around Domain-Driven Design. And one of the things that Dennis Stephens, 50 years ago when we first met, was talking a lot about was the idea of business architecture. So I was hypothesizing last time that that may be a way of talking about this, thinking about the business architecture of the organization, the capability model of the organization, and the intersection of that.

And what the technology guys are really thinking about in terms of Domain-Driven Designers. So we want the business ultimately and the technology and the people to be in alignment, right? So think about we’ve got the business in alignment with the technology and the people, and you really have the Scrum teams, right? You have encapsulated relief trains, right?

You have encapsulated value streams, right? So if you can pull that off. And so, even taking it one step further, one of the big buzzwords out right now is the idea of like product-driven organizations. What is that? If I want to have a product-driven organization instead of a project-driven organization, I’m basically saying the same thing, right?

The product is the value, right? That’s the alignment with the business. The product is the technology, and it’s the people that build it, right? As a product, you have an organization that is fundamentally the same thing. You look at some of the stuff that’s coming out right now around the Composable Enterprise, right? Well, what’s a Composable Enterprise?

Well, it’s an Agile, Open Digital kind of enterprise where the organization is, in effect, built of reusable components. And so there’s this idea, right? It’s really interesting. It comes down to what we’ve been hunting for forever in the Agile community. I was talking about a couple of months ago, I was up in Raleigh, and I was talking about how you create a culture of agility.

And we started talking about teaming strategies, and we started talking about where backlogs come from and what enterprise governance looks like and what we measure and what we control. I told a story about one of my buddies who was in the audience and raised his hand and said that as Agile coaches, we can’t change the organizational structure, we can’t change the team strategies.

And I was kind of blown away because if we’re not changing that, then what the heck are we really doing around here? And so, you watch, you look at all this Gartner research, all the McKinsey papers, all the Accenture papers, the Deloitte papers, the stuff that’s being published, the things that people are thinking about around this idea of Composable Enterprises, Agile, Open Digital, the idea of product-centric organizations.

Right. It’s all fundamentally the same thing. How do we get teams of people, how do we get them to align with the business, and how do we get them to have some autonomy over the technology stack so we don’t have to have this crazy, easy level of orchestration between different parts of the enterprise? And so I think about it because we’re in the change business.

And you start to ask yourself things like, “Well, why is it so difficult?” And this is what I think is interesting.

It’s like part of the challenge that we have right now is that it’s really difficult to see past your current constraints. And that’s the argument that Agile Coach I was telling you guys about was making.

It’s like if the organization can’t see past its current constraints, then what’s available to us? It’s like we’re sitting there saying, “Okay, we’re going to buy some new packaged software, we’re going to implement and devise some new technology, we’re going to overlay some new process.” But why is it that we get to this point where the process keeps changing, the buzzwords keep changing, the angle of attack keeps changing?

The products and software we offer keep changing. And it’s like we’re constantly trying to hunt this holy grail, some silver bullet. But at the end of the day, it comes down to encapsulation and orchestration, right? That’s what it comes down to all the time. And one of the things we need to sit in as a community, as a marketplace, as a movement in the Agile community, is if we can’t figure out how to help companies create these kinds of teams, product-centric organizations, composable enterprises, agile, open, digital, then what are we really doing?

If we can’t see past our current constraints and do this for real, you know, I hate to say “lipstick on a pig,” but that’s fundamentally what we’re doing here. It’s kind of fascinating.

The Challenges of Change Management

And I think part of the challenge is that as practitioners, even if we recognize it, we don’t know quite what to do about it. We don’t quite know how to orchestrate the change.

If I’m a senior leader, then I might delegate it down to my people, and I don’t really know necessarily what are the underlying patterns that need to be changed. I’m trusting the people underneath me to do it. But there’s an element, there’s an element of how do we get the executives to understand and do a product-driven organization, do a composable enterprise, do something that’s agile, open, digital? We have to fundamentally rethink the architecture of our systems.

We have to fundamentally rethink the architecture of our business, like Domain-Driven Design and business capability modeling. We have to fundamentally rethink how we orchestrate value and how we feed that system. If we want the benefits of this Agile, Open, Digital, Composable Enterprise, product-driven organization world, it’s really all fundamentally saying the same kinds of things.

It’s fundamentally an encapsulation and orchestration problem, right? It’s the same problem that companies face when they take legacy mainframes and try to turn them into a service-oriented architecture. That might be an interesting pattern to explore because that’s kind of what we do in our transformation world. If you’re going to take a legacy system and refactor it into a microservice, containerized, cloud-based ecosystem wrapped in tasks, what would you do in the software? Well, you’re really doing the same thing to the organization. It’s fascinating.

And I think that’s the principle. I think that’s the core truth underlying all of this. Once you get past the consultants, the process, the technology, and the resistance to change, there’s this pattern, this underlying thing that we’re trying to do. How do we create encapsulated autonomous entities? And one thing that, again, I would challenge everybody to think about is that we hear that and we agree with it, but then we look at our organization as it is, and we can’t see past the current constraint.

We can’t see how to change the organization in a meaningful way. We can’t see how to launch a change program that will do that in a structured and disciplined way. And, at the risk of being a little self-serving, that’s kind of what we do, right? Like, why else do all these CEOs come to us? So I think of leading Agile very much like we’re a hammer looking for nails, and nails are everywhere. But when somebody comes up to us and says something like, “Hey, we want to adopt Agile,” that’s usually where we start.

We say, “Okay, if we’re going to adopt Agile, what are the necessary preconditions to adopt Agile?” And you say, “Okay, well, I have the whole complete team’s minimal dependencies, I have to have backlogs, I have to all have the ability to produce working, test synchronous software Corp. Right. That’s the fundamental precondition for Agile.” And then you ask yourself something like, “Well, if I can’t create those conditions, I’m not going to get the business benefit from it that I want.”

So what would I have to do to create those conditions over time? That’s the fundamental question you’re asking yourself because there’s no easy button here. You’re having to pull this system apart and rebuild it differently. So if it’s an Agile question, you have to start with that fundamental precondition.

If I were going to use the same kind of metaphor on the system side, I might think about it something like this: I have a legacy monolith that I want to move to the cloud, some legacy software that I want to move to the cloud. And you have to ask yourself, what would it take to be able to move that software onto that different platform?

You could do it in a couple of different ways. You could take that legacy platform and move it to the cloud, and I think they call that “cloud-enabled” or something like that. But there’s a difference between being cloud-enabled, cloud-ready, or cloud-native. For something to be truly cloud-native, you have to pull it apart.

You have to make it more service-oriented, containerized, wrapped in APIs, and tested in order to fully exploit the cloud at that level. So, if somebody came to me and said, “I want to do Agile,” you’d have to work your way back to this encapsulation and orchestration thing.

If you want to do a cloud migration, you’re fundamentally having to think about it in the same way.

Why Digital Transformation is Failing

Another word that keeps coming up is this idea of digital transformation. And what we’re starting to see in the industry is that digital transformation has been largely treated as a technology problem, and now we’re seeing articles being written about why digital transformations are failing.

The reason why is that it has been treated as a technology problem. It hasn’t been treated as a people and process problem. It hasn’t been treated as an organizational design and governance problem. The inclination is either to put new technology in place or wrap the existing organization in a new set of processes or ways of working.

But at the end of the day, once you see it, you can’t unsee it. You have to figure out how to take the new digital technologies and wrap them in people, give them a more Agile, lean governance framework to experiment with. Once again, once you see this pattern, you see it everywhere. It’s fundamentally a teaming strategies problem, an orchestration problem, a dependency problem.

And again, I just think the root of the reason why I don’t think that’s hard to understand, and I don’t think most people would disagree. But the hard part is seeing past the current constraints.

How do you get the people in the organization to understand that this is the problem at hand, right? And then how do you get executive buy-in to make the changes? And once you have the buy-in, how do you manage and cost-justify the change? All those things.

Transformation is Transformation

Over the last couple of years, we’ve been working on larger and larger Agile Transformation work, it’s really interesting. It’s not just about installing Scrum. It’s very much in the space of digital transformation, cloud migration, and technical uplift. We call it Agile transformation, but all those things are interconnected. They’re all in the same space. How do I take my people, align them with the business, take the technology, align it with the people in the business, minimize dependencies, so folks can operate with more local autonomy and make good decisions on behalf of the customers?

Because that’s what we’re really trying to achieve. And so, I’ll say it one more time. If we can’t figure out how to overcome our current constraints and create the necessary conditions, we’ll just keep throwing dollars at this. We’ll keep throwing technology at it. We’ll keep throwing new processes and labels. But at the end of the day, it’s the same thing. It’s the alignment of people, process, and technology.

It’s kind of consulting 101. But what does that mean? Encapsulation, orchestration, minimizing dependencies. If you can encapsulate, you have to orchestrate. If you can’t break dependencies, you have to manage them. That’s the problem. What we really need are organizations that are adaptable. That’s why we’ve been gravitating towards the term “composable enterprise” because it brings together the systems view, the technology view, and the people view under one umbrella.

I’ve been using that term a lot, trying it on a little bit. It’s an interesting thought. So feel free to reach out, make a comment. My team keeps me updated, so I can engage and reply. I’m super happy to do that and I look forward to the conversation. Thanks a lot, guys. Have a great day.

Mike and Dave sit down to have another debate with ChatGPT about dealing with dependencies in Agile. Mike asserts that dependencies kill Agility and that they’re meant to be broken. ChatGPT says that it’s all about managing dependencies and that while dependencies may limit Agility, they can also foster collaboration and synergy.

The debate quickly rolls into a conversation about dealing with legacy technical debt and business capability modeling and how we need to focus on minimizing dependencies in all aspects of the business, not just at the team level. Dave even gets Mike to start talking about his latest thinking on composable enterprises and what executives need to know about software architecture.

Contacting Mike Cottmeyer

If you’d like to contact Mike, you can reach him at:

LeadingAgile: www.leadingagile.com/guides/mike-cottmeyer
LinkedIn: www.linkedin.com/in/cottmeyer/
Twitter: twitter.com/mcottmeyer
Email: mike@leadingagile.com

Contacting Dave Prior

If you’d like to contact Dave, you can reach him at:

LeadingAgile: www.leadingagile.com/guides/dave-prior/
LinkedIn: www.linkedin.com/in/mrsungo
Twitter: twitter.com/mrsungo
Email: dave.prior@leadingagile.com

If you have a question you’d like to submit for an upcoming podcast, please send them to dave.prior@leadingagile.com

Interested in CSM or CSPO Training?
You can find all the details at www.leadingagile.com/scrum-training/

Mike Cottmeyer debates ChatGPT and sits down with Dave to discuss what it really means to scale Agile. Over the course of the podcast, Mike and Dave explore the difference between Agile principles and practices, cloud migration, and what the Agile industry can learn from the US Air Force’s concept of Agile, Open, and Digital. 

Want to Listen Instead?

Contacting Mike Cottmeyer

If you’d like to contact Mike, you can reach him at:

LeadingAgile: www.leadingagile.com/guides/mike-cottmeyer
LinkedIn: www.linkedin.com/in/cottmeyer/
Twitter: twitter.com/mcottmeyer
Email: mike@leadingagile.com

Contacting Dave Prior

If you’d like to contact Dave, you can reach him at:

LeadingAgile: www.leadingagile.com/guides/dave-prior/
LinkedIn: www.linkedin.com/in/mrsungo
Twitter: twitter.com/mrsungo
Email: dave.prior@leadingagile.com

If you have a question you’d like to submit for an upcoming podcast, please send them to dave.prior@leadingagile.com

Interested in CSM or CSPO Training?
You can find all the details at www.leadingagile.com/scrum-training/

Agile, Open, and Digital. Several years ago, the Air Force coined this term as part of its Digital Century Series initiative, a new approach to building fighter jets. While the Digital Century Series may be dead in the water, the idea of Agile, Open, and Digital lives on and is making some headlines in the manufacturing world and the world of business in general.

But what can Agilists learn from this idea? Are there any analogs in the software space? What about when it comes to organizational design and systems architecture? Mike Cottmeyer sits down to explore this idea of Agile Open Digital and the implications for the Agile industry.