Our guest, Troy Magennis, has been described as a national resource in the Agile community. He’s a published author and frequent speaker on forecasting and modeling Agile projects.

Today, Troy joins us to discuss how many of the metrics the Agile industry uses actually prevent companies from achieving the change they so desperately desire. Together, we’ll explore some ways the industry gets metrics and forecasting right and where it tends to go wrong. And Troy offers a ton of insight on how you can begin thinking about the work differently to release more value more rapidly more often.

Listen to the Podcast

Contacting Troy Magennis

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

Focused Objective: https://www.focusedobjective.com
LinkedIn: https://www.linkedin.com/in/troymagennis/
Twitter: https://twitter.com/t_magennis

Contacting Dave Prior

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

LeadingAgile: https://www.leadingagile.com/guides/dave-prior/
LinkedIn: https://www.linkedin.com/in/mrsungo
Twitter: https://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 https://www.leadingagile.com/scrum-training/

In Agile, you only get the full benefits of Scrum and SAFe when certain conditions are met in the organization. People will often break the methodology or the framework instead of changing the org design and sacrificing their ability to be truly Agile.

XP and DevOps are no different. Solid technical practices and your full-stack developer’s software craftsmanship are also limited by the conditions inside your organization.

Today, Mike Cottmeyer brings in our CTO and one of the main architects of our Studios offering to discuss the conditions that must be present for solid technical practices and software craftsmanship to thrive.

Video Transcript

Mike Cottmeyer:

Hey everybody. Thanks for joining us today. We’re going to try something a little bit different. A couple weeks ago we did a recording session with Chris Beale, who is one of our most senior executive consultants, runs a lot of our large enterprise class engagements. And Kevin Smith, who is a kind of chief architect, principal consultant in our studio. I invited them here to have a conversation with me because I was out with clients doing presale stuff and working with executives on the teams and the conversation around full stack teams, software craftsmanship, clean coding, different strategies for how to get developers engaged and involved was coming up. And as somebody who hasn’t had hands on keyboard directly for probably 30 years or something at this point, sometimes I feel like I know enough to be dangerous. And so what we were talking about was the idea, on theme for the last couple of these recordings of, what are the necessary preconditions to be able to do software craftsmanship well?

And so we started this conversation to talk about test harnessing and rapid deployment and the kinds of technology things that you might want to consider. And the conversation really took a tone into really how do you get the teams involved? How do you get leadership engaged? What’s kind of the attitude and mindset around it? So we’re going to drop into that conversation now, and what I’d really like to know is what you guys think, where else should we take the conversation? What other questions that you might have? And for you hardcore engineers out there, not really so much talking to you. What I’m really talking about is to your project managers, to your team leads, to your executive teams around what kind of conditions they need to create for you so that we can do Agile and Agile engineering practices really well. So I hope you enjoy this talk. It’s a little bit of an experiment for us, and I’ll check in with you at the end and see what you thought. Thank you very much.

The Preconditions for Agile

Hey everybody, welcome to our little video recording. We were just talking with our marketing team that we probably need to come up with a name for this. We tend to do these on Friday afternoons. It happens to be a Friday afternoon when we’re doing this one. Maybe we’ll call this Fridays with Mike or something like that. But over the last couple weeks we’ve been talking about this theme and the theme that that’s on my mind is if we’re going to do Agile, if we’re going to do Scrum, we’re going to do XP, we’re going to do something scaled like SAFe for large scale Scrum, one of the things that we have to really be attentive to is creating the appropriate pre-conditions to do Agile. And at the smallest, simplest level that it’s usually like if we’re going to do Scrum, we have to have complete cross-functional teams of five to six to seven people.

They have to be operating off of clean backlogs that are written in a way, something like Mike [inaudible 00:03:13], Bill Wake’s INVEST model. We have to be able to have the ability to produce a working test in increment at the end of every sprint. And with the idea that if we create the right preconditions, the methodology work tends to work out. If we want to do SAFe for something at scale, we have to figure out how to encapsulate value streams. We have to figure out how to encapsulate release streams. And so I was actually out on site with a client last week and we were talking about the idea of having complete cross-functional feature teams, teams that could kind of roam around the entire code base, that could do frequent commits, that could get fast feedback, that could deploy rapidly. And we started having this discussion about what were the underlying technical considerations that had to be in place to do that.

And so I started to engage my team, because I know just enough about the technical side to be dangerous, so I can talk about the benefits of pair programming, I can talk about the benefits of CICD or the benefits of test-driven development, but it’s been a long time since I’ve had my hands on a keyboard. So that’s not something that I consider myself a deep expert at. So what I did is I brought in a couple experts and we’re going to see if we can have a conversation here today. So I have Chris Beale who is on my executive team. He is one of the people that basically owns a portfolio within LeadingAgile and supports a lot of our high-level customers helping to create strategy and vision. The cool thing about Chris is that Chris comes from a really solid XP background, and when he joined us, he was five, six years ago now Chris, something like that?

Chris Beale:

Seven.

Mike Cottmeyer:

He really just had to suspend disbelief and kind of throw himself into this whole process in transformation world. And I also have Kevin Smith here with us who is one of our principal engineers, and he is one of the main architects of LeadingAgile’s studio. That’s something that I don’t talk about a ton, but we actually have the capability to provide tech coaching, velocity pairs. We can deploy whole teams. We do a lot of stuff around product extraction and such like that. So I brought Kevin in.

The Conditions for Software Craftsmanship

Mike Cottmeyer:

So I’m going to throw these guys a couple of questions and we’re going to get some conversation going and see where it goes. So, Chris, I’m going to hand you the ball first. And in the context of this, we want to have just the most perfect extreme programming XP teams that we could possibly do. Software craftsmanship, attention to detail, all the things that Kent Beck and Ron Jeffries and those guys were talking back in the early 2000s. In your experience, what are the conditions that have to be created organizationally for that to work really well?

Chris Beale:

Yeah, so thanks Mike. The thing that’s top of mind for me with respect to conditions for software craftsmanship, clean coding, all of that to work, probably number one is it has to be a team sport. So I’ve been in organizations before where one developer on a team is really passionate about that, they’ll do tests first. They’ll keep their tests running, they have good CI hygiene and others, like in a standup, I was a little amazed once when one of the developers told the other developers, “Hey, I just broke 14 year tests. You need to fix them.” So it has to be a team sport. So within the team, there has to be agreement, there has to be common practice, there has to be common commitment across all of the developers and all the team members that this is the way we’re going to work.

We’re going to do ensemble programming at times, so we’re going to pair, we’re mob, we’re going to test drive, we’re going to do these things as a team. And then when you have multiple teams working together on things that are dependent, you actually need those decisions to really be across teams. So you’ve got to have a common commitment across the scope or the span of people who are working together to get something valuable done that this is how we’re going to work.

Mike Cottmeyer:

Okay. Typically, what’s the case you make? I mean, one of the questions we get asked at an executive level is, how do you get your CIO or your CEO to want to do Agile? What’s the value prop for a developer in operating this way?

Chris Beale:

Yeah, so it’s kind of a personal thing really. I mean, my hands on exposure to extreme programming was 20, geez, 21 years ago at a company that I used to work for. And before that I was a boil the ocean architect. Everything was big up front design, OA, OD, had to know everything up front, was risk proofing my software 10 years out. And then I hired into this thing that I didn’t even know what they were doing. I didn’t understand it, but it was amazing. They were getting defect-free releases done and deployed with a push of a button. Actually, it was a one command line to deploy an entire system defect-free, completely regression tested, and it was like nothing I’d ever seen. So I had the benefit of seeing it before I had to actually accept it and experiencing it.

I questioned it and I could learn from it. So for me, it was very objective because I hired into the middle of it and had no idea what it was. A lot of people don’t get that. That’s a bit of a blessing for me. A lot of people don’t get that. They’re being asked to do this without being able to see it. So if at all you have the chance to see it and actually to experience it, there are generally local labs or something you can go to where they do this kind of work and work this way and you can just see it. It’s really very evident, very quick what the differences are. That being said, I think for folks who are learning it from our coaches, there’s some art in the coaching that where I used to fail, I would write some code, I would try to integrate it and it would fail.

There’s ways coaches can coach to make that failure small. It’s not expensive to decrease the amount and cost of failure, but to actually show the benefit then of how I just saved you a bunch of time and a bunch of rework and a bunch of frustration, possibly missing a deadline. So there’s art and possibility and opportunity with coaches to actually make it… Because failure’s a good teacher, it’s a very strong teacher. You’ll have a hard time sometimes convincing somebody of anything by just talking about it.

We look for agreements to act your way into a different way of thinking. So just start, use the Karate Kid metaphors like sanding the floor, paint the fence, but we’ll do it in little enough cycles to where, okay… And the epiphanies happen, okay, I was just able to do that. I have a failing test. I wouldn’t have known that for hours or days, but now I know that in minutes and I can address it. And so those little epiphanies start to add up for many developers and then they catch on, okay, wait a minute, now we want to know more. And you start to build momentum in those little learning cycles.

What Gets in the Way of Solid Technical Practices?

Mike Cottmeyer:

Yeah. So Kevin, let’s say somebody goes off and they do their homework, they go to the labs, they maybe get a chance to experience it, and then they’re coming back into maybe a legacy code base or a code base that wasn’t written with TDD or isn’t appropriately unit tested. What are some of the challenges that teams who want to do XP, software, craftsmanship, clean coding, what are some of the challenges that you see that make it difficult or maybe even unsafe to actually do those things?

Kevin Smith:

Yeah, Mike, and feeding off of Chris’s big upfront architecture background, I had a bit of that as well. And it wasn’t true 20 years ago, and it’s even less true now that any architect or any developer can hold the entire system in their head. So that’s the false belief that a lot of developers fall under, especially if you’re developing a new system, is you build up over time until you get to the point where you don’t know and it’s pretty quick that you don’t know the entire system, you don’t know how it’s operating. And going into a legacy system, you’re jumping right into that. How do you look at code that you’ve never seen before, make a fix or make a new feature in that code base? What are the safety mechanisms that you need around you to actually push that into production?

And then what are the things that can help optimize your understanding of that code base of how it works? And that’s the purpose of tests. And tests first help you design a system that’s testable, but if you’re jumping into a legacy code base, there’s characterization tests or exploratory testing that you can automate to help you understand what it is that already exists and how it runs. And then even outside of testing in production, there’s patterns around observability so that you get realistic logging that’s all tied together. So you can push data through a system and see how it navigates through all the different components that makes it usable for developers to be able to get up to speed and be able to code. But yeah, it is very difficult to jump into a legacy code base without those types of things and be expected to add a feature without creating a defect. So you’ve got to create some safety nets.

Mike Cottmeyer:

Well, so in my non-technical front of the room, talking to executives all the time, I think about just really simple things like, if we’re going to have multiple teams operating on the same code base, it’s like when I started learning about XPOs reading all the Kent Beck books and stuff back in the day, the idea is that if we have sufficient testing, one of the things that actually increases speed and agility from the development team is like, if you’ve broken something all the time.

Kevin Smith:

You want your biggest failures to be on your tightest feedback loops. If you’re going to break something, if you have a test that can show you that within seconds versus weeks later in UAT, you can make that fail fast. You can make that failure very inexpensive. But if you put that piece of code in and it goes through, you don’t have good test coverage and then you integrate it and it goes over to a QA team that’s completely separate or UAT environment and it takes weeks before you find that failure, you have to unwind that whole thing to get back to the team to make that change and do it all over again. It becomes very expensive.

Mike Cottmeyer:

For a team that’s motivated to do this, maybe we’re kind of talking around about what makes it difficult? What are the impediments? Because what I find is that, again, in this particular case that I’m thinking of, you have a team that wants to do this, they’re trying to do it, but in the presence of the dependencies, in the presence of the lack of test harnessing or Red, Green, Refactor kinds of stuff, it’s like it’s actually introducing more errors than it’s actually… It’s just not serving the purpose of it.

Kevin Smith:

Off the top of my head, I can think of you need some boundaries of the area that you’re working in. And we’ve talked about this in the past on hard, crunchy shells and product extraction and things like that. But you want your team to have some sort of area of focus. If you’ve got this massive legacy system, how can we isolate the area that we impact? And whether that’s putting certain types of tests in or actually going through and extracting some things out or putting some APIs around things, there’s definitely some pre-work to take into consideration so that you can move faster later.

Chris Beale:

Yeah, I think the folks that taught me, I learned from some very talented people, the principle they gave me was trust breeds momentum, momentum breeds success, and success breeds trust. So it’s a virtuous cycle that underneath all of it with XP. So as an example, if I don’t know what the code is, the code has unknown dependencies to me, I don’t want it to break if I touch it, then I’m going to act very carefully. I’m going to forensically try to understand it, I’m going to make changes, but I don’t know what I’ll break. But if the code is giving me feedback, if I’ve got tests that are saying, “Okay, wait a minute, you just broke something.” Now I can actually act courageously. I can try just about anything I want because I’ll get instantaneous feedback, “Wait a minute, you just broke something.” Okay, do I want to fix that and move forward with what I was doing, or do I want to revert?

So I can move with courage versus trying to forensically figure out how to play operation and not touch the sides. To Kevin’s point though, you can almost think about when we’re talking about just normal Agile stuff, Mike, with our customers, I often describe the things that we do as is really the goal of those things is to validate learning, it’s to explore and discover and have better conversations and you get all the other stuff, the software kind of falls out the side when you’re really good at that. So it’s really about learning and getting collective cognition, multiple people on the same page so we can move together efficiently and effectively. That’s what user stories do, that’s what Scrum does. It’s getting everybody’s brain to act as one for one small iteration.

When you’re going through legacy code, the things Kevin’s talking about, so you can do characterization testing. If the goal is to write a test, you probably have the wrong goal. If the goal is to understand-

Mike Cottmeyer:

Explain that to me a little bit.

Chris Beale:

So the goal should be to learn and understand. So even when I’m doing test-driven development on a brand new thing, the goal isn’t to test, the goal is to learn. It’s I’m exploring my design ideas, I’m exploring the requirements. I’m trying to figure out what it needs to do and how I want to do it in a very changeable way. So it keeps cost to change very low. My learning cycle’s really fast so I can explore my design. I don’t generally ever come out with a class diagram or the software I thought I was going to get when I started, because learning happened through all those little micro-iterations of build, test, learn in the software. So my classes emerged, the responsibilities emerge, the relationships emerge for me. I mean, I have a place where I want to start, but in exploring my design and how I want it to work with tests, I get software. The software is a byproduct.

When I don’t know the code and how it works… And so there was a customer back in the day where I was told to do… It was a turn by turn thing. So the early days of turn by turn automation, you’re going to get directions from your house to the mall or something-

Mike Cottmeyer:

Like GPS turn by turn is what you’re talking about.

Chris Beale:

Yeah, GPS turn by turn. So the customer said, “Okay, here are 14 services that you can use and this is how they work.” And I said, “Okay, it’s great, but I want to test them.” So immediately I just wrote some tests. Turns out 12 of them didn’t work the way that the customer said that they work. But I knew how they worked because I had tests, running tests, green tests that said, okay, when I pass it this thing, this is what it actually gives me.

And so I could basically alter the design and actually we altered some of the requirements as well because the services didn’t work as advertised. Testing is primarily about learning and understanding. When testing is about testing, that’s generally what test after is. I’ve got some code, did I do the right thing? Did it work? When you’re really in the XP frame and you’re thinking test first, it’s really about learning, exploration, and discovery, and reducing risk. And so you understand the boundary of the software you’re going to change by writing little characterization tests. When I pass it this, what does it do? Oh, it does that. Okay, so I’ll name my test this and now I know what it does in that area. And I can actually explore the boundaries of my change so that I know that when I make the change around that boundary, I don’t change behavior. So I can learn the software, that’s why I’m writing the test. I get the automation and I get the change as kind of a side effect of that.

Kevin Smith:

And that learning carries forward as you onboard new team members or over time as developers come on board and change, those tests are there for their learning. That’s how they learn the system, how they learn how it functions, how they learn, where the boundaries are. It’s also, the safety net for them from an automation perspective because those tests will break when they do something unexpected. But it is a learning mechanism.

Chris Beale:

If I come into a new system with tests, the first place I go to understand the software isn’t the software, it’s the tests. The tests will tell me how the software works because the tests won’t lie to you. If they’re well-written tests and they’re running green, they’ll tell you how the software works.

Mike Cottmeyer:

You mean you don’t go to the big design specification to see how the software actually works, Chris?

Chris Beale:

The old adage is, documentation lies in the XP world. Documentation is going to lie to you. And in the case of that example I gave you, I won’t give you the customer’s name, but in the case of that example, the documentation clearly was lying about the contracts that those services were supposed to provide. And it’s because everybody knows keeping the documentation up to date is an extra thing. And even if you want to do it and you’re conscientious about it, it’s hard to think about all the behaviors you’ve added or changed. You might just miss stuff. So over time, enough of that happens to where the docs aren’t actually describing what the software does. The cool thing is you have an executable specification. It’s the test itself. It’s actually a specification for how the software works that has to be true because it’s running green. So if it ever gets out of date, it’ll turn red on you.

Supporting Engineers Doing Agile and Economic Justification

Mike Cottmeyer:

One of the tensions that I’ve always felt in the Agile space, Agile really grew up out of the software engineering world. So the Kent Becks and the Martin Fowlers of the world. And then it got taken over what I’d say about the Jeff Sutherlands and the Ken Schwabers of the world, it became almost like a Scrum XP dichotomy. And I think one of the things that we see quite a bit are folks that get introduced to Agile that don’t really have the deep expertise in how software’s built, how it’s architected, how it’s run, how it’s tested, how it’s deployed, all those kinds of things. So we kind of wrap development in these management practices, but sometimes because we say we’re doing Scrum and Scrum doesn’t necessarily require XP practices, then we can break things a little bit.

So maybe Kevin, you could lead us off. I would love, as a developer, what would you want maybe your Scrum masters, your Agile coaches, your leaders in that organization, what would you want them to know such that when they’re implementing Scrum or SAFe, what would you want them to be aware of and cognizant of to create the right environments for the engineers to do Agile well? Any thoughts?

 

That’s a great question. The thing that pops to the top of my mind comes back to what I said earlier around feedback loops is understanding the one to 10 to 30 layers of feedback that a feature is going to need to get to production. So anytime you can move risk to a smaller and faster feedback loop, the better off you’re going to be. If you could focus on not just in your most TDD feedback loop where you’re writing a test, writing the minimal code to pass that test and then refactoring it and committing it, but all the way through the cycle, how can you reduce the size of those feedback loops through automation? And this is where DevOps comes in. And by doing that, that gives you the ability to take more risks, experiment more with more things, push things out to production more quickly, get feedback on them and so on. I think that that’s the big thing in my mind from a support from Scrum masters or support outside of the development team, is understanding all of those feedback loops and how to work towards reducing them.

Mike Cottmeyer:

Chris, you led off with the idea, you talked about the idea of pair programming. I was introduced to that through, I was at the XP White Book back in the day, something like that. And the common objection of leaders would be, well, why would I have two people writing the same code when I could split those two people up and I could write twice as much code? So one of the things that becomes a barrier to what Kevin’s talking about is the idea of economic justification. So how would you create economic justification for building the necessary infrastructure so that you could achieve those faster cycles? Because it’s not just a mindset or an attitude or even a practice. There’s some fundamental barriers sometimes in how that code is written and deployed that actually make it really expensive to create those feedback loops. How do you create the economic justification for that change?

Chris Beale:

So I think it’s always difficult to… When you look at outcomes, causation can be very, very difficult. It’s like the business outcomes that we create for our customers, an increased revenue or decreased expense or whatever. Direct causation, if revenue’s going to go up a hundred million dollars, can you say, okay, it’s these features that cause that, specifically these three features? So causation can be difficult, correlation a little easier. Over time we show that we’re doing these things and our customer SAT scores are going up and our revenue’s going up, and you can start to correlate things. When it comes to specifically what are now being called ensemble coding practices where you have more than one developer working at a time, you can think about it from an input perspective, an output perspective, and an outcome perspective. I think a lot of the people we run into are dealing with finance organizations that think in inputs.

So dollars per hour, number of resources working, do the math. Very easy to say, we’ve got X amount of dollars working at that screen at any given time, and what are we getting for it? And I think we are very bad as an industry at saying, okay, but your productivity went up by this much and your defects went down by that much, and the cost of a defect is this much for you. So I think those things can be actually measured. I’ve done it in prior jobs. I actually proved in one job that the worst thing you could possibly do with this system is to have anybody change a line of code. If you just stop, that is the best economic outcome you can have. Because every time you change it, you break this many things and each thing costs you about this much to fix and the benefits you’re getting doesn’t actually outweigh the cost.

So if we’re good at tracking metrics around the cost of change, and we can correlate that to then outcomes, so what kind of improvements are we getting in productivity, decreases in waiting. So how does that correlate to waste in the system and productivity and throughput and all of those things? I think that can be powerful. I have run into situations where even with that economic justification, it’s just some people just can’t wrap their brain around it. I mean, the example I gave earlier, we had an organization transformation went from a new product was 21 months and 700 defects and don’t touch it, to three months, no defects, 20 hours of production support per year. We had the metrics for all of that stuff. And so CTO moves out, new CTO moves in, didn’t care about any of that, just saw two people at a tube and absolutely couldn’t understand why we would do that and why were we writing all these tests when we could write features?

And no matter what we gave them in numbers it just wouldn’t land because of the way they saw the world in inputs, not outputs and outcomes. But I think the outputs are very measurable and you know can correlate to the outcomes, you might not be able to do direct causation. I think in many cases the world has changed, Mike. I don’t think there’s as much pushback for allowing people to do this. I think actually there’s more expectation that people will, but I still think there’s a good case to be made for saying how valuable is this? So measuring throughput, measuring rework, quality, all of those things, and then correlating it to how much value now can we put out to the customer based on the fact that we’re no longer doing all of these other things.

Mike Cottmeyer:

Okay, awesome.

Kevin Smith:

It’s never been about about how fast developers can type, it’s always about their problem solving skills, which is collaborative. If it was about how fast you could produce code, we’d have typing tests for developers. That’s never the case.

Mike Cottmeyer:

Yeah, that’s an interesting point, Kevin, because sometimes what I’ll talk about is a lot of times it’s decision latency, it’s waste, it’s wait time, it’s defects, it’s all those things that is actually what’s driving the cost and the timeline. If we were just clear, so many organizations resist the idea of getting the business and the developers in alignment on even what they’re going to build. It’s too expensive, it’s too up front, it’s too this. And I’m like, but what’s the cost of them not understanding it? They’re just building the wrong thing.

Kevin Smith:

And if you can get that in front of them faster through the feedback loops and get a reaction from the end users about what’s actually being built, you can make directional changes sooner at a lower cost, even if it takes-

Chris Beale:

That’s something that can be measured though, time to feedback. So the longer we-

Mike Cottmeyer:

I actually told an engineer one time I wasn’t interested in how many lines of code or how much software he could write, I was interested in how much validated features in the product that he could demonstrate to the customer. It was a really kind of a different mindset. So we’re going to wrap this thing up. I really appreciate you guys stepping into this with me, and I think we’ll do more of these over time. I think this is a fun topic to explore. And I think just at the highest level, just bridging the XP and the Scrum worlds together a little bit and help them each understand how we need each other, I think will be a cool thing to do. So anyway, everybody, thank you guys for joining us and we will talk with you next Friday. Have a great day. See you, bye.

Kevin Smith:

Thanks, Mike.

Parting Thoughts From Mike

Mike Cottmeyer:

Well everybody, I hope you liked that interview. I hope it was informative. I hope you learned a lot. If there’s anything else we could do that would help you understand how to create the necessary conditions, whether they be management, whether they be cultural, whether they be technical, we would love your feedback. Please drop a note in the comments. Let us know what you’d like us to explore further, and we will get Chris and Kevin back and we’ll do a follow-up to this and take it whatever direction you guys want to go. This is a really important issue because one of the things that we have to keep in mind is that specifically when we’re doing Agile in a software development world, the practices of Scrum and the practices of SAFe aren’t enough.

The kinds of things that really enable you to go fast, to move fast and to break things are these very technical issues that we’re talking about. And one of the biggest failure patterns in the industry is when we start doing Scrum, we start doing rapid planning and rapid delivery, but we haven’t created the necessary safety in the software product to do that very well. So again, help us help you. We would love to go deeper into any of these topics and we’re looking forward to hearing what you guys have to say. So until next time, we’ll talk to you later. Bye bye.

I spend a lot of time talking about the underlying preconditions for Agile. Because of my background in project management, process, and org design. I usually talk about the necessary preconditions from that angle. I beat the drum pretty hard on the idea of teams, backlogs, and working tested product increments as the fundamental preconditions to do Scrum well.

That said, my education is in computer science, I’ve been working in the software industry for the past 30 years or so. I think I understand a lot of about how systems are architected, and how good code is written. I say things in front of really smart developers and don’t get thrown out the door. But because I’m not a hands-on keyboard guy, I tend to keep my mouth shut where I don’t consider myself a deep expert. I know just enough to be dangerous.

Keeping that in mind, I want to talk about a conversation I had last week.

I was talking to a group of leaders, leaders that were super deep, knew their product backward and forward, and very committed to doing Agile well. We were talking about the idea of full-stack developers. Feature teams that could work anywhere in the code.

It wasn’t really working for them. They were struggling to make and meet commitments. They were struggling to keep the code defect-free. They were having a hard time knowing when things were broken. They were struggling to see why it wasn’t working.

Let’s look at why it’s not working.

The Ideal Full-Stack Team in Agile

An ideal Agile team would be relatively small. Maybe five to seven people. It would have everyone and everything necessary to produce a working tested increment of software on regular intervals. And it would have close contact with customers and be able to get rapid feedback. That’s what the ideal team would need from a management perspective.

But what do they need from a technical perspective?

Again, not a hardcore technical guy here, but I think they’d want to have sufficient unit test coverage. They might want to have the ability to rapidly do a build. They would want to deliver frequently into that build and instantly be able to know if anything had broken. They would want frequent customer feedback.

That is a HUGE part of what makes Agile teams faster. They can move fast and furiously through the code because they always know if they broke something. They always know that, if they refactor something, they didn’t break anything else. That allows them to keep the code clean, defect-free, and well-architected.

Now imagine a full-stack team moving fast and furiously across the code. Working on small user stories and committing often. Since we have shared code ownership, we might even imagine we have multiple teams making changes into said codebase simultaneously.

Now, imagine that team doesn’t have sufficient test coverage. Imagine they don’t have unit tests. Imagine they can’t do frequent builds. Imagine they can’t continuously integrate and deploy. What if they can’t get rapid feedback from the customers? What if the testers are on a separate team? Maybe they don’t see it as their responsibility to test at all. Maybe that is the responsibility of the QA team. What would be the result?

It’s not just the management practices of Scrum that have preconditions. The technical practices (of let’s say XP) have preconditions too. You can’t move fast and break things if you can’t tell it’s broken and can’t fix it immediately. You can’t have shared code ownership and multiple feature teams working simultaneously if you can’t prevent them from stepping all over each other.

So, I want to encourage everyone to not just understand what to do. But to understand why we do it. What the practices are and how to do the practices. And most importantly, what preconditions must be in place for them to really work.

Applying Principles Over Practices

Here’s the deal. If you go back 25-30 years and you read the literature. You go back 20 years and read the early Agile literature. There was a lot of underlying theory behind the evolution of Agile principles and practices. Over the years, it seems we remember the practices, but don’t always appreciate why we are doing them. What problems we were trying to overcome, and what conditions had to be changed to make those practices effective.

It’s like knowing sprints should be the same length without understanding the underlying principles of empirical process control. Managing variation and throughput through consistent sampling intervals. If you don’t understand what is going on, you don’t know when to break the rules or stick to them.

Anyway, principles without practices can be applied universally. Practices can never be applied without understanding the principles without creating a high likelihood of failure.

What if, instead of focusing on all the Agile practices, we started applying some of the things we know about systems engineering to help large companies become the kind of organization that can leverage those practices?

Instead of blindly performing the ceremonies of Scrum, what it we got super disciplined about how we decompose work and flow decisions through the organization? Craftsmanship and emergent design are great. But at some point, the ideation of features and requirements and the decisioning process looks a lot more like an assembly line in a factory than it does boutique delivery.

Video Transcript

Agile is a way of enabling work cells in that factory. But what is the factory? How does workflow across the Agile world? We’re really focused on the idea of empowering teams, the teams being the best people to understand how work is supposed to get done. There’s not a lot in the Agile community right now that basically says how do we apply systems engineering and systems thinking to how the assembly line of software happens?

What does the supply chain for software at scale look like?

(Musical Interlude)

There’s something that I’m exploring here a little bit that’s been on my mind lately that I’m going to share with you guys. So, I spend a lot of time talking about the differences between Agile practices and the nature of the organization that is necessary to deliver against those Agile practices. In my world, it’s really the difference between, let’s say, doing Scrum, right?

I’ve got Scrum Masters and Product Owners, and I do daily stand-ups, sprint planning, reviews, and retrospectives. But the idea is to have really well-formed, complete cross-functional teams, teams that operate off of a clear backlog and are able to produce a working, tested increment of software at the end of every sprint.

We go to client after client, up clients that are doing Agile really well. Agile is pretty well understood at this point, but they are unable to form the kinds of teams that we want them to form, unable to build the kinds of backlogs that we need them to build, unable to produce the working, tested software that we want them to produce.

And this is the interesting thing. So, I’m going to challenge you guys for a minute. If you go back to the early works on Agile, back in the early 2000s, the early Mary Poppendieck work, the early Kent Beck work, the early Ken Schwaber work, the early Alistair Cockburn work, the early Mike Cohn work, all that stuff, right?

Those guys were exploring the underlying theory of how you organize around value streams. They were exploring the idea of how to deal with variation in highly variable systems. They were exploring the idea of Lean applied to the software development process, how to operate in smaller batches, how to continuously focus on quality, how to continuously get feedback.

I talked a bit about the idea, maybe the differences between predictive process control and empirical process control. There is a deep understanding, a deep exploration of the theory of software over time. What started happening was that those practices became codified. And then you have Jim Cundiff and others at the Scrum Alliance who really popularized the CSM training.

Right. They took Agile mainstream. Even PME got on board with the PMI, ACP certification. In order to certify somebody, you really have to make it repeatable, right? You have to know the roles, the ceremonies, and the artifacts. What is Agile? What do you do to do Agile? At this point in our evolution as an industry, it seems like we are focusing on the practices of Agile over the underlying theory. I talk about this a lot, right? We talk about Leading Agile being a systems-first company. We have to get the structure of the organization right.

We have to get the governance and metrics right. We have to have an idea of what the end-to-end system of delivery looks like. Then we enable that with practices, and culture emerges over time. But what I’m really hunting down when I go down that exploration is that a lot of us have either forgotten or are not aware of the underlying physics that those practices were designed to work on top of.

It’s like the physics of team strategies, the physics of small batch, the physics of balancing capacity and demand, the physics of constant inspection and pulling risk forward, and all that kind of stuff. All of that stuff got codified into these practices of Scrum, these practices of SAFe and other methodologies that emerged. And I think one of the biggest challenges that we’re dealing with as an industry right now is that we’re thinking that if we do the agile things, we’re going to get the Agile results. If we show up and do a daily stand-up, that’s going to really help us get the results we want.

Another line of thinking that has been noodling around in my brain a lot… So back in the early nineties, I was in college, and I did a degree in computer science. My first job out of school was as a systems engineer for EDS. And one of the things that I think is interesting, you know, they put you through a fairly rigorous systems engineering development program. I think I probably undervalued the amount that the systems engineering perspective has really penetrated into how I think about things. We talk a lot about the idea in the Agile community of being a systems thinker, right.

But one of the things that I think is somewhat pervasive right now is that the idea of Agile and collaborative creation has somehow supplanted the idea of systems engineering. So what I believe we need to explicitly consider is: What is the system? How do we engineer the system that we are operating on top of?

And how do Agile practices enable that system? When we discuss the idea of transformation, when we think about implementing a new system of delivery, organization, or operating model, we are essentially discussing the systems engineering-focused design of that organization. How does work flow across the organization? What do interfaces between teams look like across the organization?

I have mentioned this in my videos before, but about five or six years ago, definitely pre-pandemic, I returned to my alma mater, the University of Florida, and conducted numerous talks on campus. I became involved in the Entrepreneurship and Innovation Group’s engineering leadership and participated in some of the industrial and systems engineering classes over time. During these interactions, when I discussed Agile with industrial and systems engineers, it prompted me to consider what the software factory looks like.

I started contemplating the application of industrial and systems engineering concepts to the software factory. The idea that has been occupying my thoughts is that Agile serves as a means of enabling the work cells within that factory. But what exactly is the factory? How does workflow function within it? In the Agile world, we are truly focused on empowering teams. Teams are the best people to understand how work is supposed to be done.

Recently, there was a commenter on one of our posts, and I responded with something along these lines: Imagine I am working on an assembly line responsible for installing doors on cars. In that specific task, I might be the most skilled person when it comes to understanding the mechanisms of putting doors on cars, right?

If there’s a problem with how we’re currently installing doors on cars, I might have valuable feedback on improving that specific task. However, am I necessarily the best person to engineer how the entire assembly line works or to reimagine the supply chain?

I believe there’s something in what we’re currently doing as an industry that assumes if we implement Scrum or SAFe, the assembly line and supply chain will naturally emerge. And to some extent, that may be true for smaller organizations that are ready to embrace Agile practices out of the box. Many things will naturally emerge from doing Scrum or SAFe, and impediments can be identified and addressed within the team’s operations.

However, a lot of these impediments are focused on optimizing specific aspects, such as making door assembly more efficient. What’s lacking in the Agile community right now is an emphasis on applying systems engineering and systems thinking to the overall process of software assembly. How does the software supply chain look at scale, even with the presence of scaled frameworks? I perceive these frameworks as operating models that assume the existence of a functional assembly line and supply chain.

But what if the assembly line is not effective? What if the supply chain is not effective? I’m not convinced that the individuals working on the assembly line are the best ones to provide advice in organizing the system or scaling the work. Furthermore, they may not be the most qualified to address the challenges of fixing a broken assembly line or supply chain and reimagining them.

In conclusion, I’d like to invite your feedback and input on this topic. Please feel free to comment and share your thoughts. I would appreciate guidance on which aspects of this discussion you would like me to delve deeper into. I believe there is much more to explore, but I want to ensure we are on the same page.

So, please provide your comments, and I look forward to your guidance. I’m not convinced that the individuals working on the assembly line are the best ones to organize the system, scale the work, or reimagine a broken assembly line or supply chain.

Okay, and there’s a book I’m reading, and I apologize as it just came to mind. I’ll ask my team to provide a reference for it in the comments or something. There are a couple of books on Agile systems engineering that I’ve been reading, by Dr. Bruce and others. I’ve just started on both of them, and they’re really fascinating explorations of what systems engineering looks like in relation to agile software delivery.

From the early stages of reading these books, it seems that they focus more on systems engineering for products. However, what we’re really discussing is systems engineering applied to organizations. When we talk about transformation, we’re not merely talking about improving collaboration in building doors. Transformation involves examining the aspects of the assembly line and the supply chain. What does that look like?

I understand that many individuals may dismiss what I’m exploring here because they don’t necessarily like the idea of an assembly line for software. Some prefer the notion of craftsmanship and almost a boutique-style delivery. It’s as if we’re suggesting that if we were Ford Motor Company, we shouldn’t be mass-producing cars but rather building unique Lamborghinis. However, the reality is that many software organizations strive to operate at scale and undertake significant endeavors. This often necessitates a certain level of systems engineering focus.

Over the years, we have observed that there are situations where agile delivery is attempted within non-agile systems. I have a talk called “Faster Food and a Better Place to Sleep” where I worked with a hotel chain and a fast-food restaurant, both based in Atlanta. We discussed agile delivery and non-agile systems. In these scenarios, the software factory is essentially an idea factory. How do we facilitate the flow of ideas and decision-making through the system? It’s an intriguing concept to explore.

So please don’t dismiss this idea outright, as at a certain level of scale, you will encounter software as an assembly line or a software supply chain. The supply chain may involve ideas, feedback, and validation. While the actual building of individual parts may have a unique and boutique nature at the work surface level, the decomposition of ideas into actionable work and the aggregation of those ideas into integrated deliverables becomes a supply chain problem.

Over time, we may attempt to delve deeper into these concepts. I’m unpacking ideas from various angles, but fundamentally, Agile, even in pure-play software, is an exercise in systems engineering. What does it look like to engineer a system of delivery at scale within a large enterprise? Once again, I would love to receive your feedback and understand which ideas resonate with you. Please feel free to leave a comment, and I eagerly await engaging with you there. Have a great day, everyone. See ya’

The Agile industry seems insistent that practices, 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

If we keep beating the drum that it’s about methodology and practice and mindset and culture and we can’t wrap our head around what a broader operating model is going to look like, we’re going to wear everybody out. I think we’re fighting the wrong battle talking about scaled methodology. I think what we have to do is talk about the principles that make small team agile and scaled methodologies work and focus on the idea of scaling the principles behind these methodologies rather than scaling the practices behind the methodologies.

(Musical Interlude)

The Limitations of Scaling Agile Practices

So what we’re going to talk a little bit about today is the idea of scaling principles versus scaling practices. And let me tell you what I mean by that. Over the last 20-some-odd years, we’ve had a progression of Agile methodologies and a lot of innovation in the Agile methodology space as of late. But if you look over the last 23 years at this point, something like that, we kind of started with some relatively small team Agile stuff, right?

So we have things like Scrum and extreme programming, or if I get really out there, talk a little bit about Alastair Cockburn’s crystal clear stuff in his family of methodologies. And then probably 15 years ago at this point, maybe a little bit more recently than that, we had Dean Leffingwell come out with the Scaled Agile Framework.

We had Bas Vodde and Craig Larman started to talk about large-scale Scrum. I guess it was Scrum Inc, maybe it was Schwaber and Sutherland who came out with the whole Nexus thing. We have Ambler with Disciplined Agile Delivery. We have some of the work that Ash Callaway did with his Flex model. We have the PMI ACP stuff.

And what’s really interesting is, as we go into really large organizations, it’s like the methodologies that we’re talking about don’t fundamentally scale. Even if you think of something like SAFe, SAFe is a methodology for dealing with what, 150 people is the recommended size? And SAFe is going to make some assumptions about that. It’s going to assume that you have encapsulated value streams. It’s going to assume that you have well-formed Scrum teams. And when you start to set up your release trains and you start to do your planning, Dean Leffingwell makes an assumption that we’re at about 150 people.

So when you start talking about doing even a scaled framework in a really large organization, it’s difficult because at some point the organization is going to hit the limits of the methodology.

One of the things that I’ve heard the last guys talk a little bit about is that it’s not really about scaling the methodology. It’s really about scaling the organization. And if you think about what that means, it’s not that we’re not going to do big products and it’s not that we’re not going to have large companies.

But when we talk about scaling an organization, what we’re really exploring is the idea of how do I create entities within the enterprise that are loosely coupled from the other entities within the enterprise. So if I’m dealing with something at the team level and I’m talking about Scrum teams, I want to have teams that have few, if any, dependencies between them.

If I’m up in the scaled areas, then I’m talking about having maybe value streams that don’t have dependencies between them or I’m talking about work groups that don’t have dependencies between them or product areas that don’t have dependencies between them. But when you start getting into really, really large organizations, there are dependencies everywhere.

And so when we talk about scaling so that either a team or a work group can operate with greater agility, what we’re really talking about is how do we look at the organization in a way that we have smaller groups that are able to actually own delivery, have interaction with a customer or product owner or aspect of the business, and can operate relatively independently from each other.

So this idea that it’s not the practices of the methodologies that scale, it’s really the principles of encapsulation versus orchestration that fundamentally scale. It’s the idea of small batches that scale. It’s the idea of creating flow across those small batches that scales, the idea of a learning or a can process that scales, right?

So there’s a lot of stuff within the Agile world that absolutely is applicable across the entire enterprise. But when we think about it from a practices-first perspective, there’s going to be some size of the organization that the methodology is going to hit. Dependencies, organizational impediments, organizational design, technology, architecture, anything that creates any kind of dependencies, the methodology is going to hit that and it’s not going to have an answer for it. That’s the problem, right? That’s the thing that we’re trying to solve.

Descaling Large Organizations to Scale Agile

So when we talk about transformation strategy, what we are fundamentally talking about is how do we systematically over time start to create this notional idea of a decoupled enterprise?

How do we start the process of breaking dependencies so that teams, work groups, product areas, or different parts of the organization can operate more independently? This is why I think it’s super important. Companies out there, we’re 20 to 23 years into Agile as a formal thing, right from the signing of the Agile Manifesto in 2001.

Agile methodologies have been emerging for ten or 15 years prior to that, maybe even longer. One thing that I find really fascinating is that we haven’t given up on Agile yet. I know some people have. We have some clients that won’t even use the word “Agile.” They know they need agility, the performance characteristics of an Agile organization. But they’re so burned on the dogmatism of Scrum or the dogmatism of SAFe that they don’t even want to talk about it.

We have some big problems to solve organizationally, such as how do we get organizations building the right products? How do we get organizations building products that customers are going to use? How do we get organizations building products on a regular release schedule, making sure that we’re doing the most important things right? We have some really big challenges. The only reason we haven’t abandoned Agile yet is that we haven’t really come up with anything better. If you say, “Agile isn’t the answer,” where are you going to go back to? Functional silos? People focused on activities rather than outcomes? Big upfront planning and long release cycles? We just intuitively understand that isn’t the answer.

We’re looking for the answer. You’re starting to hear the industry around stuff. Is that a DevOps problem? Is that a digital transformation problem? Is it a business transformation problem? You’re putting new labels on things, but we’re fundamentally talking about the same thing. We want to have small encapsulated teams that are focused on an area of the technology that are closely coupled to the customer, that can produce working, tested, and validatable software at the end of every sprint.

We want to be able to produce working, tested, and validatable software in a way that’s reliable and consistent across the organization. When we have multiple teams that need to come together in multiple workgroups or multiple product carriers, we need an organizational channel planning metaphor that allows us to flow value across multiple teams. That’s why it seems like every week I come online here, I’m doing podcasts with Dave, and we’re talking about what it takes to really do Agile at scale because I don’t think we have a good alternative yet.

At the end of the day, complete cross-functional teams organized around value that have autonomy over their technology stack, that are rapidly getting feedback from clients that are testing as they go, that are continuously deploying – maybe I’m myopic, maybe I’m too close to the problem – but I don’t see us coming up with something fundamentally better.

The challenge is my constant struggle with the world of Agile and Agile methodologies. Some people call it the Agile industrial complex. Maybe we’re a part of that, I don’t know. But this idea that we can install Agile via training, methodology, and so on – that’s the part of the Agile movement that I believe is failing right now.

If we can create small, encapsulated teams that are operating in a more continuous flow model, testing, getting feedback right, we have the opportunity to fundamentally do Agile in any size organization. We’ve been fortunate to work with some really, really large organizations, tens of thousands of people going through Agile transformation, and in every single one of them, it’s never been the methodological elements that have created performance and scale.

What it really is – and I guess we could use the word “scaling” – is about breaking the organization up into encapsulated entities so that each entity can operate with agility. Once the whole organization is operating with some level of agility, we can start orchestrating in small batches across and do some really interesting things with multiple teams at scale, managing flow with Kanban systems at a program or portfolio tier level. We can start managing investment strategies, tying up to OKRs and KPIs, looking at the business architecture of the organization, and understanding where we’re going to have bottlenecks in our system. We can invest in those capabilities over time so that we alleviate the bottlenecks in the system.

We can start running the entire enterprise in a way that’s risk mitigated where the risks are front-loaded in the system. And you can really do some pretty interesting things.

The net result of all these interesting things is getting past the idea that it’s going to be the implementation of a methodology that’s going to do it. Again, I feel like a broken record sometimes coming on and saying these things. If you have a blog post, I’m going to do a companion to this video that, hopefully, you’ll be able to read in conjunction with it.

The challenge is, as an industry, we’re going to have to start figuring out how to talk about some higher-level things. We’re going to have to start talking about things that businesses at scale really care about. It’s investment strategy, faster time to market, being able to get the organization to inspect and adapt and to pivot effectively. The only way we have found to do that is through this idea of descaling.

Scaling doesn’t mean we’re not going to do big things. It means that the big things will be amalgamations or roll-ups of lots of smaller things.

On Reengineering the Software Factory

So, one of the metaphors that I use, I happen to be a University of Florida guy, and so over the last couple of years, I’ve been doing a lot of work down on campus with the entrepreneur and innovation group—engineering leadership. And probably six or seven years ago, I got connected to the industrial and systems engineering program. And, I started talking to the professirs and the students in that world, and I was kind of asking them about what they were doing. And it kind of dawned on me that I think what we have is, we have an industrial and systems engineering problem. But basically what we’re doing is we’re trying to figure out how to re-engineer the software factory. Sometimes I tell those kids that there really is an assembly line of sorts that’s going on. You go into an IT shop and see a bunch of people sitting in team rooms, cubicles, or working from home on Zoom. The idea is that we have all these people sitting and typing at their computers, but they really are delivery pipelines, an assembly line of sorts.

There’s a metaphor where you start to think about components that are being created and arriving in a just-in-time way and being assembled into larger subsystems. Subsystems are assembled into ultimate products. We’ve done a lot of work in the defense industry and automotive industry. When you start to look at how physical goods are made on an assembly line, there are serious metaphors. It’s almost like the difference between doing a really high-end boutique car made one at a time versus having a factory of things where teams are working on user stories that roll up into features, and features are continuously delivered.

Features get rolled up and delivered into an epic or an initiative, and the ROI of the initiative gets tied up into an OKR. We can argue whether that’s Agile or not, but there’s a huge opportunity to think Agile, independent teams at the work surface level, but then agility at the program, portfolio, investment tier levels.

There’s something here, right?

Why the Agile Industry is Stuck

One of the things I want to do over the next week, month, couple of months is to start talking about some higher-level things in the industry, such as how to deal with OKRs, business architecture, investment strategy, enterprise architecture, leadership in organizational design, and all those kinds of things. But if our mental model is installing Agile by installing a methodology, and that’s where it ends, then I think we’re going to lose an opportunity to have a broader conversation.

Candidly, I think that’s a big part of why we’re stuck as an industry and why nothing else has emerged so far. The challenge is not a better methodology. The fundamental problem is understanding organizational design, dependencies, and breaking dependencies. As Agile coaches, we need to call this to a higher level of thinking.

A few weeks ago, I was in a room with one of my Agile coaching friends talking about something as simple as forming the right kinds of teams, and I think a lot of us have given up that it’s even possible. How do we elevate the conversation as Agile coaches and consultants in the Agile space to talk about how to organize in such a way, break dependencies, and effectively scale these enterprises?

I don’t mean be scaling in the sense that we only do small things, but we be scale in the sense that we have encapsulation and minimal orchestration from the work surface all the way up into the broader enterprise. Understanding that, having our heads wrapped around that, is what will give us the language to talk about higher-order concepts.

In addition to those higher-order concepts, we’ll talk about how to form the right kinds of teams, how to break dependencies, and how to move an organization from a scaled mindset to a descaled mindset, an encapsulation, minimal orchestration mindset.

And again, just to kind of close a sub, the reason why I think this is so important is because if we keep beating the drum that it’s about methodology, practice, mindset, and culture, and we can’t wrap our head around what a broader operating model is going to look like, we’re going to wear everybody out.

We probably have, to some degree. So, you know, maybe sometime in some of my next sessions, what we’ll do is we’ll actually get a virtual whiteboard, and we’ll start drawing some of this stuff out and exploring. But for now, that’s all I kind of want to say, kind of a shot across the bow in terms of I think we’re fighting the wrong battle.

Talking about scale, methodology. I think what we have to do is we have to talk about the principles that make small team Agile and scaled methodologies work and focus Transformation on the idea of scaling the principles behind these methodologies rather than scaling the practices behind the methodologies. Because if we can get the principles of encapsulation and orchestration, break dependencies, balance capacity and demand, focus on small batches, and we hold those higher than we hold the practice side of it, then we can start making some really wise choices about how to do org design, how to do governance, what to measure, what to control, what practices actually make sense for our organization.

We can talk about how systems and practices lead to culture. We can start talking meaningfully about Transformation strategy. We can talk meaningfully about how do you continuously improve an organization over time? We can talk about strategies for getting alignment across your organization, Shared Cognition. But all of that stuff is really, really difficult if we’re taking a practice focus.

So I’ll just tell you personally, like sometimes in these videos, I feel a little bit stuck. I feel like I constantly want to go back to the basics because I don’t think as an industry we’ve aligned around that yet. And so to talk about the promise of higher level organizational Agility, it’s almost like you have to reset the understanding of team-level Agility.

We did a conference a couple of years ago at this point called Elevate Agile, and the first one we did in Atlanta a while ago. It was a little bit frustrating because it’s like that was the trap that we fell into. We were trying to have this really high-level conversation about what does Agile really look like at scale?

How do we tie it to business problems, how we deal with governance and corporate issues, and all these different things? But we got trapped in this idea of laying the foundation of team-level Agile, so we had to do a dance halo around to figure out how to have these higher-level conversations, understanding that these principled underpinnings are what’s really important.

So I’m going to try to hunt that out. I don’t have any answers of exactly how I’m going to do it just yet. But that’s what I’m going to hunt for. And so super informal, super exploratory. I’m going to try to share some of the things that we’ve been doing for the last 13 years with you guys and just open up a conversation and see where it goes.

And so it’s not going to be like me sitting here saying, “Hey, this is the answer.” What I’m going to try to do is open this conversation up and just explore some ideas and see what you guys think, right? See if there’s a way that we can move the industry into a healthier way of understanding what is really going to drive Agility.

And I’m telling you, it’s not Scrum, it’s not XP, it’s not SAFe, it’s not LeSS, it’s not any of these things. It is the principles that underpin those things. And then what will start to happen is we get really, really good at applying those principles. Organizationally, methodologies are going to start to make a whole lot more sense. So that’s what I have to say with you guys today.

I hope you’re enjoying some of these new videos that we’re doing and some of the thinking that we’re trying to put out. I hope I don’t sound like too much of a broken record, but we’ll see what we can do to pivot past this over the next couple of weeks and months. So you guys have a great weekend.

We will talk with you next time.

LeadingAgile has worked with lots of clients 13 years into our existence. In our experience, the number one barrier to doing Agile at scale, to running a successful Enterprise Transformation, to achieving true Business Agility is creating complete cross-functional teams at the lowest levels of the organization.

What do I mean? If we can’t create complete cross-functional teams at the work surface, where code actually gets written and deployed, how do we expect to run a successful Transformation or achieve any notional idea of Business Agility?

Why don’t we do this? Because a lot of companies aren’t set up that way. Technology isn’t built in a way that supports it. Dependencies are rampant across the organization. And no one besides us, as far as I can tell, is even talking about the problem, let alone coming up with a way to do something about it.

So, we get trapped in this mental model that it’s all about bad leaders. If management would just get out of the way and let us do our thing, all would be right with the world. If managers would stop putting pressure on us to deliver on time, on budget, and on scope, life would be good.

Let me tell you why they don’t. Agile practices on top of a functionally siloed organization, a poorly architected solutions architecture, and a traditionally governed enterprise are a recipe for chaos. If I was your manager, and these were my constraints, I’d be top-down command and control too.

Centralized orchestration would be the only way.

Again, I feel like a broken record. Can’t tell you how many rooms I sit in where these ideas are ignored. We can’t get the conditions we want, so we double down on the idea that management is bad, the culture is bad, and that the organizational anti-bodies are the things that are shutting us down.

Agile is about fixing time and cost and varying scope to maximize value. How many teams do you know that are complete and cross-functional and have everyone and everything necessary to deliver a working tested increment of product? How many have an empowered Product Owner or direct access to a real customer? How many can actually deliver something of value at the end of every sprint?

Let alone how many can regularly meet a sprint commitment or a release commitment with defect-free, potentially shippable software. Maybe it’s a function of what I write about, the people that call us, or the people that show up to Agile conferences, but my sense is that it’s not many.

Release trains are made up of collections of Agile teams. Value streams are made up of collections of Agile teams. Workgroups are made of collections of Agile teams. Departments are made up of collections of Agile teams. Business units are made up of collections of Agile teams. How can I have Agile release trains, Agile value streams, Agile workgroups, Agile departments, or Agile business units if I don’t have Agile teams?

How would I expect any aspect of my larger enterprise to operate with Agility if my teams can’t operate with Agility? The short answer is that you can’t.

That is why properly formed teams, operating off properly formed backlogs, who can produce a properly formed increment of value, is the first step. And if those types of teams aren’t in place, then forming those kinds of teams is the only step that matters.

When we talk about Agile at scale, we’re talking about collections of these kinds of teams. When we talk about Agile governance, we’re talking about how you feed work to collections of related Agile teams so that their efforts can be integrated into larger deliverables. When we talk about Agile metrics, we’re talking about how to scale concepts like velocity or cycle time up to these larger increments of value.

In the Absence of Agile Teams, Nothing Makes Sense

You see, none of the higher-order concepts make any sense unless you have teams that can do what they say they’re going to do when they say they’re going to do it. There is a way to guarantee that happens, but getting there is really hard. So, as I unpack this over the next however many weeks. If we want to talk about higher-order constructs of an agile enterprise. If we want to unpack how to achieve measurable business results with Agile, we’re going to have to assume that Agile teams exist. That they’re working off well-formed backlogs. And able to produce a working tested increment of product at regular intervals. Potentially shippable and deployable.

If you don’t have that, you have no chance of doing Agile at scale in a meaningful way.

So, think about that. What are the barriers in your company to forming the kinds of teams you need to form? Building the kinds of backlogs you know you need to build? And getting to a point where you can deliver a working tested increment of software to your customers every two weeks?

I know the stuff that used to get in the way when I was a project manager delivering work. I know what gets in the way for our clients. But what’s your experience?

What is preventing you from doing Agile the way you know it’ll work?

When organizations set out to adopt Agile, they always have a business reason. It’s never just because they really love Scrum, or SAFe, or LeSS. But when the teams start doing all the Agile things, and they’re met with resistance from the organization around them, it’s hard to point to success because not much changed. So, we start defining success as “do the roles and ceremonies exist and are we following all the Agile dogma.” That’s a poor definition of success, and we have to get better at changing the organization around the teams. But that’s a different problem altogether. To do that, we’ll have to deconstruct what people, especially leaders inside organizations, believe about Agile and get them to see it through an all-new lens.

Mike and Dave sit down to begin deconstructing some of the current beliefs about Agile, and talk about what success actually looks like in this week’s episode of SoundNotes.

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/

If you could magically create a new world where large organizations had overcome the barriers to Business Agility and Agile came naturally, what would have to be true about that world, the organizations, and the people working there? To make your new world a reality, what beliefs and worldviews would need to get left behind? What would the organizations have to look like? And how would we know that this new Agile world was any good?

Join Mike Cottmeyer as he shares some of his earliest observations and latest thoughts on the Agile industry and explores what must be true for Agile to succeed.

Video Transcript

We’re not talking about doing local optimization. We’re talking about doing large-scale change. We’re not talking about creating agile projects or agile teams. What we’re doing is creating agile organizations and whether that be transforming existing organizations or creating models for new organizations that are going to come down the pike over the next 10, 15, 20 years.

What do we want to be educating our new leaders on? What old things do we want to deconstruct and pull into a new paradigm? What are the current beliefs that need to change so that we can do this really well?

(Musical Interlude)

So hey everybody, how are you guys doing? So we’re going to talk a little bit today about some things that have been noodling on for a while. And what I’m going to try to do is I’m going to try to enlist your help and your support and help me figure this out a little bit. So as you guys know, Leading Agile, we are exclusively in the change management business.

Typically, we’re doing Agile transformation and all the change management is associated with that. And one of the ways over the last 12, 13 years that we’ve been around and really before that when I was just doing social media stuff on blogs and Twitter and things like that. But a big part of what we try to do is we try to educate people on how to think about change, how to think about Agile transformation.

Because if you call us up and you say something like, “Hey, we want some training,” you know, it’s like, “Okay, like what do you want to be trained on? What do you believe? What’s your environment like?” There are a bunch of different things, right? And so if you show up and like you say, “Hey, I want to adopt Agile,” but you know, you’re not familiar with the strategies or Agile governance strategies or such, right?

There’s just a lot of stuff to unwind. And so what we try to do is, which I do a lot of videos like this, to enlist people and to get people thinking around things the right way, and the people that see things our way and have a need for our services will typically pick up the phone and call.

And so I started thinking about this week all of the different things that really go into helping somebody fundamentally see how to transform. So I started taking some notes. I have some notes over here on my page. And so I’m going to kind of do a survey of my top-of-mind stuff throughout the week.

And then the idea is I’ve got my marketing team on the call with me right now. They can’t, you actually can’t see them, but they’re listening, and they’re going to take this and turn it in and edit it and all that kind of stuff. And then what we’re going to do is turn it into a series of more micro topics.

There we go. So today is kind of like a survey. And what I’d really love for you guys to do is as you’re listening to this, to start to think about for me, am I missing anything? Like what other barriers do you see? What other conceptual gaps?

Success in Agile

And so the first thing I want to talk about a little bit is the idea of what does it actually mean to be successful with Agile? And on the one extreme, you have things like the actual business results you’re going for, whether it be predictability, quality, putting things in market fast so you can charge for them, particularly your return investment cost savings.

Are we optimizing the throughput of the organization? Are we doing it in a cost-efficient way? Do we have the right people in the right seats? Innovation, are we able to get feedback from customers and invent products that they want to use, product fit? Are we generating the right kinds of feedback to make sure we’re building the right products, whether that be innovative or more in a structured way?

But then, and so those tend to be like the business benefits of it, right? And the other side of that coin, and this is something that we see a lot, is like success for Agile tends to be like, are we doing the practices effectively? And there’s like this assumption that says something to the effect of like if we’re doing the practices effectively, theoretically we should be getting the business results from it.

But as I’m sure a lot of you guys have seen as a lot of people run around doing Scrum or SAFe or whatever, and they’re not actually achieving the goals of agility and you know what’s hard? And I won’t go too deep into this one, but what’s really difficult about that is that the there are impediments in your organization that people can’t fundamentally change.

And so because they can’t change the things that are getting in the way of agility, they start defining success in an Agile transformation as, are you doing the Agile things?

And so, on the one extreme, it’s very much like a cargo cult kind of, you know, if we do these things, it will happen versus all the way on the other side of measurable benefits, business benefits. And so one of the first things we try to help people overcome or get really clear on is what does success look like? Why are you doing this, and what does success look like?

The Possibilities of Transformation

The second thing that is interesting, and I gave a nod to this in a talk a couple of weeks ago coming out of the Triangle event that I spoke at. And the idea is, is like what is possible to change in the organization? And there are a lot of folks that are adopting Agile that are in organizations that are really, really difficult to change.

And you know, we get into clients like that and our consultants get faced with these things all the time where you live in this kind of this weird dichotomy of I know these things must be true to be successful, but the organization doesn’t seem to want to change them.

And so, to some degree, you have to cast a vision for what is possible to change, of course, the vision. But you also have to sometimes get people to suspend disbelief enough in terms of what’s possible. Because as we know, right, Agile requires a certain kind of operating model to really be functional at scale and to achieve the goals.

So, the challenge that we have is we have to get people to suspend disbelief that certain things that are hard to change are actually not impossible to change. And that there’s a path forward and there’s a way to engage in doing this.

So, you know, the first point is, why are we doing this? Like, why does it matter? What does success look like? And then what are the things that we’re willing to tackle in the organization to create the conditions to be able to achieve those goals? And so those are the first two things I listed.

The Physics of Transformation

The second thing that I was thinking through was stuff that we’ve done talks here over the last couple of years, what I call the physics of transformation. And there are certain really interesting rules, right? Like we have to be able to bring capacity and demand into balance.

And so from an Agile perspective, like if I know the size of my backlog and I know the velocity of the team over 100 points in my backlog velocity, the team 20, you know, we’re not going to pull more than 20 points into a sprint, and we know it’s going to take about five sprints if we want to get through the entire backlog with negotiation and variation, we have to bring capacity and demand into balance because most organizations we go into are like ten times overloaded. It’s not just about cost savings, but also trying to figure out value density and what path through the backlog will deliver the most value within the time and cost constraints.

Organizing around value is important, especially in early-stage adoption of Agile. While projects are valuable, they are also transient and encourage a cost accounting versus a throughput accounting model. To overcome this, we need to organize around the persistent value objects in the organization, such as value streams, feature sets, or business capabilities. However, there is a conceptual challenge to overcome as many people still believe in organizing around activity, putting people in functional silos and assigning them work based on their skill set. Without overcoming this, it is hard to make a case for Agile teams.

What’s Getting in the Way of Agile?

The idea of theory of constraints is also important, where we optimize for the flow of value, limit work in process, and prioritize getting things finished before starting new ones. Identifying constraints in the system and moving resources to the constrained objects helps increase flow through the system. These conversations often involve cost accounting versus throughput accounting.

And so if you’ve grown up in a traditional mindset, you’ve grown up in a traditional project management model. Very often those folks are centered around the idea of functional silos, local optimization, focusing on cost accounting versus throughput accounting, where Agile tends to be more like organizing around value, sub-optimizing the idea of cost for the elevation of throughput, making sure value streams are encapsulated, things like that.

The idea of encapsulation versus orchestration, you know, so we have to overcome the idea that when you organize around value, you want to do it in a way that minimizes dependencies because when you have dependencies in place, you have to break dependencies, or you have to manage them. A lot of times Agile is in the presence of dependencies and wants those dependencies to self-organize away. So, it’s like the traditionalists want to hyper manage dependencies. A lot of agile folks want to ignore dependencies and believe the team will self-organize. Often there’s a middle ground, but you have to make the case for that middle ground a little bit. So, there are underlying thinking tools that are involved that we have to get people to be able to see.

Does the Methodology Matter?

Probably the third category of stuff, and this is what I find interesting about the industrialized agile frameworks at this point. So, you think SAFE, Large-Scale Scrum maybe, although I don’t know that fits in that category, Scrum as a model, XP as a model, and things like that. The idea that it’s a description of the methodology that matters. We talk in LeadingAgile a lot about the idea of reference architecture versus reference implementation.

And what I say about SAFE often is that it is very valid. It’s based upon a very valid reference architecture. Scrum teams at the bottom, some sort of orchestration mechanism, the product middle tier, some sort of orchestration mechanism up at the portfolio tier, some linkage to investment tier investment strategy, focusing on the flow of value at each level, understanding lean principles.

So fundamentally, under its core, I don’t have any issue with SAFE. I think SAFE is fine. There are things that we often will do differently or in addition to or subtract from a SAFE-type model. But the point being is that almost all scaled methodologies, probably all scaled methodologies, are built around some sort of fundamental reference architecture that we believe is inarguable.

Then on the other side of that, you have this idea of reference implementation. And that’s where I think SAFe gets a little wonky sometimes, is that it’s a specific reference implementation on top of a very valid reference architecture. And so, what happens, and it happens always, that happens with the PMBOK. It happened with RUP, it happens with SAFe, it happens with Scrum, it happens with everything.

We take the implementation details and say that it’s the details, right? The roles, the ceremonies, the artifacts, the cadences, all those different things that we model as implementation details. We take that as the thing and then we over-index on having the roles, having the titles, having the ceremonies, having the artifacts, all those kinds of different things.

And so you take something that’s very valid, like SAFe, and then you pick up the reference implementation as described in the SAFe materials and SAFe training. The people that invent these methodologies will acknowledge that they are designed to be tailored. But in practice, very often they don’t actually get tailored, right? They get implemented as a whole because people want to believe it’s the implementation details of the roles, the ceremonies or what have you, and not the underlying reference architectural patterns.

You have to help people see it’s like this weird, non-dualistic way of thinking about things. The patterns are immutable, the implementation details are helpful. And then we have to ask ourselves what implementation details are going to help us best support the reference architecture patterns that are actually the secret sauce.

If I think about that from a really simplistic perspective, you take something like Scrum. So one of the things that I do from a reference architecture perspective is I talk about the three things. So what is the fundamental pattern of Scrum? The fundamental pattern of Scrum is that you have a dedicated team organized around value with few, if any, dependencies.

You have a well-defined backlog, and you’re able to produce a working, tested increment at the end of every sprint. To me, if you have those three things in place, that’s the only thing you need to be able to do Scrum. Now, you can further specify that you say, okay, the product owner is the one that creates the backlog, and the team is made up of these roles and not these other roles.

And you know, this is what it means to get to a definition of done. And we can be really dogmatic about, “Is there a Scrum master? Is there a product owner? Is there a burn down chart? Are we using sticky notes on the wall? Are we doing story point estimating or are we using planning poker? Are we doing reviews? Are we doing retrospectives? What kind of reviews and retrospectives are we doing and how are we doing them?” Those are all details, right? And sometimes they’re helpful details and sometimes they’re not.

And so, like, I’m not interested in the prescription of Scrum that says you have to have a product owner as helpful if you have a product owner as Scrum describes it. But if you don’t like putting a business analyst in front of a backlog, someone who doesn’t have the background understanding, it’s not helpful.

Putting a ScrumMaster on that team that can’t actually go out and remove the organizational impediments that are required often isn’t helpful. But that’s what we’re doing in practice, right? So helping people understand the difference between reference architecture and reference implementation, and whether there is a different implementation that can help us more effectively achieve our goals when we deeply understand the patterns, the principles, reference architectures that are involved is important.

So, you’ve got to get people through that kind of hang-up.

Recommended Approach to Agile Transformation

Which really leads us to something else that I talk about quite often: the idea of systems first, systems practices, then culture. If I can get the training strategies right, I can get the governance strategies right, I can get the measurements right, so I call systems then, and I can start to build a solid system of delivery on top of those patterns.

Then I can create the conditions for the Agile practices to come in, right? So I can pick out elements of Scrum and Kanban and SAFe and LeSS and things like that, right? XP. And then I enable it with really solid practices, and then culture can emerge over time.

Common beliefs suggest that culture is the primary obstacle to Agile taking hold, but there is also some truth to the idea that teaching Agile practices alone will solve all problems. However, education is key to understanding what makes Agile different from traditional project management, which often does not address organizational design.

Agile inherently implies organizational design, and without aligning the systems, operating model, and methodology practices, it is unlikely that a culture of Agile will emerge. Therefore, it is important for people to understand this fact because the competing belief is that changing mindsets alone will solve all problems and ensure the success of Agile.

However, this is not always the case, even when leadership teams are fully committed to Agile. For example, teams may have the spirit of agility but be hampered by a poorly designed technical architecture that is not congruent with Agile principles. In such cases, having the right attitude is not enough if the underlying technical architecture, organizational design, governance framework, and measurement are not consistent with Agile.

Although it may feel like an attitude problem, it is important to recognize that an operating model needs to be developed. Implementing solid practices is key to changing hearts and minds over time. Therefore, education plays a significant role in helping people grasp the intricacies of Agile transformation.

A Holistic Look at Change Management

There’s another thing that I’ve been thinking about a lot as we work with larger and larger clients and we start to deal with really issues of scale. And it’s a classic like Blind Man and the elephant problem. And I think you guys are probably mostly familiar. I mean, I know I got introduced to this parable through the Agile community probably 15 years ago at this point, but the idea of the blind man and the elephant, you have these three blind men that are standing next to an elephant and one’s touching its ear, one touching its tail, and one touching its leg.

The one touching its ear says an elephant like a palm tree, right? As fronds and leaves and things like that. And the one touching the tail says, no, it’s more like a snake where you have because it’s long and thin and flips around and stuff. And the one touching the leg is like, No, it’s like a tree. And they get in fights because they’re all looking at the same thing from very different points of view.

And it’s weaving practice. It’s like, you know, we get involved in leading Agile. It’s not just in team level transformation, but in enterprise-level transformation, a whole IT organization transformations we get involved in, helping people change their financial governance strategies, KPIs, OKRs, things like that. And in doing so, DevOps transformation, right? Digital transformation, business transformation, business agility, right, all these buzzwords, right? They’re all aspects of the same thing at the end of the day, right?

What people are trying to figure out how to do is to use technology to leverage technology to generate better business outcomes. And so some of it is, it’s like I think there’s almost, and I should probably try to write an article on this or something, but it’s like there’s almost like a unified theory that is starting to emerge that really takes like you can take things like, you know, we talked about structure, practices, and culture kind of in the Agile world.

You can tie that to the whole Occupy movement, you can tie it to a digital transformation story, you can tie it to a DevOps transform story. One of the fascinating things we’re seeing right now, a huge opportunity in the market around DevOps, and it’s like you could almost ask yourself the question why DevOps fails? I’m not a deep DevOps expert.

I’ve got a lot of really deep DevOps experts on my team. But what’s kind of funny is that DevOps is failing for the same reason everything else is failing. It’s like, we treat it like it’s a tool problem or we treat it like it’s a practice problem or we treat it like it’s a mindset problem.

And almost always, it’s an organizational structure problem, it’s a governance, it’s a working tech problem, it’s a culture problem, it’s an adoption problem, it’s a lineman problem. It’s an integrating with the whole problem. And so when we take a thread like DevOps, highly unlikely if we’re not thinking about it from a systems perspective that we’re going to get a lot of stuff wrong.

And so you start to weave when you think through this blind man and the elephant lens. It’s like we’re all blind men and we’re looking at our particular piece of it and failing to respect that. The idea of organizational design, governance practices as metrics, culture, all these things, it’s all an integrated whole. And that has to tie together because it’s one fundamental company.

So investment strategy, OKRs, KPIs, audit controls, financial compliance, governance, all that stuff, product management strategy, requirements, decomposition, traceability, Agile delivery and execution, DevOps, enterprise architecture, all of those things are all part of the same story. And oftentimes we talk about it like three distinct things that happen in a company. But again, blaming the elephant problem, they’re all pieces of the same thing

Planning a Transformation

And like the last little bit that I want to hit on again, this is just kind of a top-of-mind exploration for me as I was contemplating what I want to talk with you guys about this week is, you know what the difference between what we call a system of delivery, a system of transformation. We also talk about a system of engagement versus a system of continuous improvement.

And there are really four questions that people are trying to sort through when they call us. It’s like, what does it look like? What is the operating model look like when Agile is done? Like how will we operate differently? I had a client in the early days leading Agile go, “What will be the evidence that you were here after you’ve gone?”

Something like that as a paraphrase of it. So, like, what will my organization look like when we’re done? That’s a question that people want to know the answer to. And so basically saying, “Well, it’s just going to emerge, we’re going to figure it out as we go,” is usually not a satisfying answer. There has to be a starting place.

So what is the end-state operating model look like? The second question is how are we going to get there? What is the transformation strategy? How are we going to introduce these ideas? How are we going to break up the organization? What are we going to form teams around? How are we going to do that? What are we going to do with resource disparities across the organization?

How are we going to measure progress on the transformation? How are we going to know what done looks like? How are we going to know we’ve actually improved? How are we going to know that we’ve actually delivered against the goals of the transformation? So you have the end-state model, but then you also have the transformation strategy, right?

So when you hear me talk about expeditions and base camps of outcomes-based plans and activity guides and leading and lagging indicators of the transformation, what we’re really talking about is how do you orchestrate the transformation, but more generally, like what does the change management around the transformation look like? How are we keeping everybody informed? How are we making sure the organization knows what to expect, what the impacts are going to be, right, all those kinds of things?

So there’s stuff that has to be overcome there. The third piece we call System of Engagement, which is a couple of different things, right? A lot of times for us as a consultancy, it’s really about like how we structure contracts and how we think about deliverables and how we think about milestones. But it’s also a lot about how our consultants collaborate with each other, how are they co-conspiring, collaborating with the client, how are we demonstrating economic value for the dollars that they’re spending with us?

Maybe most importantly is how are we reducing cognitive dissonance and creating shared understanding through the course of the transformation? So how am I going to get my stakeholders enlisted in being able to do this? And then the last piece is okay, once we’ve transformed, is that a one-time event or is that something that happens over time?

Well, I think in practicality the transformation has a beginning and an end. But an Agile organization is supposed to be continually adapting to market changes and new opportunities. Right? And in one way that manifests in terms of small batches and backlog items and epics and features and user stories moving through queues. But that’s a little bit like the work in the system, right?

But the challenge is there’s an element of stuff that’s on the system, like how do teaming strategies change over time when we need to enter new markets? How do we redeploy resources, people, teams, things like that into new opportunities? How does the organizer of the organization dynamically adjust it? We call that the system of continuous improvement. How do we continuously reevaluate the business architecture?

How do we align business architecture to strategy in an ongoing way? Simple things like when new people come in, how do we orient them to our new system and how we work? How do we educate them? How do we coach them? How do we support them? How do we find people that are capable? Like these things are all what we call the system of continuous improvement and education.

The point of education is that, you know, you think about it at one extreme. If I see Agile or as its own means to an end, like the goal of adopting Agile is that we’re doing Scrum. And so in that world, I say, “Okay, well, I’m going to train everybody on how to do Scrum.” And if everybody doing Scrum is the measure of success, okay, fine, right then, then we have a pretty simple worldview.

But in practice, right, our experience, and I bet your experience, is that really doesn’t work. It doesn’t work at scale. It works for a team that works for a small work group, right? No argument in the small, but in the large. Right. We have to have a greater conceptualization of all the different little pieces that have to be hooked into.

And so many people, it’s like what they want is they want an easy button. It’s like, “Hey, we want to do Agile. I’m excited about Agile. Can I get some training to do Agile?” And that’s good, right? It’s a great introductory step. A lot of our clients start off with kind of a training-first approach. They’ve gotten everybody doing the practices and just got really limited results. So then they start looking at scaled methodologies and they start trying to transform, but they don’t really fully understand the systems, practices, culture, interrelationship, right? So, so they introduce scaled methodologies and that kind of works a little bit. Or maybe they start trying to figure out how to do teams and agile structures and agile governance.

But, it just everything doesn’t click into place. And so, this idea that we can separate the definition of the operating model, the initial idealized end state with a separate strategy for how we’re actually going to move the organization around. And then a third piece that is how are we going to create shared cognition across the organization, do all the change management and then how are we going to stay there and make sure that we have a continuously adaptive organization over time?

So that was my top-of-mind list as I was sitting down thinking about what I want to say to you guys. So what I’m hoping you might do for me and I’d love for you to respond in the comments, whether you’re seeing this on YouTube or LinkedIn or Facebook or whatever. And my marketing team is going to be paying attention and they’ll alert me, and I’ll engage if appropriate, or we’ll deal with it in a subsequent video.

But I’d love to hear from you the kinds of what I would call conceptual things that need to be overcome. What are the current beliefs that need to change so that we can do this really well? I’d really love your thoughts on what you’ve experienced. I love to compare notes, see what you guys are thinking, and if you’d be so kind, help us advance this message because I think we’re on to something.

Paving a Way Forward for Agile

I think there’s a way of thinking about this that enables us to deconstruct existing worldviews and to build new ones. I think a lot about, and this is a total aside, but I think a lot about because I’m a University of Florida guy. And so pre-COVID, I spent a lot of time down there talking to the entrepreneur and innovation groups and leadership, engineering leadership, industrial and systems engineers, that kind of thing.

And I’ve thought a lot about like, what would you do if you’re going to build a curriculum to do large-scale transformation and you were going to mentor IS and agile transformation strategy? Like, what are the things that you would want them to know? What are the things that you would want them to believe?

And I think there’s a huge part of this that is industrial and systems engineering-oriented. I think there’s a bunch of organizational design, organizational psychology. I think there’s a lot of business and change management. We would pull in a lot of large-scale software architecture and then tons of industry knowledge and DevOps and project management and all these different things.

And so we have a big task at a strategic level. We have to convince people that we’re not talking about doing local optimization, we’re talking about doing large-scale change. We’re not talking about creating Agile projects or Agile teams. What we’re doing is creating agile organizations, whether that be transforming existing organizations or creating models for new organizations that are going to come down the pike over the next ten, fifteen, twenty years.

What do we want to be educating our new leaders on? What old things do we want to deconstruct and pull into a new paradigm? And so that’s what I want to explore with you guys. So anything you could offer would help, and I would love to engage in conversation on it. Thanks for your time, and I’ll look forward to talking with you guys next time.

Have a great day.

Today, the market for Transformation is a transition period. We see some companies looking for the next big thing, and others going back to what they know. Is this a sign that Agile is waning? Is it evolving? Or is Agile so deeply engrained in the way business gets done, people have just started calling it something else to deny the fact they just aren’t very good at it? Mike Cottmeyer and Dave Prior sit down to discuss this interesting moment in time for our industry and more in this episode of SoundNotes.

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 Transformation, Digital Transformation, DevOps Transformation; they’re all just different ways large organizations attempt to achieve the same results. And they all fail for the same reasons. No plan. No vision. No way to measure success. No alignment. And no results. For any of these approaches to work, we’re going to have to fall back on the principles of change management and get super intentional about how we approach Transformation.

Video Transcript

This idea of Digital Transformation, DevOps Transformation, and Agile Transformation are all starting to blend together, and the reason why these changes often struggle is because we don’t appreciate the complexity and the amount of intentionality required to execute them.

(Musical Interlude) 

The Reality of Change Management

Well, good morning, everybody. How are you doing? We’re a little off schedule here at Leading Agile. I usually record these things on Friday afternoons, but it is Thursday morning and my eyes haven’t adjusted yet, so I have my reading glasses on and some notes underneath me. But we’re working on some interesting content this week around the idea of change and change management.

As you know, I’m always talking about agile and agile transformation, but I had three events happen over the last couple of weeks that have really got my brain turning. The first one was when I was at the Triad conference in Raleigh, North Carolina, a couple of weeks ago, and I was doing a talk on how to change culture.

I’m generally not a culture-first kind of person when I think about agile transformation because culture feels like the problem, but it’s not actually the problem. There’s a lot of resistance to change and adapting behavior, but my belief is that if we get the systems and organization right, including teaming structures, governance, metrics, and controls, and enable them with solid agile practices like Scrum or SAFe, culture can emerge over time.

However, during the conference, a friend of mine from the Agile community, whom I have known for almost 15-20 years, raised his hand and said something to the effect of, “But when we go in, we can’t actually change the teaming strategies.”

And it was an interesting thing to me that there are coaches in the world, right, Agile consultants, that have totally acquiesced to given up on the idea that organizations are static and then we don’t have any influence over them. So that was like the first thing that got me thinking. And then the second thing that got me thinking was, you know, I guess it was last week or so we did a content series on SAFe and SAFe with Agile, and you know, one of the things that I think is interesting is, you know, most people don’t have the breadth of experience that like me and Dennis Stevens and a few of us do.

Yeah, I’ve been running this company for almost 13 years now, and then prior to that was working for VersionOne for a couple of years. And so, you see hundreds of Agile transformations. We’ve seen hundreds of different kinds of organizations. And one of the very persistent problems that I see is that, you know, people are going off of training, whether it be Scrum or SAFe or something like that.

And they’re bringing back Agile practices, and they’re trying to apply them on top of organizations that haven’t been transformed. Right. And probably just like that coach that I was talking about at your conference, they don’t see how to actually create decoupled teams or decoupled value streams and that kind of a thing. And so, I was having this conversation around, you know, SAFe not really prescribing a transformation strategy. And this lady on LinkedIn was kind of debating back and forth with me that it does. And, you know, so I went, okay, okay, like maybe I’ve missed something over the last couple of years. And I and I went digging around and, you know, what I see is, I see general guidance for issues around value streams. And maybe there is an implication that value streams should be loosely coupled, right? Not have a lot of dependencies between value streams is important.

When people attend Scrum training, they may assume that they will return to a complete cross-functional team. However, in practice, this is not always the case. Teams are often organized around things that may not necessarily be considered value, such as a feature set or a business capability.

Our perspective on Agile transformation is that we must ensure that team strategies, governance, metrics, and controls are all correct. If you try to apply Scrum or another methodology on top of an organization that is not ready for it, you will inevitably face difficulties. Although methodologies may implicitly or explicitly suggest encapsulation, I do not see evidence of a strategy for attaining it.

One comment that I make and I’m probably going to piss Bas Vodde and Craig Larmen off at some point in time, continuing to say this, but like in their first book, unless you know the way I kind of joke about it, it was like saying, “Hey, in order to do LeSS, you need totally encapsulated teams and yeah, it may take years, but you know, I keep at it.”

I was like the general tone of it, at least as I remember it. It’s been a few years since I’ve read that book, but that’s like where the work is, right? It’s like that cartoon where it’s a bunch of math on one side, a bunch of math on the other side. And then it’s like, “And then a miracle happens here,” right?

So sure, it’s one thing to say organize teams around value. It’s one thing to say we’re going to encapsulate value streams, but what if value streams and teams aren’t encapsulated? That’s really, really tough. We just started working with a client about six months ago. We went through and did kind of a funny and stayed.

We started working through all the different aspects to get prepared for some of the changes we were making. We’re running a pilot, a pretty small pilot, but some of the things that we need to have in place just aren’t in place yet. So, we don’t have the right team strategy. We don’t have the right persistent teams. We don’t have the right ability to build backlogs.

We don’t have the right ability to produce a working tested increment. And even amongst my team sometimes, it’s like you get into these big corporate bureaucracies and it’s like everybody you talk to says, “Yeah, that’s not possible.” “Yeah, that’s not possible.” “Yeah, that’s not possible.” “Yeah, that’s not possible.” But it has to be possible on some level, right?

Because that’s the fundamental physics of anything we’re going to do, it’s Agile, it’s encapsulation versus orchestration. We have to break dependencies, or we have to manage dependencies. And so, if we acquiesce, if we just give up on the idea that we can create the conditions, what I wonder is, are we able to ever deliver on the business benefits that we promised?

And I think what’s happened is because so many people see that kind of organizational change as impossible, what they define success as, you know, is are we doing the practices of Scrum or SAFe correctly? And that is never what we’re really trying to do, right? We’re trying to organize around value. We’re trying to get to the place where we’re closer to the customer, and we can deploy rapidly, and we can get feedback and we can inspect and adapt.

And if we don’t have a dependency-free environment, it’s really, really difficult to do. So there are a lot of things that we might recommend in an early-stage transformation that we call compensating controls, right? So in the presence of dependencies, or teams that aren’t formed, or governance that isn’t fully in place yet, you start to put that in place and you put some extra orchestration in until you can actually create the teams.

But it’s fascinating to me, the number of people in our industry that either don’t see it or they see it and they don’t believe it’s possible. And the net effect is that we’re doubling down on practices and not more effectively getting the business benefits from it that we’re trying to do. So, it’s a really interesting problem.

Introducing Change into Large Organizations

And so, there was an article from McKinsey and Company that came out a while ago. Tim Zack, my Chief Marketing Officer, sent it to me, and it was talking about the problems with Digital Transformation. What I thought was really interesting as I was going back to the idea of introducing change into an organization. I’m not really good at remembering specific details of different things, but I was thinking about the eight-step Kotter model of change. The Kotter model is very much like building guiding coalitions and wins, and all those things. It’s really super good guidance, but it’s not specific enough in terms of what those wins mean. The McKinsey article was basically saying that a lack of a clear in-state vision, a lack of clarity on what acceptance looks like, what done looks like, and how we are going to specifically get ourselves there, is a challenge.

I think a lot of change fails because we say, okay, we convince people of the problem, we might even be able to get them excited enough to want to do something about it. But the challenge is that we’re dealing with some very complex systems, very complex technology systems, complex organizational design, complex financial models, complex governance models, places where we don’t have really clear ways to adjudicate prioritization. We’re dealing with organizational politics. So when we’re dealing fundamentally with organizational system-level problems, those kinds of changes need to be incredibly thought out. We’ve had some success over the last 13 years since we’ve been in business, but really more maybe specifically over the last four or five years as some of our methodology has started to emerge.

One of the things we really distinguish between is the idea of a system of delivery, which is basically like your operating model, like your enterprise operating model, and the system of transformation, like how do you get to that end-state operating model? And what we’ve generally found is that there’s a lot of work that has to be done in order to enlist people around the patterns and principles that are going to make them successful.

Then you have to sit down with them and understand all of the constraints that are in the system and all of the things that are going to make change difficult. And not only do you have to understand what’s going to make change difficult, but you have to have a credible strategy for overcoming those things, because if somebody’s sitting there, one of the classic examples, and this is maybe an example from seven or eight years ago, as I was talking to a mainframe architect, and he was just totally blasting what we were trying to do with team-level Agile.

The reason why was because it was like, okay, small teams inspecting, adapting, continuously deploy, right? He understood Agile, and he was open to the idea of it, but he was looking at this technology architecture and basically saying that’s not going to work. He was right. That’s not an attitude problem, that’s not a culture problem, it’s not a mindset problem, it’s not a behavior problem. That is a constraint of the system problem.

So just like you wouldn’t walk into a legacy mainframe platform that needs to have product extraction work done, legacy refactoring, legacy recovery kinds of things and just go, oh, okay, we’re screwed. For some people, I don’t know, just be fine. You have to be very thoughtful about those kinds of things. So, a lot of what we’re doing in Agile Transformation is very similar. We’re fundamentally refactoring organizations to be able to operate more effectively.

After you enlist people on the patterns and principles, then you sit down with them and understand the design constraints that are in the system, and you evaluate where you are now, what’s the state of your organization, where do you want it to be?

You start to think through like, what’s possible today versus what’s possible in the future as we make changes. And then you do what you can today to be successful, and then you systematically start improving the system. You start to deprecate some of the compensating controls, and all of that stuff can be planned. Right. And, and, and so like what we’ve done is you hear us talk about expeditions to Basecamps.

You know, we have this four quadrants model, we have Base Camp One, Two, Three, Four or Five where we define kind of the next intermediate state. And then we have outcomes that enable us to be able to get from one base camp to another through 8, 10, 12 intermediate steps. And you can think through the different activities and you can say all day long that that’s big upfront planning.

But, but like the alternative is sitting there and just, you know, kind of air quote, empowering a group of people to make these kinds of decisions. And most people can’t conceptualize how to make radical organizational change. Gosh, another blog post from back in the day, I had my son, who’s 26 now. He was, you know, the kid at the time, 13, 14. And he had this goldfish sitting in his room. And I didn’t think anything of the goldfish, but it’s just sitting in a small goldfish bowl.

And, and I walked in one day and I’m like, the goldfish bowl hadn’t been cleaned. It had to be a year or something. It’s like basically the water is yellow. And I was just sitting there thinking, this little goldfish is kind of swimming around. That sound felt like, And if you’re that goldfish, like, how do you how do you clean that tank? Right? How do you extract yourself from the system so that you can empty the water, clean the sides, do all the different things that needed to be done, fill it back up with water, put yourself back in it.

Really, really difficult. And I think that’s the problem. Sometimes inside companies, it’s like we see all the constraints that are around us and we don’t know. We don’t know what to do about them. We don’t know how to influence or orchestrate that kind of organizational change. And so and so that that manifests itself as a lot of local optimization.

We have a lot of, you know, teams doing the best they can and, you know, folks trying to manage dependencies and, you know, and then they end up bending the rules of Scrum or bending the rules of SAFe to accommodate their organizational dysfunction. Because again, just most people are not systems thinkers and they have a really hard time changing the systems that they have to operate in.

Right? There’s politics and negotiation and people have different points of view and there’s no authority and all that kind of stuff. And so for us, the secret, the change, the secret to organizational Transformation has been is getting really, really clear on what your intermediate states look like, the outcomes you have to achieve to get there, the specific activities, the underlying design principles of the organization, what are the things that you can do now and the presence of suboptimal conditions to help get yourself into the place where you want to be sometime in the future?

And, and so yeah, so that’s kind of just, just what I’ve been noodling on.

Why Transformations Struggle

And what I think is fascinating is a lot of what we’ve been doing in the Agile Transformation space is actually translating and very complementary to some of the stuff that’s going on in the DevOps world right now. And so we’ve started a few engagements with clients to help go through DevOps Transformation.

I was just with a client yesterday and we were talking about Digital Transformation. And what’s fascinating is that all of these things are really related. They’re just different views on the same fundamental problem. You know, we’re trying to figure out how to organize around value. We’re trying to figure out how to create continuous flow. We’re trying to figure out how to leverage systems and technology to solve business problems.

And so, this idea of Digital Transformation, DevOps Transformation, Agile Transformation, it’s all starting to kind of blend together. And the reason why this stuff is struggling often is because we don’t appreciate the complexity and the amount of intentionality that is required to actually execute the kinds of change. Again, you have to enlist people. You have to help them understand the practices and the principles and the things that are going to help them be successful.

And then you have to spend time and you have to think through what is my desired end state, like, How is this system going to perform on the backside? Like, what is our hypothesis on how this organizational design is going to support the performance characteristics that we’re looking for? And then once you’ve done that, then you say, okay, well, let’s pilot, let’s try it, let’s test our hypotheses, let’s see if it will work.

And then as we get in and we actually do it and we learn and we apply these things in the organization and we create feedback loops and, you know, we inspect and adapt our way through. Right? All the things that we kind of talk about in Agile, we can do with transformation. But if we don’t do it thoughtfully, if we don’t do it with full respect for the systems and constraints that are in place, what we end up with is a lot of going through the motions of whether it be Agile Transformation or Digital Transformation or DevOps Transformation.

And we’re going through the motions of doing it without actually getting the results and because we all want to be successful, at the end of the day, we claim victory. We claim victory on our installation of SAFe, right? Because people are doing the SAFe things and have the SAFe roles, right? The whole reason we’re trying to do SAFe is because we’re trying to unlock value.

We’re trying to get things to market faster. We’re trying to be able to make and meet commitments on regular intervals. We’re trying to get fast feedback from clients. We’re trying to maximize our ROI. Right? And so if your SAFe isn’t doing that or your Scrum isn’t doing that, it’s not working. It doesn’t matter how well you’re actually doing.

The methodology can. And so again, intentionality around change in list design the system run pilot, get feedback, understand how it’s working. Are you getting not only the performance improvements you want, but are these performance improvements resulting in the business results you want? Are they driving your OKRs? Are they improving the business outcomes? Because at the end of the day, that’s the only thing that matters and I just think, just to kind of put a bow on this, is that the thing that we have to recognize is that any kind of transformation work isn’t soft culture first mindset.

Let’s get everybody into the same headspace and then somehow it will all magically happen. I’m just a huge believer that a reasonable amount of upfront system design, a reasonable hypothesis on how those things are going to be orchestrated with the different practices, and then once we have a significant change in the operating model and we can actually see it working, that’s when hearts and minds start to change.

So we’re going to see a lot of why DevOps fails, why Digital Transformation fails, why Agile fails, because a lot of the stuff is struggling and it’s not because they’re not good ideas, it’s just that it’s really difficult to see how to make the organizational changes happen. And so what we end up doing is we end up buying training, we end up buying tools, we end up buying things that make it look like we’re making progress, but without actually making the progress that we’ve promised.

So maybe just the last thing I’ll say is that we have to be able to suspend disbelief. We have to be able to believe that real systematic change is possible. And at the point that you’re willing to believe it’s possible, well, then you only have the opportunity to have a conversation about how might we actually make it possible.

Not saying it’s easy, I’m not saying it’s straightforward. I’m not saying that you won’t get resistance. I’m not saying that there won’t be skeptics, but you just create more skeptics when you don’t speak the truth and you don’t talk about the things that have to be true in order to make this work. And some thoughtful preparation and a thoughtful plan for how we’re going to get from point A to B to point C to point D goes a long way in being able to help manage these kinds of changes.

So, I hope you guys have a great week and I will see you next time. We’re going to see a lot of why DevOps fails, why Digital Transformation fails, why Agile fails, because a lot of this stuff is struggling and it’s not because they’re not good ideas, it’s just that it’s really difficult to see how to make the organizational changes happen.

The thing that we have to recognize is that any kind of transformation work isn’t a soft culture-first mindset. Let’s get everybody into the same headspace and then somehow it will all magically happen. We have to be able to suspend disbelief. We have to be able to believe that real systematic change is possible. And at the point that you’re willing to believe that it’s possible, well, then you only have the opportunity to have a conversation about how might we actually make it possible.

Not saying it’s easy, I’m not saying it’s straightforward. I’m not saying that you won’t get resistance. I’m not saying that there won’t be skeptics, but you just create more skeptics when you don’t speak the truth and you don’t talk about the things that have to be true in order to make this work.

Empowering your teams isn’t about allowing them to make decisions in a vacuum and giving them free rein to do whatever they want. The days of providing a little guidance here, some methodology there, and letting the teams self-organize their way to success are behind us. As the world of business increases in complexity, it will take more than user stories, estimation, and OKRs to build a trustworthy system that management can delegate into.

But if managers want a trustworthy system, it’ll be up to them to create it. You see, the real work of a manager is to understand that each team is different, then find ways to continuously elevate the teams to meet their collective needs, all while creating the conditions for the teams to thrive. Join Dennis Stevens for this talk, where you’ll learn the secret to creating a high-trust environment where teams have what they need to live boldly, work fearlessly, and deliver the highest quality work for your customers while releasing maximum value into your business.

Video Transcript 

I think if you’re not getting what you want from your teams as a manager, you have failed to lead appropriately. You haven’t created the conditions to be able to delegate to that team.

(Muscial Interlude)

The Challenges of Empowring Agile Teams

I’m Dennis Stevens, Chief Methodologist at a company called LeadingAgile. The genesis for this talk is around the fact that we go into a lot of organizations, and we often hear that management won’t let us form these teams or that they don’t know how to empower teams. When you look at the literature that’s out there, I was reading an article recently about empowering teams, and the very first line in the step of the five steps for how to empower your teams was “manage your teams in an empowered way.” Like, what the heck does that even mean?

What does it mean to empower teams? I think there’s an interesting challenge in our industry, too, that the Agile community has been fighting for a long time to be allowed to be empowered. But we don’t understand what must be in place to empower teams. Why would I trust a team that can’t do what they say they’re going to do, right?

Why would I put my credibility and my job on the line as a leader in an organization and just give the team everything they need? “Just trust me, get stuff done.” There’s some sort of a bargain, some conditions we have to strike to make this a healthy relationship that makes sense. So, I think we don’t pay attention to that all the time.

What I’ve been doing is talking about this with clients and going to different places, sharing with people some of how I’ve been getting them to see both sides of the coin of what it takes to empower teams. I hope you walk out of here with a set of questions that you can shape for your own purposes, where you see it not working, to walk in and ask, “Why is this not working?” Because it’s probably not that the manager is deliberately trying to make everyone in the organization fail or trying to undermine the health of everybody. That’s not what’s happening, right? And the teams, they want to be given the rights to make decisions and do work the way they want to do it.

But what would have to be true for that relationship to work well, is that a good topic? And so that’s what it said on the piece of paper, so I assume you’d like the topic. The slides are going to be available if you go to three, three, seven, seven, seven and just text managers, you’ll get the slides.

I want to talk about. Here is the conversations that we have to navigate through with management to get them to empower our teams. How many people are in here who are managers and want to understand how to empower their teams? How many people are consultants or team members that feel like managers don’t know how to empower their teams? Yeah. So why is it important to empower teams?

Like why do we need to actually give teams empowerment? Why do we need to move decisions closer to the work surface? So that’s the topic. But I think I think it’s important we all know what just kind of Scrum, Agile, the whole world knows that if we have to escalate every decision, it just takes forever. And then the people making the decisions don’t have the nuanced craft.

Understanding the few in place to make the decisions they need to make. Right? So we want decisions to be made within empowered teams if we possibly can, so we can move at the speed that we need to. Everybody agree with that? Why is it hard to to empower teams? Like why is it necessary? What does it mean? Why is it hard?

We can talk about why it’s hard. And let me give you three strategies. Actually, for strategies to build systems to ensure the right attributes are in place to empower your teams as a as a group. I just a couple questions. Why is it hard for managers to empower teams they want control? Why do they want control? Fear, fear.

What are they afraid of losing? Oh, you think it’s a win? What do you think it’s all about winning failure so big, right? You think it’s about winning? Okay. Why do they want to win? Ego. Fascinating. That’s an interesting path. I would suggest that that is not the healthiest path to take that conversation. Now, I would suggest that if we start out believing that the managers and organizations have bad aspirations to win at all costs, at everybody else’s expense, this is a really hard conversation to have.

Right. And so if you’re if you’re if you’re showing up that way and that’s the conversation you’re having, you’re not going to get the collaboration with the management that you need to be. How many the managers in the room feel like that you’re here just to win at all costs, exploit everybody, just bring people on the ground. Just raise your hands up on that one.

How about if I started the conversation with that? You know, the way you’re leading just to soothe your ego and win at all costs just to burn the place down? Let’s talk about that, because I need you to change your ego. What do you think? It’s not going to go well, is it, Managers? Why are you afraid to empower your teams?

What are the challenges with empowering teams? Why does it not happen? Trust. Trust. Fascinating trust. So I need to be able to give the team things to do and have them deliver in a way that is still safe for everybody. Because I’m kind of responsible for the people looking at me for making sure that dollars are spent well, that outcomes get achieved.

It’s a reasonable place to be, right? So you’re not just trying to win at all costs? No. Okay. But it’s interesting because it feels that way when we can’t have healthy conversations. Right. And I think that the agile industry, to a certain extent has promoted that just empower the teams and get out of the way. I think the servant leadership coaching world has talked about just be there for your teams and support them.

And I’m a huge advocate of agile teams and empowering teams. I’m a huge advocate of servant leadership and taking care of your teams.

What Does It Mean to Empower Agile Teams?

Let’s talk about like, why is that really hard to get to and some of the things that industry has tried to do to solve for this and maybe why they don’t work. But team empowerment happens when a group of employees has the responsibility and authority to make decisions every good with that, right?

So if we look at things like Agile and Waterfall, these are methods of operating in organizations that are kind of well known. And I mean, waterfall is a little bit of a of a straw man, but just bear with me on that. But basically agile small teams working together are close to the surface. Making decisions in real time Agile is really good for solving problems that have a high level of ambiguity.

But it’s not great when there’s a lot of dependencies because okay with that, okay, so we put Agile in place. There’s a lot of ambiguity and what gets away from us is the dependencies. How many of you all work in organizations have? No dependencies like end to end can just ship stuff to your customer after talking to a customer.

Okay, so there’s some challenges with with. We have to do something to figure that out. What waterfall attempts to do? Waterfall is really good at managing dependencies interdependencies, but in order for that to work, we have to know everything about it upfront. How many of you all work in industries or solving problems where you can know everything about the work upfront and have no variation how to do it or what problem your solving?

So this is the problem, right? It’s kind of a cool, let’s really clear our problem. So. So how can I trust a team is at the point that a team does something they decided what they’re going to do and how they’re going to do it. It make sense at the point in time that a team operates, there’s not a lot of ambiguity or not a lot of interdependencies are actually managing in the moment of action.

Right? So this is why agile teams work and it’s also why we actually want Agile teams in Big Waterfall, big complex projects because we need those teams to operate close servers. We can make our bottom box bigger with some technologies and some expertise, some experience. I might be smaller in some cases for outsourcing things. You know, there’s like different that box can kind of shape, but as this picture makes sense, all so the goal is how do we create the conditions for teams to make decisions and be able to perform work in a trustworthy manner?

Good call right here to read the deck. Right. So the goal is, is as managers, how do we make that happen? And it’s a collaborative thing. It’s not a one way street. You’re with me. So the problem is the problems we’re solving are up in that big green box. And the avenue for solving this problem is in between.

I ambiguity, high interdependency problems and the point of execution. And what I’m going to talk about a little bit is that we need to figure out how to solve that and come up with an intentional plan. Do we solve it by putting in specific practices in place like scrum of scrums or dependency boards or like that’s a set of practices.

Okay. With that, do we solve it with a culture? Just trust the team, stand back, let people figure it out. They’ll self-organize, they’ll figure it all out. Right now, practices are critical and culture is core to being able to operate in new methods, right? We have to change the way that we think about things, but our belief is in order to change that, we actually have to get the systems in place.

And a system is a group of interacting and interrelated elements that act according to a set of rules to form a unified whole. So those scrum teams don’t operate as a as an independent agent when there’s dependencies, right? The people asking for stuff don’t operate as a as an independent group when they’re operating in the complex organizations that we’re in.

So we have to think about it like systemically, we have to get the teams that do some things different, get management, do something different is probably a more complex layering of concepts we can get into. But in 45 minutes, I’m going to go through just some basic core things about what are the attributes of how we solve that problem.

We’ve got to be able to clarify the intent and cast vision so the team knows what it’s operating with. Then we can’t expect the team to invent its own clarity. That’s a failure mode. It’s in a lot of organizations we don’t sufficiently address, where are my  gaps in clarity. We have to clarify the path forward, aligning the competence and capacity of the teams doing work with what we need.

So sometimes we ask teams to do things that they have to figure out, or we give them ten times too many things to do and then expect them to be trustworthy. Right? Doing it, you’ll have teams that are working on ten times more things and they’ve capacity to do that happen a lot? So if we’re doing that as leaders, if we’re putting that burden on the organization, how can we expect that team to be trustworthy in its production?

Like we’re creating the conditions that the team can’t be trustworthy, right? So one of the things that Scrum tries to do is solve that is they give us a capacity, they give us a velocity. We say they control the velocity with the backlog, right? So, that’s a way that we try to create bounce capacity and then we have a sprint planning where we balance out the competence.

This is going to be hard, this is going to be easy. And we have them commit to things they understand, right? So Scrum kind of tries to address that a little bit. And teams have a cadence where they’re operating with intent but within constraints. So those are the sort of the attributes that that’s those are the attributes of solving from that problem up there.

And if you’ll notice, I put another team up in the upper box. I think this concept of stacking of teams and getting real clear about what it means because I think that team up there probably has a team that it’s responsible for. That team also needs clarity for its intent. Maybe the organizational strategy, right? Maybe what they’re allowed to spend and operate from, maybe the decisions that they’re allowed to make, maybe about safety performance.

There’s like there’s a set of dynamic conversations that take place amongst multiple layers of teams. Good with me so far.

The Attributes of Empowered Agile Teams

So these are the pillars of empowered teams, clarity on value and decision right? So if I don’t know what to do or what is that a problem that involves teams you think teams are operating? I don’t have clarity.

Is that a reason why you don’t get what you want out of the teams? Right? They don’t know what to do. And do you ever have the problem where we don’t know who makes a decision? If a lot of people can say no, but nobody can say yes, right? So it becomes really expensive competence. Do we ever have teams do things like this?

Is this to me is like a Scrum master failure mode in a lot of places. The Scrum Master is going to remove the impediments, but the impediments to the thing, to the team are things in in the Devsecops group or in my enterprise operating center or in my architecture group or in my somewhere, my customer or my market, like the Scrum Master can’t go change those policies and impacts on the organization, right?

So we’re asking teams do things that have the competence to do and is an a moral thing. Like I’m not going to ever be your accountant. You don’t want me balancing your checkbook. I have demonstrated that many times, right? So balancing my checkbook now and I love her and I trust her so and then capacity balanced with with demand and then a cadence of measurement and feedback seems like the pillars.

And really we’re going to walk through each of these questions. If I were walking in as a manager and I was trying to assess with a team, what do we have to do to put these things in place? This is the avenue that I have the conversation, worthwhile conversation for all.

Empowerment Strategy 1: Stable Teams & Clear Boundaries

Okay, This is also the first time I’ve done this trimmed down version of it, so I’m trying to figure out it’s going to take enough time or think I’m going to fit in fine. But I think we’re in good shape.

So empowerment strategy number one, establish a team structure with stable teams and clear boundaries. We talk a lot about chartering teams, getting decision right, How many people have really, really well, charter teams that understand their roles, responsibilities. So I want I need to hold this team accountable. I need to go and I tell them, here’s how you’re going to operate or work together, collaborate, How are you going to operate so we can agree on it?

Well, that’s not acceptable to me, but that’s unacceptable to me. Well, what is an acceptable thing to go? We don’t charter teams and get this clear because sometimes it’s hard work and we don’t want to end up in a disagreement as we just let it go unresolved. Right? We don’t have clarity on our roles and responsibilities. The decision, writes One to me is a really big one where a team wants to make certain decisions.

I’m going to decide what’s the most valuable thing to build in your job. We actually have a whole product group and a customer that we’re doing that up here. Why are we getting that decision clearly communicated to the team? So that breakdown is not between the backlog and the team that can do working in that backlog. It’s in deciding which decisions get made up and down the stack.

So one of things I talk a lot about is different types of teams. Here we have delivery teams, product teams, portfolio teams, investment teams that might be too complicated. You might need to you might just need flat teams. But most delivery teams can’t orchestrate their own dependencies. There’s too many dependent. You can’t self-organize around them because they take more than a week or two to get in place.

So I’m going to have a team structure that’s responsible for orchestrating dependencies, identifying risks and removing risks around the teams for the areas the teams can’t go after. Is that does that make sense? And that team’s going to have a charter and that teams can have a charter that talks about what their roles and responsibilities are. And it’s going to be very, very clear what decisions they get to make and it’s going to be shared between the delivery teams, the product teams, which decisions each team gets to make.

Now, is it going to be the same in every slice of the organization? Now, there are some decisions that we’re going to push down to the work surface because the conditions exist and it’s appropriate. There are some decisions around how we’re going to do something were to decompose and break down the work and do things in the small that the delivery team is going to do.

They’re going to self-organize around the constraints and the boundaries that were established and then negotiated agreements on the system. So when something is going wrong in an organization, ocean and teams are and the first thing I’m walking into going is what was the decision that got made in the wrong time? How did they build something that you didn’t want?

Like, how did that happen? That they built something you didn’t want? Who was responsible for sorting all that out? Because the problem is it’s the vagueness of the system. It’s a lack of intentionality around the team design and who makes which decisions. This isn’t super complicated. You dry up the teams, you have a group, you get together and you talk about what are the decisions that each team gets to make and you get agreement on it.

This will be hard too, because you have people that don’t want to give up some decision rights. We’ve been dealing with this actually here in town recently with a guy who’s been running an IT group for 15 years with an out of control sort of stack of stuff above him. And so he doesn’t trust giving any decision rights up.

He wants to control what they’re delivering to customers and he wants to control how they’re going orchestrate stuff. The problem is, is that that portfolio or product team here where they’re actually talking to customers, nobody has any idea what the status of anything is, what they think is going to get done. So he’s not only making decisions, but he’s not radiating any of the information that problem.

Guys familiar with that problem, that classic problem. All right. So how do we get past that? Sit your teams down, get extremely clear on what value means to that project or that team. What we’re going to reward, what we’re not. Get really, really clear on the rules, responsibilities that exist on the different teams and make it explicit which decisions get made at which tier.

If you don’t make it explicit, then things are getting dropped. Then you have to get better at making decisions. What does it mean to make decisions and communicate it? There’s this whole sort of theory around commitment-based management. Have you guys have you seen any of that where I’m going to ask for something? You’re going to make a promise, You’re going to do it.

You’re going to go tell it. You can tell me what it’s done. Like the process of managing the interaction between those teams becomes really important, too. So if you’re responsible for doing something that you trust, for doing it, your response for telling other people has been done and making negotiating explicitly the criteria. So it’s cool that that from a value standpoint, acceptance criteria.

OKRs There’s a whole bunch of things that are built into our agile world that we can use for creating clarity on value. We can get clear on who negotiates the different aspects and what are the tradeoffs is who gets to make the tradeoffs, and then we can get the work down into the teams. The team can operate there.

We do a lot of work. Okay, as an organization, we’ve seen a lot of it going on and they’re not used to actually great clarity. They’re not leveraged when we’re actually making decisions in a good place. That’s cool. We’ve seen a lot of places where it’s disconnected from actually doing the day-to-day work. We’re doing okay, but we don’t.

Clearly, we see a lot of people that write acceptance criteria. Acceptance criteria are functional tests, not the problem we’re solving. We don’t we don’t communicate value and intent and our acceptance criteria. So, when you say, well, okay, here’s acceptance criteria stories, well, form teams, these things are all great. People go, we’re doing all that. But you look at it and you go, but you have really clearly articulated goals and business outcomes, communicate his aims.

Could they articulate why they’re doing what they’re doing and how they can associate that piece of work with that? If not, then you have an accomplish the intent of your OKRs or however you communicate it. Are there clear roles and responsibilities for all members? Yeah, but we don’t really do them because the teams are different and every team might be different, but if we don’t know who’s making which decision win and whose response for doing work and making it explicit, it’s going to kind of fall apart.

There’s a set of dynamic conversations that take place among multiple layers of teams. These are the pillars of empowered teams – clarity on value and decision-making, right? If there’s a problem that involves teams, and they don’t know what to do, or who makes a decision, it can hinder their ability to deliver what is expected.

To empower teams, we need to establish a team structure with stable teams and clear boundaries. This includes chartering teams and getting clear on roles and responsibilities. We also need to make explicit which decisions get made at which tier, and ensure that it is shared between delivery teams, product teams, and portfolio teams.

As a manager, we need to facilitate clear understanding around roles, decision-making, and how to do value. This is a leadership responsibility. We need to charter teams, explicitly agree on working, and use acceptance criteria to articulate value in a way that both groups agree to and can hold on to. However, depending on the domain knowledge of the team, the complexity of the problem, the rate of movement, and the number of dependencies, we might want to charter them differently.

To empower teams, we need to create the conditions to delegate into the team and ensure that they have everything necessary to be successful. We also need to get clarity on how all those things happen. Lack of trust between the groups can make this hard, so we need to solve the problem together, revisit the design of our teaming structure, and hold the team accountable to the decisions they made.

Leadership is responsible for the design of the system, and we need to empower teams by building trust, setting an example of empowering teams, and solving problems to achieve shared goals. Monthly retrospectives at an organizational view or team level retrospectives can help in this regard. This is a simple yet courageous and tenacious process that requires intent and hard work.

But one of the things that makes it hard is this lack of trust between the groups. So, you have to sit down and say, “Listen, we have to solve this problem together and we’re going to get as good as we can.” Now, do you all do like monthly retrospectives at an organizational view or just do team level retrospectives? Some organizations do operations reviews or bigger retrospectives.

Yeah, so every once in a while, you should be revisiting the design of your teaming structure in decision rate and moving things around when something goes really, really south. Sit down and do it. You want to talk about empowering your teams. You want to start as a manager, set an example of empowering your teams, how to about how to solve this class of problems to achieve the goals that we share.

Now, the team actually influences the world. They’re participating in how they want it to be shaped, and if you listen and help them put it in place and hold them accountable to the decisions they made, that’s empowering teams. It’s building trust. This is interesting because I believe leadership is responsible for the design of the system, and we tend to just let this stuff not be done or we don’t do it itnentionally enough.

And then we get messiness and then we’re frustrated and positional power. It’s the frustration on the delivery team. I think if you’re not getting what you want from your teams as a manager, you have failed to lead appropriately. You haven’t created the conditions to be able to delegate into that team.

Empowerment Strategy 2: Explicit Decisioning, Orchestration, & Interaction Models

Competence. The right people in the room at the right time making the right decisions.

We see a lot of big heavy SDLCs or process flows or diagrams about how to build software, how we ship product, how we work. A lot of those things. Very, very little of it is really, really followed closely and without much transparency in the work that’s actually going on in there. One of the cool things about the way that we can do with Agile is we’re pretty familiar with just like this delivery team Kanban, right?

Here’s what I’m doing the next two weeks, broken down the stories. We have clarity on it because we did that conversation. We’re going to track it apart across through in progress, story done. You know, whatever your flow is at that level, we’re tracking those little pieces of work across and we have a lot of transparent see into the state of the work with a lot of transparency where things are getting blocked.

When we have a lot and when things are getting blocked, what does that mean? It means that we delegated something to a team that the competence didn’t exist within the team to resolve. It is competence, morale. Why should we mad at them? Because we gave them something they’re not competent to do. Should the teams that are interacting with each other get frustrated when we expect someone to do something they’re not able to do? That’s a design of the system problem isn’t it? So what I want to do is make these flows be really explicit. We’ll do stories at the bottom, features in the middle, epics at the top, maybe opportunities or investments, whatever you need one or two or three stacked beginning, extremely explicit that at this point when we’re in solution definition at the epic and feature level, here’s the people that are in the room. Here’s the information they’re going to have and here’s how we’re going to make decisions that we can all hold ourselves accountable to. Right?

Within the design of the system. That’s going to be reflected now in my acceptance criteria. It’s going to bounce off my OKRs and it’s going to be the way I decompose my work because I have a stable team and I have responsibilities for decisions. I’ve agreed on how we’re going to operate. Now I can intentionally manage the flow of work. And when things aren’t working, I can test for that I have a poor team design, can I understand as you make quick decision or I push work into a team they’re not competent for. What do we do if we’re trying to push work into a team they’re not competent to do. What can we do?

We can make it clearer, we can make it smaller, more precise. We can find another team that can do it, or we can invest in elevating the competence of the team. But if I give a team something to do as a Product Manager, Product Owner, or an executive or whatever, and they’re not capable of doing it, is that the team’s fault?

So what is the team responsible for when we’re having that conversation? Communicating what they can do, right? Yep. Being transparent. Here’s what I can do. Here’s what I can’t do. If you could work with me to get these things in place, I could do this for you. But I can’t handle that.

But a lot of times it’s because of the nature of the organization. We put stuff into the teams. We expect the teams to go do it, and they feel obligated to do it because of the positional power itself. So it’s really interesting. It’s the positional power thing that gets sideways, right? And it’s because it becomes individual instead of understanding how the whole system works.

So I get really explicit on how work flows, and I can tie what decisions get made, where, and who has to be in the room to make those decisions. And remember, I tie decisions to the different teams. We built it out earlier. I make sure people have the right information to make the right decisions. It becomes very interesting when in many organizations we walk out to the endpoint and we find a lot of the work at the end, we integrate at the end, we test at the end, we come up with our security requirments at the end , and then we solve a lot of things at the end because we don’t have the right people in the room at the right time, creating a context for the teams to operate within. Or we delegated decisions about how we’re going to operate into teams that don’t have the right to make that decision, and then it conflicted with something we were trying to do from a higher level. So getting very explicit about the flow of value and the decisions and where they fit in, that becomes the critical next step.

Empowerment Strategy 3: Transparency & Radiating Key Info

And then there’s the capacity. One, every organization has more work to do than they can possibly get done in a period of time. That’s just generally true, right? Are we getting things done faster when we’re working on everything at the same time and are pushing everything into the teams? How do we have transparency that what do we do to understand how much capacity can handle? What’s the optimal amount of rate based on their team structure and the competence of the team?

How do you know when you’re pushing in more stuff that you can pull out? This again, where a  Kanban is a really nice sort of tool for understanding that. How do you know when the team is at maximum limit? Do you have an understanding of what the capacity of your teams are and how much you can push in?

Do you know what the dependencies are that are blocking them, and are you orchestrating and managing the dependencies ahead of the teams or expect them to figure it out in real time? So these are things we walk in and kind of look at things when really they go sideways. This is almost always like a big hit, right?

But until I have the stable teams and clear decision rights and can actually measure the flow of value, it’s really hard to solve for the capacity in demand conversation. It’s really hard to get to dependency management decisions in the right place because I can’t be finding every dependency late now and expecting the team to resolve it in real-time just doesn’t work.

So, I can design a system that has a lot of late failure, and it will never be predictable. It was never predictable. I’m not going to trust it, right? So, I’m not going to push decisions into a team that I can’t trust. The one about capacity constraints and dependencies are two very, very big ones. You all have good tools for understanding your capacity so that the business is making decisions and pushing things in that are balanced with your capacity.

Are you good at managing dependencies ahead of the team? Are you all good at really working out only the most important things? Why is it hard to empower your teams given this sort of frame? If you were to look at it for a minute, what makes it hard for you to empower your team as a leader?

What’s missing from this is what they all said: it was hard to empower your teams. What makes it hard to empower your teams? Does this frame help you with that conversation? Are there things here that you could go do? What would you go do?

Empowerment Strategy 4: Feedback Loops

Let me go to my last sort of big slide. So, the last one is just the cadence and the cadence of management, the teams getting together and reviewing how work is performing. If it’s hard to see the status quo going to work as performing or where the impediments are or how this thing is performing is very difficult to resolve. And if we’re just managing like every individual crisis, a crisis at a time, instead of understanding the design of our organization, it’s impossible to actually go improve. So, we end up we talk about being in the system versus on the system.

So organ in the system all the time, but having some time to deeply understand how our system works, how our teams are working together, where their challenges are, where their impediments are, what their capacity is, what their competence is, and making sure that we’ve optimized for producing value through that, that transparency is really important and we have to stop and go back and ask the questions.

Is the team designed right? Is the flow of decision-making right? Do I have the right information to make the right decisions or am I just hacking on people? And when we don’t have those things in place, then we end up just bullying on the teams, right? That’s the only way to get things done. And we have to get things done.

Tradeoffs just getting really, really clear in that moment. We want to do that fast, but we want to do it and it’s going to end up eroding the technology and making things worse in the future. Or I can’t do these four things. I can do these two things like having that cadence of using the data performance of the system in place and providing that feedback so you can adapt and respond in real time. That’s a critical strategy. Many organizations are still pushing things in at the top that are not strategically aligned, capacity constrained, or dependency aware and expect it all to get figured out in the middle. All these pieces are in the messy middle there, That Red X, that’s where we need to put these pieces in place.

Part of that is having transparency and an explicit place to make tradeoffs. If we don’t make the tradeoffs above the delivery teams, where those tradeoffs are going to get made? Say, I can only do four things for you, but you give me eight to do. If we don’t decide the four as part of a process, who’s going to decide which four get delivered to the team, some developer, or some vendor? That’s an example of decisions getting pushed down because we’re not taking accountability for it. If I didn’t get back what I wanted, I delegated the decision to a team that I should have delegated authority or competence to do it right. So there has to be an adjustment.

We need to understand what tradeoffs we have to make and how to make them. The last one is continuous improvement. How do we look at this system again and again and improve it? If you’re thinking, we already do all these things and you’re not getting your teams empowered, that’s kind of what I was going to say before. What’s making it hard if you’re already doing all these things to engage with your teams and make them feel empowered?

Are you trying to make your teams feel empowered? Do you know which decisions you want to delegate into the team and give them responsibility for? Do you know which impacts on your system you want them to have a voice in and be able to improve and elevate? They should feel like they’re actually influencing their life because it’s not just about organizing the chaos and crisis around the next piece of work. It’s about actually making a place that isn’t horrible to live in and work.

It’s about having the ability to participate in making it better and better for me to keep the promises that are being made between teams and between management and the team. So that’s the takeaway, empower teams, the four pillars, and sort of the introvert. I know I thought I might have cut this a little bit short. I didn’t go into too much detail on some of the areas. I’ll be really happy to take any questions or work with you all, take any specific and sort of walk through it, take any feedback on what I presented to.

If you were king for a day, and you could change the hearts and minds of the people inside your organization over night; what would you do next? And would you be able to guarantee those actions would lead to greater Business Agility?

A lot of people believe that Agile Transformation starts with culture because it feels like a culture problem. It feels like there’s resistance to change, and that command-and-control leaders won’t let the teams be Agile. More often than not though, it’s not that people don’t want to change. It’s not that leaders are anti-Agile. It’s that the system you’re trying to build that culture within isn’t designed to foster it.

Video Transcript

If you could do anything in the organization that you want to do, you could change anything overnight that you wanted to change. You could snap your fingers and all of the cultural impediments would be overcome in an instant. What would you do differently the next day?

Hey, everybody. Thanks for joining us today. We are doing a series right now around common misconceptions around Agile Transformation. If you’re not familiar with LeadingAgile and what we do, we are a boutique consultancy based in Atlanta, Georgia, that focuses exclusively on helping companies effectively adopt Agile, Agile practices, specifically in larger, more complex organizations, where there’s a lot of, you know, just challenges organizationally with doing this and doing this well.

So, what we’re talking about specifically is common misconceptions around Agile Transformation. And one of the one of the misconceptions that we see quite a bit is the idea that the difficulty adopting Agile is largely a culture problem. So, I’m fairly well documented in saying that Agile is not a culture problem. Agile is a systems problem. It comes down to how we form teams, how we build backlogs, how we produce working tested software.

A fast follow behind that is what are the practices that we use to enable that Agile System of Delivery. So, in the presence of really well-formed teams, we might want to do Scrum and XP on top of that. In the presence of well-encapsulated products or value streams, maybe we want to do something like SAFe or Large-Scale Scrum.

And so, what tends to happen is that when people go down this path of doing an Agile Transformation, it almost always starts from a practices perspective or from a culture perspective. So, if I think about a practices first perspective, I’m basically going under the assumption that if I teach you how to do Scrum, Scrum will show you your impediments. And then those impediments will get removed over time.

A culture-first Transformation basically says if we can just get hearts and minds changed, if we can just get the behavior of the organization to change, if we can just get the people in the organization open to doing Agile and being able to think differently about how we do software, then everything else will flow.

One of my favorite thought exercises to do, if I get out and speak at a conference or a user group, is…I kind of call it a “king for a day discussion” and basically say, if you could do anything in the organization that you want to do, you could change anything overnight that you wanted to change, you could snap your fingers and all of the cultural impediments would be overcome in an instant. What would you go do different early the next day?

Understanding that we need to have incremental and iterative development. We need to do team-based delivery with stable velocity. We want we want flow of value. We want early release, we want high quality, we want efficient delivery. We want to be able to respond to change, right? All the different things that we promise with Agile.

If you took the culture aspect of that out of it, what would you go do the next day? What would you ask of the organization? What changes would you make? And if you were able to make those changes, would you be able to guarantee success installing an Agile ecosystem as designed?

And so, what my belief is, is that most of that resistance organizationally, the thing that we see as an unwillingness to change or a mindset or a behavior of command and control, largely comes from having an unreliable System of Delivery, something that that is really difficult to trust.

And so, we have leaders that are behaving in a way that’s anti-Agile, but they have a long history of working with product development organizations and IT organizations that haven’t largely been trustworthy. So, my belief is we want if we want a cultural attribute like trust, we have to build a system that is trustworthy. If we want a and a culture that is responsive to change, we have to have a System of Delivery that is able to accommodate change in a reliable and predictable way.

So, the idea that the impediment to Transformation is culture, I think is a bit of a misconception. What we want is we want a reliable, Agile System of Delivery, one that’s formed around teams. Backlogs are clear, able to produce a working tested increment. Stabilized velocity the team level. A team-based organizational structure—enterprise-wide. A lightweight, Agile governance model that ties up to the portfolio management/investment tier strategy.

We want metrics and controls that actually enable the kinds of things that we’re looking for. We enable that system with really solid, Agile practices. And what we find is that when that system becomes trustworthy, you start to see those attitudes and beliefs and behavior from leadership and your team members start to change. So how you get there is a bit of a process, right?

There’s a there’s a way to design an Agile operating model. There’s a way to incrementally and iteratively deliver that operating model in a way that’s safe, plan-driven, that can actually be, you know, intentionally designed and deployed that will actually work to achieve the goals of Agile. And then within the context of that, we can ask the organization to change.

So, it feels like a culture problem because there’s so much resistance. But that resistance comes from the cognitive dissonance of not seeing how it’s going to work. So, if you can create a compelling case for how this Agile System of Delivery is going to work, and how your leaders are going to get more of what they want out of the system, then over time, then you can start changing hearts and minds.

So, it’s not changing hearts and minds and behavior first. It’s about putting in a reliable System of Delivery that can be trusted and then inviting participation into that system. Once the organization learns how to get what it needs out of that system.

So, thank you for joining us. Appreciate you being part of this conversation with us. And we look forward to our next session together. Have a great day, sir.

How do you get hearts and minds to change? How do you get past long-standing behaviors and reinforced patterns of thinking so you can begin to do things a new way? Possibly a better way?

Let’s say you wanted to move from a command-and-control management style toward a more empowering, human-centered leadership style. How would you go about asking those managers to change? Those leaders to change? To risk it all in hopes of finding a better way. In large part, our behaviors are driven by what each of us sees as necessary to get results within the bounds of our organization’s operating model. We play by the accepted rules for how everyone works. Leaders often behave in a command-and-control manner because the company’s operating model is chaotic, impossible to understand, and doesn’t produce results. So, they take control and drive results.

What if they became empowering servant leaders in the presence of a chaotic, impossible-to-understand operating model that doesn’t produce results? They would most likely fail. To get your people to change, your leaders to change, and your organizations to change, you must change the environment each of them operates in. You must change the rules of the game.

This talk will explore the organizational attributes and behaviors that truly support a culture of Agility. We’ll look at the systems necessary to reinforce and guide those behaviors. We will evaluate the things we see in many organizations that get in the way of people being their best selves. Finally, we’ll explore how to systematically introduce changes that make it possible for each of us to think, behave, and deliver in a truly Agile manner.

Agile Transformation isn’t about a big-bang rollout of Agile, and then Presto! You’re done. It’s about meeting the organization where it is today, and iteratively and incrementally rolling out Agile capabilities over time. As your ability to be Agile matures, today’s Transformation will look a lot different than your Transformation a year from now.

Another reason why you can never really be done with Agile Transformation is that the market is constantly shifting and your customers needs will change. That’s not to say that you need to have consultants on the ground forever, but it is to say that improving the organization, maintaining its ability to inspect and adapt and respond to change, will be an ongoing initiative that is never finished.

Video Transcript

Agile isn’t something that you just install, and you’re done with, but it becomes part of not only how you’re thinking about managing work, but how you’re thinking about adjusting the organization to satisfy the long-term needs of your customer.

(Musical Interlude)

Hey, everybody. Thanks for joining us. We are continuing our conversation around common misconceptions around Agile Transformation. So, we’ve covered things like is Agile transformation just as simple as learning practices? We’ve tackled the issue of is Agile culture change? Do I need to change the culture in order to be able to create an Agile operating model? We talked a little bit about one of the common misconceptions being that if I just get my teams working, it doesn’t matter what the rest of the organization does. We kind of tackled that from the perspective of it has to be an integrated operating model across the entire business to really achieve the business benefits of doing Agile at scale.

The last common misconception that we’re going to cover is the idea that Agile Transformation is a one-time event. Now, here’s the interesting thing about that. Can Agile Transformation be a program with a start and finish? Yeah, 100%. I mean, that’s kind of what LeadingAgile’s bread and butter is. You know, we come in and we take a look at the organizational design, we look at the business architecture, the product model hierarchies. We look at the technology architecture. And you can create an operating model that is team-based with lightweight, flow-based governance at the program and portfolio layer. You can tie that up into OKRs and KPIs.

That is a system that can be designed. And then you sit there, and you think about, okay, how do we incrementally and iteratively install that system into an organization? How do we go through and how do we form teams, how do we install the new governance, how do we put the new metrics and controls? Once the system is performant, how do we start to teach the business how to exploit that system to its economic advantage? Those are all things that you can do, and those things do indeed have a start and a finish.

What we generally find is that the things that you need to do in an early-stage Transformation, in the presence of dependencies and while you’re creating the conditions to really do Agile at scale, sometimes you need more governance, more control, more planning than you would like to end up with. So, what I would suggest, maybe the first thing to tackle in this misconception is that when you’re thinking about Transformation, you think about Transformation like a journey.

You can do certain things in an early-stage Transformation, but there’s compensating controls that you need to put in place because you haven’t fundamentally improved all of the underlying, really dependencies and staffing issues and all the different things that get in the way of being able to do Agile well. You haven’t actually improved those in an early-stage Transformation. But there’s a lot of Agile you can do. And then as you move and you start fixing how the organization is staffed, how it’s run, where the dependencies exist, how the dependencies are managed, how batch sizing is happening in the organization, you can start to improve the underlying operating model and start to deprecate some of the planning. And you can start to deprecate some of the dependency management. And you can start to operate more in a pure play way. Okay.

So, the idea that Transformation is a journey, and the Agile operating model is going to look different over time as the system improves. That’s one angle that we want to cover. The second angle that we want to cover is the idea that the organization itself also has to be able to respond to change over time. And so, the business capabilities and the product areas that we organize around, we have to be constantly mindful that those capabilities are reflective of the needs of our customers. So sometimes macro-level economic things change, sometimes the needs of our clients change. So not only do our backlogs and teams have to be responsive to change, but our organization and how we deploy our capabilities to satisfy customer demand. That also has to change sometimes as well.

So that’s where you get from the idea of doing a, you know, a one-time Agile implementation, you know, maybe via like an Agile Transformation Office to actually creating some long-term support. So not only can the backlogs inspect and adapt over time, but also the core organizational design and what we’re deploying our assets towards to where that can change over time.

Point being is that Agile isn’t something that you just install, and you’re done with, but it becomes part of not only how you’re thinking about managing work, but how you’re thinking about adjusting the organization to satisfy the long term needs of your customer. So anyway, thank you so much for being part of this conversation with us and we look forward to engaging with you in the future.

Have a great day. See ya’.

Agile practices don’t automatically lead to Business Agility. In the presence of dependencies and organizational impediments that the teams have no ability to change, going through the motions of Scrum or SAFe isn’t going to lead to greater Business Agility either. So, you can train the teams all you want, but if it doesn’t lead to greater Agility, who cares?

Listen as Mike Cottmeyer and Dave Prior discuss some common misconceptions about Agile Transformation, how training often leaves businesses wanting more, and some things to consider if you’re thinking about starting an Agile Journey of your own. Also, stick around for the end, where Mike reveals who his favorite fictional Project Manager is.

Want to Listen Instead?

Contacting Mike Cottmeyer

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

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

Contacting Dave Prior

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

LeadingAgile: https://www.leadingagile.com/guides/dave-prior/
LinkedIn: https://www.linkedin.com/in/mrsungo
Twitter: https://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/

True Business Agility requires a lot more than team-level Agile. It requires an integrated operating model across the entire organization, where all the different parts of the business are plugged into an Agile System of Delivery, and it operates as an integrated whole. Otherwise, you won’t ever unlock the full potential of team-level Agile or Agile at Scale.

Video Transcript

Yeah. If you’re a small project in a large organization? Sure. Do Agile. You’ll probably get a lot of business benefit from it. But that isn’t the same as Business Agility

(Musical Interlude)

Hey, everybody, thanks for joining us today. We are engaged in the middle of a conversation around the idea of common misconceptions around Agile Transformation. What we’re going to talk about today is the idea that team-level Agile is sufficient to basically being Agile at scale.

Now, where I think some of this comes from is that there are a lot of organizations out there that are really naturally oriented towards an Agile ecosystem. They might not be doing Agile, but they’re kind of anchored towards it, right? So, they have very well-defined products, they have product areas, they have the opportunity to organize teams around feature areas. There might not be a lot of dependencies between different parts of the team. You know, the teams can operate independently from each other. And so, there’s a lot of places where you can pick up Scrum. You can pick up Extreme Programming. Or maybe, you know, in a workgroup environment, pick up SAFe and get a lot of business benefit from doing those practices.

But there’s also a lot of organizations out there that are, you know, currently heavily Waterfall, very functionally siloed, and the technology platforms have lots of dependencies between them. And so, not only is it insufficient to do team-level Agile, but there’s also like a way we have to think about it in order to be able to tie that team-level Agile up into program and portfolio and investment tier objectives.

There’s a lot of thought and intentionality that has to go into how are we going to introduce this incrementally and iteratively into the organization over time. There’s like really interesting things about like how we’re going to deal with, you know, corporate compliance and financial governance and, you know, audit, product management, enterprise architecture, DevOps, right? There’s a lot of different stuff that goes into this.

And so, if you’re thinking about doing Agile in a really large organization just at the team level, well, that might work for like if you’re a small team within a larger department and you’re trying to use Agile to get a project done. Again, not saying that that isn’t possible, that you couldn’t use just simple small team Agile in a large organization to get some sort of initiative done.

But the context of the question is what does it take to achieve Business Agility? What does it take to achieve Enterprise Agility? And when that’s the question we’re asking, how do we get the entire company to not only respond to changing markets, but also to get like the very fabric of the company responsive to changing markets? And like everything else we’ve been talking about, so much of it comes down to organizational design.

It comes down to organizing teams around business capabilities, product areas, feature sets, reducing the amount of coupling dependencies between different parts of the organization. And then you can start to think about once you have encapsulated delivery teams, how do those delivery teams roll up into more complicated like value stream type deliverables? How do those value stream or product deliverables tie up into the portfolio?

How does the portfolio operate in smaller batches? How do we start changing all of the different aspects of the company in order to be able to really exploit this this team level delivery capability that we have?

So, where I might end this little bit of discussion is that, yeah, if you’re a small project in a large organization? Sure. Do Agile. You’ll probably get a lot of business benefit from it. But that isn’t the same as Business Agility.

If you’re in a larger organization. What we have to recognize is that not only do you need really solid team-level Agility, but you also need Agility in terms of how you think about doing work decomposition, how you make investment decisions, how you govern and control everything else around those? And it all comes down to how do we, in effect, fund and support independent teams that are working autonomously at the local level, but also rolling up into larger program and portfolio level of objectives.

And so, while you might be able to Transform a team using training or going to Scrum, when you’re really talking about doing Agile at scale, it requires a whole lot more than team-level practices. It requires really an integrated, Agile operating model across the entire organization where all of the different business functions are plugged in to that Agile System of Delivery, and it operates as an integrated whole.

What we found is that that is the only way to truly get not only the benefits of team-level Agile, but also the benefits of Agile at scale and how to achieve true Enterprise and Business Agility. You have to look at the system holistically.

The cool thing is, is that the principles that we’re applying at the team level are the same principles we’re going to apply at scale. It just requires a bit of refactoring of the organization and some thoughtfulness about how you’re going to get there. So those are the kinds of things that LeadingAgile does, the problems we try to solve. So, if you’re interested in having that conversation with us, we appreciate you’re here, and we’re looking forward to continuing that conversation.

Have a great day.

Many people believe that the practices associated with Scrum and SAFe will reveal what’s getting in the way. They assume that, over time, the ScrumMaster and the team will have the ability to resolve those impediments. But what happens when the teams run up against a tightly coupled mainframe system, or cross-cutting concerns amongst multiple teams, and dependencies in the technology stack? Agile begins to break down because these impediments are outside the teams’ span of control. So, you’re going to need more than Scrum and SAFe. You’re going to need a plan to deal with the things that are getting in the way of Business Agility. 

Video Transcript

If you’re thinking about going through and doing an Agile Transformation, training is important and we believe in training and people need to have skills transfer. But if we don’t get the underlying buying attributes of the organization, if we don’t get the underlying System of Delivery right, then what we’re going to end up with a lot of people doing Agile practices and like the phone calls we get, not getting the business benefit from it.

(Music Interlude)

Hey, everybody. Thanks for joining us today. Over the next few sessions, we’re going to explore the topic of Agile Transformation and some of the common misconceptions we see around Agile Transformation. The first thing you should know if you’re not familiar with LeadingAgile and what we do, is that we are a boutique consultancy based in Atlanta, Georgia, that focuses exclusively on helping companies adopt Agile more effectively.

One of the biggest things that we see and that we believe, and we think is a huge barrier to adopting Agile. What makes Agile unique in a way is that Agile is largely dependent upon how you structure your teams, how you do governance, how you do metrics, how you do planning. One of the things we talk about internally quite a lot is the idea of encapsulation and orchestration.

So Agile, in its an ideal state, requires a really high degree of encapsulation at the team level, at the work group level, at the organization level. In short, what that basically means is that any time we have dependencies between one part of the organization and another part of the organization, or between one team and another team, that’s going to reduce our ability to be Agile.

If you think about it, it makes a ton of sense because if I am connected to somebody, right, we have a deliverable that requires us both to work on it in order to create something of customer value, then we have to coordinate. At scale, sometimes that level of coordination can get totally out of control.

And so, the common misconception that we see is that Agile is a set of practices. It’s something that you can go to CSM training, or go learn about the Scaled Agile Framework, and then just go start doing. What seems to be underneath this misconception is that if we just start doing the practices associated with Agile, if we just start doing the things that are in Scrum and the things that are in SAFe, that we will identify our impediments and that over time the ScrumMaster, or the team will work to reduce those impediments.

Basically, what we’re seeing is that when we go into large-scale organizations where there’s like, you know, tightly coupled mainframe systems, dependencies between different teams across the organization, really complex requirements and, you know, integrations and such that are happening at scale. What tends to happen is that when you start applying the practices of Agile, that these dependencies, these impediments, get in the way and they’re largely unresolvable at a team level.

And so, what happens in practice is that people are going through the motions of doing Scrum, but they’re not actually getting the business benefit from it.

When somebody calls up LeadingAgile and says, Hey, you know, we’re interested in doing some Agile Transformation work with you, a lot of times what they’ll say is that we’re doing Agile, right. And that we’re actually good at it, but we’re actually not getting the results. Almost always that comes down to how you form teams, what you’re forming teams around, how you’re generating backlogs, how those backlogs are tied to and nested up underneath corporate strategy.

Can we get to a place where we do a working tested increment of software at the end of every sprint? Because what we found is that if we can create teams like that that operate with that level of independence, with really clear backlogs and have the ability to produce a working tested increment—Scrum is a fantastic methodology.

Scrum and XP, you know, with all the craftsmanship stuff, excellent ways of building software. But largely dependent upon the idea of teaming strategies, right? Encapsulation strategies, backlog strategies and working tested software strategies. So, what we tend to recommend is let’s get your teaming strategies together first. Let’s figure out how we’re going to get strategically aligned backlogs, and how we’re going to connect those backlogs into a lightweight, Agile governance framework.

And then how are we going to hold those teams accountable for actually producing something of working tested value, and not only get stable velocity the team level, but steady flow across teams at the program level, and steady flow across teams at the portfolio level.

So, if you’re thinking about going through and doing an Agile transformation, take that into consideration. Because training is important, and we believe in training and people need to have skills transfer. But if we don’t get the underlying attributes of the organization, if we don’t get the underlying System of Delivery right, then what we’re going to end up with a lot of people doing Agile practices and like the phone calls we get, not getting the business benefit from it.

So, thank you very much for joining us. We look forward to continuing this conversation with you and good luck in your Agile journey.

As a community, we have developed a handful of team-based Agile approaches over the years; some of which we would consider scaled. But here we are. More than 20 years past the signing of the Manifesto, and we still don’t have this whole thing nailed. Implementing Agile, especially in larger, more complex organizations, still seems to be a black art.

Why is it so difficult? Why is Transformation so hard?

I wasn’t around when things like XP and Scrum were invented, but I have been lucky enough to spend time with many of the original signers of the Manifesto. I imagine it went down something like this.

We have these small teams working on troubled projects. When things hit the fan, often we get everyone in the same room. We pull the customer close. We make everything visible. We operate in a highly collaborative fashion. When we do this, we seem to be able to deliver and test frequently.

Someone along the way came up with writing requirements as user stories and putting them on cards. They hypothesized that estimating the cards and doing burn-down charts would increase throughput. That having weekly planning cadences; daily standups, reviews, and retrospectives would give people a reason to get in the same room and collaborate. Eventually, they landed on the ideas of Test-Driven Development and Continuous Integration and Deployment.

Over time, different roles and responsibilities emerged. All the things we consider hallmarks of a small team, Agile methodology.

As these methodologies emerged, the people inventing them found each other. At one point, 17 of them got together in Snowbird, Utah for a weekend of skiing. In the hunt for what these methodologies had in common, these 17 came up with the values and principles in the Agile Manifesto.

Why is this important?

Well, the methodologies organically emerged as a set of practices. They were codified into a set of values and principles. What is certainly noted, but often not materially emphasized, is the importance of the small, collocated team in direct contact with an actual customer.

I’d suggest small, collocated teams are the secret sauce behind the practices, values, and principles of Agile methodologies.

Fast forward a few years and Agile methodologies have a bunch of success and start to go mainstream. Things really take off with the advent of the CSM certification and PMI finally recognizing Agile as a legitimate way to do software project management. Traditional project management methodologies are process focused and agnostic to organizational design. Agile project management is totally dependent on organizational design.

As an aside, I was in the room when the PMI ACP certification was invented. There was almost no discussion of the importance of teaming strategies to the methodology. Somehow it was out of scope.

So why the history lesson?

I think it’s relevant to how most of us think about Agile adoption or Agile Transformation. And I think it leads to many of the common misconceptions I see about the introduction of Agile ways of working.

Misconception 1: Agile Transformation is About Installing Practices

The most popular misconception is that Agile is a set of practices and can be installed by trainers and coaches.

This is the easy button form of Agile Transformation. You train your teams on Agile, the teams start using Agile, recognize their impediments, and change the systems to be more effective at delivery. In practice, most teams are not empowered to change the systems they operate within, so they bastardize the processes to accommodate the dysfunction. This is where we see lots of teams going through the motions of Agile and not getting the business benefit of doing the approach.

The litmus test for this is as follows. Can any given Agile team claim to have a stable velocity against a known backlog? Can they produce a working tested increment of software every week or two that can be validated by an end customer?

If you are doing Scrum or XP and cannot do that, you aren’t doing Agile very well. Even if you are doing Scrum well. It is possible to do Scrum by the book and not create the results. Same for XP. Same for SAFe. Same for LeSS. Same for all of them.

Misconception 2: Agile Transformation is About Changing Culture

The next most popular misconception about Agile Transformation is that it is a culture problem.

The challenge is that it feels like a culture problem. It feels like Transformation is hard because of command-and-control leaders who don’t want to delegate to or empower the teams. It feels like an attitude and beliefs problem. A behavior problem. But let me tell you, if you understand how and why Agile works, and you understand what will get in its way, these leaders are right to stand in the way of Agile. Implementing Scrum or XP or Lean Startup on top of a tightly coupled legacy mainframe system is a recipe for disaster. Total chaos.

My observation over the past 20 years of doing Agile and transforming organizations, is that if you address the underlying technical and organizational concerns, you put forth a credible strategy for dealing with dependencies, and governance, and audit and compliance, you can often get people to run an experiment. They are willing to give another way of working a try. But often in the early stages, that means compromises to the Agile ideal. Allowing some compensating controls to emerge to deal with unresolved dependencies.

One of my favorite user group questions to ask is this. If you were king for a day, you could do anything you want, you could change anything in the culture or mindset of the organization, what would you do tomorrow? The caveat is that you had to start producing working tested software within a few weeks. What would you change in the org design? The technology architecture? The governance model?

You see, many of us want to believe that the teams know best. And that may be true about building software. But it’s not always true about running a for-profit software company.

Misconception 3: Agile Transformation is a One-Time Event

Another popular misconception is that Transformation is a one-time event.

Transformation itself is a process that takes years. It has a starting place. It has intermediate states. It has a defined end-state. But as customers and markets change, your organization has to change with them. So, the misconception is that the process is linear, and once the process is installed, or the culture has shifted, you will be done.

In my experience, this is never the case. We find that getting an organization to change requires a series of intermediate states that have to be traversed as you systematically improve the organization to enable greater Business Agility and move closer to the ideal.

Frankly though, most of my experience in Agile is in larger, more complex enterprises. My corporate experience prior to joining VersionOne, Pillar, and starting LeadingAgile was in financial services. Large mainframe platforms. Complex business rules. Audit requirements. Governance and control. Dates and requirements that mattered to our customers.

We could do a lot with Agile, but Agility was really difficult. So, I’ve had to make change in large companies since the very beginning. If you’re in a small single team, your mileage might vary.

Misconception 4: Team-Level Agile Creates Business Agility

The fourth and final misconception is that the things you do at the team level are sufficient for running Agile at scale.

My last post was about whether or not SAFe was Agile. SAFe is an approach for doing Agile at scale. In some ways SAFe is not sufficient. In others, it’s way too much. Safe is too willing to accept organizational dysfunction and dependencies as immutable. It doesn’t give us a clear path for change to make the overhead go down over time. It’s too complicated and too complacent with that complication. But SAFe is trying to solve a necessary problem that small teams don’t face. Dependencies and governance.

If you don’t believe that is an issue, you haven’t worked where I have worked, and you haven’t experienced what I have experienced.

Dependencies and governance are a reality. In the presence of these impediments, you have to manage them. But if you don’t have a plan for resolving them, SAFe will limit your ability to be Agile and to operate with Business Agility.

So, Transformation is about creating the conditions to do Agile well. And in large organizations, training teams on how to do Scrum or XP is wholly insufficient. You have to address the overall operating model. You have to address governance and compliance and audit and control. You have to tell the rest of the organization how it fits in and plays, or it’ll get in the way and fight your change efforts.

The Reality of Agile for Large Organizations

So, let’s get back to where we started. The early days of Agile.

In the early days of Agile, teams and customers and continuous deployment was almost assumed. In large organizations adopting Agile nowadays, it almost never exists.

Lifting the practices of a small team Agile approach and suggesting they will work in large, complex organizations is incredibly naive. Training teams working on a large-scale mainframe platform is often irresponsible. Blaming the culture of the organization for the resistance to change is a little myopic. You have to be a deep expert in the impediments that are going to get in the way of going Agile. You have to have a plan to remove the impediments over time and for introducing new ways of solving the same problems. You have to have a credible strategy for what you can do now, and what you can do later, as you improve the system.

I’ve been on record for a long time advocating what we call a systems-first approach.

It is possible to define an organization that minimizes dependencies. That orchestrates the ones that remain. that connects to governance and OKRs and KPIs. That connects to a large investment thesis and generates the data to show we are moving in the right direction. That system can be designed, it doesn’t have to emerge through trial and error. It is not big upfront planning to think through your solution architecture and org design and to create a teaming, governance, and metrics strategy that will lead to greater Business Agility, and most importantly, keep the organization safe and protected while it is changing.

In the presence of such an end-state design, a vision for the system of delivery,  you can start to think systematically about how you would incrementally and iteratively introduce change to the organization. You can start thinking about how to systematically introduce change and process improvement that doesn’t disrupt your business operations. The change plan and the timeline can be visible and accountable. You can come up with ways of engaging the organization to support the change and teach it how to maintain the systems you put in place, over time, as customers and markets shift around.

Over the past 12 years, LeadingAgile has had to learn to separate different sets of concerns when talking about Agile and Agile Transformation. As we have done this for our clients, we’ve centered on the following language.

System of Delivery

The “to be” operating model of the organization. You’ll find that you’ll have several of these depending on the constraints you have to overcome. You’ll end up with your initial state, several possible end-states, and several transition patterns. Agile isn’t one size fits all and change is a process.

System of Transformation

How are we going to introduce the changes. What parts of the organization. How long is it going to take? What are the leading and lagging indicators. How do we know we are making progress? How do we know the change is working and producing the results we desire.

System of Engagement

How do we lead and manage the transformation team. How to do we coordinate work? How do we create shared understanding across the organization? How do we create shared understanding and reduce cognitive dissonance during the change?

System of Continuous Improvement

What capabilities do we need to sustain the change and adapt as the organization responds to its customers and markets? Do we need coaching services? Training services? Business architecture? Value stream analysis? Project or program management.

Systems Over Practices & Culture

So, in conclusion…

To lead an effective Agile Transformation, it has to be more than practices. It cannot start with culture. You have to start with systems design.  Reinforce practices. And coach and develop culture over time within this new operating model. Change is not a one-time event and there will be various Transformation patterns that you’ll want to implement over time as you are able to improve the overall system and lighten up the operating models.

We’ve found it helpful to think in terms of various systems of change. System of Delivery, System of Transformation, System of Engagement, and System of Continuous Improvement. What will the operating model look like when we are done, how will we get there, how will we get people to come along, and how will we keep them there once we are finished with the initial effort.

What Transformation is NOT, is teaching people how to do Scrum or SAFe. Valuable, just not Transformation. Transformation also isn’t telling your leadership they are bad, and they need to trust the team. It’s about establishing reliable systems of delivery that your leaders can trust and know how to operate, over time. That help them run the business, achieve key performance results, and sustain the company into the future.

The Scaled Agile Framework wasn’t exactly what the authors of the Agile Manifesto imagined 20 years when they set out to define a better way of building software. But that doesn’t mean you can’t achieve greater Business Agility with SAFe. You just might not get the results you think you will get.

And that’s the problem with SAFe. It oversells what it is in the market. SAFe thinks it’s THE way to do scaled Agile when it’s actually just one way to do it. SAFe, like all methodologies, is limited by its environment and requires a certain context to be useful. But it shouldn’t be vilified for having limitations because it does some things really well—even if those things aren’t Agile as defined in the Manifesto.

SAFe & The Agile Manifesto

{The following is a transcript of the video}

So, I was running around on LinkedIn last week and I was noticing a conversation that was going on out on LinkedIn and it’s a conversation that comes up quite often and it’s the idea is it’s SAFe Agile. And you know, me personally, my company LeadingAgile, we’re fairly methodology agnostic.

You know, my general belief is that most, I’d say all the Agile methodologies, like the ones that come to mind like Scrum, XP, Scaled Agile framework, Large Scale Scrum, maybe Nexus on some levels, Disciplined Agile Delivery. My general belief is that there’s kind of like a core underlying reference architecture and most of the prescriptive methodologies are really just reference implementations of these kind of fundamental patterns and principles.

So, this idea is SAFe Agile. First, I think you have to think about is you ask yourself what is Agile? So, if you’re saying Agile is a thing, right? So Agile is a small team methodology that’s based upon the values and principles in the Agile Manifesto. It requires a co-located team. It requires access to a customer. It requires the ability to continuously deploy software, to continuously get feedback on it. Right?

If you take that approach to Agile, which is a valid approach, right? That’s how Agile was designed. It’s probably reasonable to say that SAFe isn’t an Agile methodology. I had a conversation with Alistair Cockburn about 10, 15 years ago at this point where we were talking about some of the emerging scaled frameworks that were coming out during that time. And his comment was something to the effect of like what we were doing in Snowbird back in what 2021 was a thing. We were talking about these small team methodologies. And what’s emerging in the larger ecosystem of methodologies, like scaled methodologies. It’s not that it’s bad, it’s just that it’s different. It’s just not what we described.

Will SAFe Lead to Greater Business Agility?

So, there was a post that came out that was like, you know, all the signers in the manifesto basically saying that SAFe wasn’t Agile. And by the definition of Agile, it absolutely isn’t, right? That’s inarguable, right? The guys that invented it say it’s not. I think they get to decide. Now the challenge is, does SAFe lead to greater Agility? Okay? And you know, LeadingAgile really isn’t in the methodology business. We’re in the change business. And so, if a company wants to implement SAFe, we can help them implement SAFe.

If a company wants to implement Large Scale Scrum, we can help them implement Large Scale Scrum. Disciplined Agile Delivery? Fine, right? Generally, what we end up doing is implementing hybrids of different things, right?

So, we take, you know, in effect, team-based at the work surface level, we do some sort of Kanban/Big Room Planning, kind of release trainee kind of stuff and what in what we call like a middle tier. We tend to think of having a portfolio tier at the top. Because what’s really going on with SAFe is that the organizations that are trying to adopt Agile are not built very well for Agile. They’re not built around small teams. They don’t have lightweight governance. They’re not dependency free. There are architectural dependencies. There are people dependencies, there are requirement dependencies, there’s governance and controls and metrics and all those kinds of things.

And so, what SAFe kind of came along and did in my opinion is it said, okay, given the constraints and an existing organization, poorly formed teams, dependencies, all the things we just talked about. What we’re going to try to do is we’re going to try to create a framework that increases Agility. Right? So, it’s not Agile as described in the Agile Manifesto, but there are conditions where SAFe can deliver greater Agility.

And one of the earliest engagements we ever did, it’s been with a long-standing client, and one of the things I said to their President was, “you’d be halfway to being an Agile organization if you just stopped approving 18-month projects.”  If the organization just did three-month projects, right? And was able to put things in market faster, there would be a greater level of Agility.

But when I really break down, what is it about Agile? Agile is, by definition, a small team methodology. It’s six to eight people, typically co-located, I guess it’s probably not as much of a thing anymore. They have access to a customer or a Product Owner in Scrum and they’re able to produce a working tested increment at the end of every sprint.

One of the things that I’ve been observing for a long time is that what Scrum fundamentally assumes is that the value stream is fully encapsulated in that team. So, the whole idea from voice of customer, the product owner, analysis, design, build, test, deploy, typical Waterfall kind of stuff that’s all kind of encapsulated within that team. The team meets on a regular cadence, identifies the backlog, breaks the backlog down, roughly plans out their work. Daily stand-ups, burn down through the sprint, able to produce a demonstrable increment of the product, signed off by the Product Owner.  We do reviews and retrospectives, right? That’s typically Scrum.

But what do you do when the value stream is not encapsulated in a single team? What do you do in a situation where you find yourself with lots of teams that have to come together in order to be able to deliver in an Agile way?

Well, like Large Scale Scrum, I think has it largely nailed, right? You know, Bas Vodde and Craig Larman, it’s been a while since I’ve read their work, but they were rather insistent, I recall, on the idea that you had to organize around features or capabilities. You had to decouple those dependencies. They had to be set up in a way that they’re continuously deployable. And then you could imagine an ecosystem where maybe a product was supported by 50 teams, but each of those 50 teams were able to largely operate independently of each other. So, when I think of even aspects of something like the Spotify model, aspects of Large Scale Scrum, I think that is what those systems are calling for. But in a lot of corporations and a lot of technology platforms, you don’t have that level of encapsulation at the team level. And so again, SAFe is a response to the fact that you don’t have the appropriate decoupling.

And so, what we find in an early-stage Transformation is that there’s a lot of organizational dysfunction. And so, in an early-stage Transformation, you can generally get yourself to a place where you’re able to form teams, but those teams are often not perfectly formed and often don’t have everyone and everything necessary to be able to deliver. Often, they can’t truly get to a working tested increment of software at the end of every sprint. So, a lot of times what we’ll do is we’ll wrap a bunch of teams in what we’ve been you would call like a program level or product level Kanban. Right?

So, we’re doing more upfront planning. We’re kind of doing rolling wave, progressive elaboration. We’re doing a lot of decomp ahead of the team. We’re making sure that backlogs are sequenced across teams and those backlogs are like cross-cutting concern, dependency aware. We’re making sure that as user stories get sequenced, we are optimizing for the flow of features across teams. If I’ve got multiple product or program teams, maybe like a value stream kind of organization, then sometimes that will like flow up to a top tier like or like a portfolio tier or an investment tier. And all of that stuff, right, regardless of how you implement it, whether you implement it kind of like LeadingAgile does by default or whether you choose to go with something like SAFe, what you’re acknowledging is that you’re acknowledging that you’re installing a compensating control that is absolutely necessary in the presence of dependencies.

It’s absolutely necessary in the presence of cross-cutting concerns. It’s absolutely necessary in the presence of integrated deliverables. It’s absolutely necessary in a situation where you have coordination across teams and over time. But they are compensating controls. And to the extent that you have dependencies, you have to manage them. But anytime you leave a dependency in the system, it going to reduce your ability to be pure-play Agile.

So, when you look at LeadingAgile’s model around what we call our Quadrants, our Basecamps, and our Expeditions, what we’re basically acknowledging that is in like a Basecamp 1/Basecamp 2 ecosystem, it’s a lot just to get organized around teams. It’s a lot just to get everybody doing Scrum. It’s a lot to bring the business and the technology people together to do the coordination, the decomposition, and figure out what’s minimally viable and all those different things.

And so, sometimes it’s enough just to kind of break apart the existing structure and just to get it operating using Agile teams and flow-based metrics and more collaborative requirements decomposition, more just-in-time, more progressive elaboration, more rolling wave. You can get a lot of Agile out of that.

So, is it Agile as described by the Agile manifesto? No, it’s not. Is it greater Business Agility? Does it actually allow the customers to get more business benefit earlier? Yeah? Does it start to establish some healthy patterns? Yeah, It absolutely does. Is it small, team-based Agile as described in Manifesto? Absolutely not.

The Real Work of an Agile Transformation

So, the trick in Transformation isn’t to teach people how to do SAFe. The trick in Transformation is to, you know, aim for completely decoupled teams to acknowledge that those teams are not going to be initially decoupled. And then to install appropriate compensating controls in the presence of the dependencies.

As you move more to continuous integration, continuous deployment. As you move into DevOps. As you are able to negotiate more frequently release cycles with your customers. As you’re able to break dependencies between teams. As you’re able to change the governance model and the financing models and going from projects to products. As you’re able to empower those teams to make independent decisions in market. You can actually deprecate some of those compensating controls.

So, Transformation, again, is not about installing SAFe or installing Scrum. What Transformation is about is taking the organization from where it is to the level of Agility that it needs to be. And so, what we do is in an early-stage Transformation, a lot of times the compensating controls are actually heavier than SAFe. And then you actually have to change the organization in some ways to even get it ready to be able to do SAFe. You have to break a lot of dependencies and create a lot of technical infrastructure to get it ready to do LeSS. You can take it further and have every team be able to operate independently off a backlog. You can take it a step further than that and you can have those teams operating independently in market and being able to inspect and adapt and to figure out what those customers need. But it’s not one-size-fits-all.

The Transformation Journey is about improving the underlying organization.

The Problem with SAFe

So, I guess in short, what I think the problem with SAFe is, it’s not that SAFe is an invalid methodology. I don’t really care whether it’s pure Agile or not, right. I’m totally fine. I think there’s a lot of places where SAFe can lead to greater Business Agility, but I don’t think even that’s a guarantee because a lot of really large organizations that are trying to install SAFe, they actually have insufficient compensating controls and they’re not focusing on the org design and the dependencies as much as they should.

And so, I think the rub with SAFe is that it says that it is THE answer for Agile at Scale. It is AN answer for Agile at Scale. It’s often implemented poorly on top of organizations that can’t support it very well. And then to kind of add insult to injury because it says it’s THE answer, people think that if they do it, that it’s going to solve their problem. SAFe is just one of many compensating controls for how to achieve greater Business Agility in the presence of poorly formed organizations and dependencies.

So, my in short answer is I actually prescribe more planning in an early-stage Transformation. It actually requires work in most companies to get to a place where you can actually do SAFe, but leaving it as a SAFe implementation is probably suboptimal as well. What you really want to do is you want to decouple as many teams as you can, get those teams operating independently, get your project funding turned into product or team-based funding or organizational-based funding. And then, ultimately, for a subset of the organization basically be able to marry that set of teams or that subset of the organization with a customer and be able to take feedback and expect them to adapt as you go. Right? That’s the answer.

So, is SAFe Agile? Like, no, it’s not by the original definition. Under the right conditions, can it increase Business Agility? Sure, I believe it absolutely can. Is it an end-state that I think is recommended? No. Again, I think it’s not enough at the beginning and I think it’s too much at the end.

So, I guess my position on it would be is that the only problem with SAFe is that it’s overselling what it is in market. Yes, it is a mechanism for being able to orchestrate across multiple teams with dependencies. And that’s what it is, right? And it can lead to greater Agility, but it’s not small team Agile. And I don’t think it necessarily achieves the level of Business Agility that most organizations think it’s going to. Again, primarily because in most SAFe implementations that we’ve seen and cleaned up after, it doesn’t go far enough prescribing the actual nature of the organizational change or how to actually make those changes in the organization. So that’s kind of like my hot take on Scrum, or excuse me, on SAFe, and if SAFe is Agile.

People have debated whether or not SAFe is Agile for as long as it’s been around. LeadingAgile CEO, Mike Cottmeyer, joins Dave on this episode of SoundNotes to explore the roots of small team Agile and to discuss how SAFe stacks up against the ideals of the Agile Manifesto.

Want to Listen Instead?

Contacting Mike Cottmeyer

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

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

Contacting Dave Prior

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

LeadingAgile: https://www.leadingagile.com/guides/dave-prior/
LinkedIn: https://www.linkedin.com/in/mrsungo
Twitter: https://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/