Leveraging Agile to Get Predictable

Agile isn’t ever really about Agile. It’s about creating business outcomes.

In our Business Drivers of Agility webinar series hosted by LeadingAgile CEO, Mike Cottmeyer, Mike dives deep into six key business drivers to uncover how Agile can enable organizations to connect these drivers to better business outcomes.

In this first webinar, we start with predictability. Even though we tend to think of Agility as nearly synonymous with adaptability, one of the most common goals we see organizations have for Transformation is actually predictability.

The good news is that many aspects of Transformation are definable and repeatable, so they can be predictable. In this webinar, we discuss how to create more predictability so we can meet our commitments to customers, and build trust with everyone from internal stakeholders, to customers, to our entire market.

Check out the predictability webinar, and then click below to access the next five webinars that cover the five additional business drivers on-demand, including: Quality, Cost Savings, Early ROI, Product Fit, and Innovation.

Transcript

So, what’s kind of interesting is over the last webinar series and this webinar series, what we’re really doing is we’re really kind of going back to basics. And so last time, we talked about things like balancing capacity and demand and dealing with issues of trust and trustworthiness, the idea of dealing with things you know versus things you don’t know and the idea of encapsulation versus orchestration. We talked through that.

Tim, is going to drop a link for you guys later on if you guys weren’t part of that webinar series, because I think we’re going to reference some of it. But the idea there was is let’s go ahead and let’s start exploring some of the really foundational things of what makes Agile work, what makes it work at scale, what are we really trying to accomplish, right, that kind of stuff. And so, what I thought we would do is kind of continue along that theme here for the next six weeks and talk about some of the drivers that cause us to want to adopt Agile.

And one of the things that I think is interesting is a lot of my message over the last 10 years, 15 years, maybe even, there’s been a little bit of a reaction to some of the things that I hear us talk about and prioritize in our community. And I think a lot of us sometimes we get enamored with the idea of things like having an Agile culture, or having an Agile mindset, or the kind of work environment that Agile creates for us. And all of that stuff is absolutely true. And we want to create great environments for great people to work and to be able to show up and to do their best for the company that they work for.

But a lot of times, the where we’re at now, I mean, it’s just interesting, we’re like 20 years in almost to post signing the Agile Manifesto. And the guys that sign that thing, they changed the world. They did a great job of getting the message out Scrum and the Scrum certification did a great job of getting the message out. We’re starting to see HBR articles written more than one. I think there’s two or three of them that are been written in the last couple years. And not only like the CIOs are interested but the CEOs are interested, and the finance people are interested in the product, people are interested in the market, there’s a lot of stuff that’s interested.

And so generally kind of what would happen is we have this kind of hypothesis, and we said, if… wrong from pen here, right? So, if we do Agile, right, we’re going to get business results, okay? That was kind of the hypothesis. And then we said, “Okay, well, what does that really mean?” Does it mean that we change the culture, right? Does it mean that we start Doing Scrum, right? Like if we show up and we do sprints and daily standups and everything, are we going to get the business results that we want? Well, the answer is, most things, it depends.

If you’re a small team, right, if you’re literally a company of six to eight people, right, there’s probably like a ton of business benefit that you would get from planning and Scrum cases. There’s probably a lot of business benefit you would get of adopting an adaptive kind of culture. But what we’ve learned viscerally over the last 10 years is when you go into particularly large, complicated organizations, just the adoption of these practices or the adoption of those mindsets doesn’t really drive the business results that we want, because we know, right, because a lot of us, I imagine if you’re here on this call, are working in these large organizations. And there’s just a lot of stuff that’s just kind of fundamentally broken.

And so, from how we do governance and how we do project planning and how we do organizational structure, all those kinds of things, right, so there’s this big hop. And a lot of times I reference, there’s a cartoon, I should actually have it on the ready because I talk about it all the time. Two scientists sitting at the board and it’s like a bunch of math over here and a bunch of math over here and there’s like this cloud in the middle that says, then a miracle happens. And one scientist says to the other in a caption, I think you need to be more specific in step two. It’s kind of like we start with this idea that if we do these things, were going to get these business results and it doesn’t always kind of play out that way, okay?

And so, this is how we get from Agile to the business results is really the step two in my argument, right? It’s how do we do it? And so our whole model and everything that I’ve been talking about for a long time is about how do you move an organization from where it is to become the kind of organization that can take advantage of these drivers, right? So that’s where we got into last time, right?

So we talked about things like how do you balance capacity and demand at the team level versus the program at portfolio level, and issues of encapsulation and orchestration and dependencies, and things like that. Because those are the things that fundamentally get in the way how we govern, right, how we deal with cross cutting concerns. Those are the things that get in the way of making Scrum not work in a lot of organizations. So these things can be very difficult to try to overcome.

And so that’s where we started. The six things that we’re going to cover, and there’s probably more as I was actually noodling on kind of an outline for what I wanted to go over, is we’ve learned… I’ll go through the six that we’re going to cover and then maybe we can [inaudible 00:05:52] and go a little bit more. But what we’re going to talk about today is the idea of predictability, okay? And so, predictability is really all about figuring out how to make and meet commitments and how to do what you say you’re going to do. So we’ll go deep into this one today.

What we’re going to do next week is we’re going to talk about quality, right? How does Agile lead to better quality, not just accepting for the fact that it does, but like literally, what are the mechanics of Agile and how do the Agile practices lead to quality?

Early return on investment, okay? So we talked about being able to put products in front of customers and to be able to get feedback but a big driver behind that is we want to put products in front of customers earlier that we can sell so that the organization can start receiving money for those and fund further development because it’s a pretty expensive proposition to do three to four years of development, excuse me, or even a year and a half of development or, gosh, even at this point, six months of development without getting any validation or revenue out of that.

So we’re going to talk about what aspects of an Agile enterprise or Agile is going to lead to early return of investment. And then the fun one, this is going to be the one I’m probably going to dance around a little bit, is a lot of times what we’re looking for is cost savings. And so, cost savings is difficult because most organizations are really, really overloaded. And so there’s 10 times more work to do than the organization can actually do.

So, really difficult to come in and say, yeah, Agile is going to help me lower costs so you end up starting to have a conversation around throughput and highest value and deploying resources, people and dollars and things like that, into the most valuable things, right? So we dance around cost savings a little bit. Those are my original four. These are the first ones that I was talking about probably eight or 10 years ago.

And then we kind of evolved a little bit and we started talking about things like innovation, right, because that’s a big thing that people want, right? So how do I take this legacy organization and make it more innovative, right, the ability to disrupt markets or maybe even cannibalize our existing business, right? So there’s some patterns of Agile and Agile scale that either lead towards innovation or getting away of innovation, so we’re going to talk about that.

The idea of product fit. Are we building the right thing that our market wants to buy, how do we know, right, that kind of a thing? And then what’s really fascinating as we’ve gone deeper into this Elevate Agile conversation that Tim talked about a little bit earlier, and we’re really talking to executives about what they care about, we start to get into things, what I might call, strategic alignment, right?

How do we deploy the organization in a way that maximizes our ability to advance our strategic objectives? Agile has something to say about that. It’s not about just what features that I put into the product but it’s about what capabilities that I develop organizationally and where do I invest dollars so that I can realize these big market shifting kinds of goals, right.

And then the last one, I was thinking about a little bit, I’m kind of looking at my notes so we’re talking about strategic alignment. This might be a thing, I haven’t thought about this this clearly, but I almost want the words, I want to use like investment optimization. So, a lot of times, it’s like we have a really good idea of what we want to do but it really comes down to what’s the MVP of that? What’s the smallest thing that we can do that’s going to realize the value so we make the smallest investment possible to maximize the return on investment in the marketplace?

So I’m going to put something like value optimization here, okay. So, can’t seem to spell in front of you guys today. So these two are going to be kind of out of scope. But what we’re going to hit is, we’re going to hit predictability, quality, early return investment, cost savings, innovation, and product fit. Today, we’re going to start with predictability. And one of the things that I think about a lot, right, and this is something people ask me quite a bit. They don’t ask me the question anymore like how do I get my executives interested in doing Agile because that was like a seven, eight year ago question.

It’s relevant for some people some of the time but it’s not the predominant question. The predominant question is how do I get my execs to spend money on this or how do I get my execs to fully participate in the transformation? How do I get my execs to really care and invest time and energy and to show up and all those kinds of things? And generally the answer is I encourage people to talk about the things that the executives actually care about and what keeps them up at night.

And so sometimes I’ll put this idea of predictability into the idea of, you think about your CEO, right, and your CEO or CIO or whoever is making promises to market. They’re telling their customers what the organization is capable of doing. And they’re counting on the fact that all of the planning processes, all the project management, or all the Agile or all whatever, is going to help them make promises, okay? And they care about that because when executives make commitments to market and then the delivery organization doesn’t deliver against those commitments, then the CEO is effectively kind of lied to market, right?

And maybe not intentionally obviously, but it’s they haven’t delivered. That is a personal thing, right? People don’t like to be in a situation where they make promises and they can’t keep it. So, from a very human perspective, what we want to do is we want to put our executives in a position where the organization is a reliable, trustworthy partner that the executives can say with reasonable certainty, this is what we are capable of providing and this is when we are capable of providing it, okay? And so that idea of predictability is what I’m talking about.

And so, again, if you were at the first couple of talks that we did, the last series of talks, there’s inevitably going to be a recurrence of themes. So what I think we’re going to end up doing over the next six weeks is talk about some common themes that, if you followed my stuff that I hit over and over, but we’re going to put a different lens on them, okay? So the first lens or the first set of foundational things that we’re going to talk about when it comes to predictability is the idea of the three things, teams, backlogs, working tested software.

And so, if you think about a predictable Agile team, a team that can make and meet commitments, that’s going to be able to do what it says it’s going to do, right? The first thing that that team needs is it needs clarity on the backlog. Okay? And that means, in some form or fashion, we need to have a stack rank list of things that we are going to build, okay, product backlog, maybe user stories. And now, remember, that my focus is super narrow right now. I’m not talking about enterprise agility. I’m not talking about elevating the conversation. I’m talking about team level agility.

So the fundamental building block, right, team level agility. How do we get a team to be able to make and meet commitments, right? So, the teams make and meet commitments by having a stack rank list of user stories, right? We typically want to have those stories estimated, right? We want to be able to bring them into sprint planning and have a conversation around them. The team gets clarity on what they’re being asked to build. They understand the acceptance criteria. And they’re able to say, “Yup, this is reasonably what I think we can pull off,” right?

And then we want the team to have the ability to be accountable, right. So we’re going to put a team here, right? What is a team? Why would I use the word accountable, right? Well, because a team in Agile, as described by Scrum in the Scrum guide, is when they say five plus or minus two, I usually like to use six to eight kind of in the same ballpark. And it’s a group of people that have everything and everyone necessary to be able to deliver a working tested increment of software or whatever product that you’re building, okay?

So, since we’re typically in the software space, six to eight people have everything and everyone necessary to build a working tested increment of software as described by the backlog, okay? If that team has everything and everyone necessary to be able to deliver that working tested increment, Scrum should work as described. They pull a chunk off the backlog. They go through sprint planning, maybe they decompose the work. They pull it in, they swarm together through the life of the sprint. They deliver it, they review it with the product owner, product owner says yes, and then they get to claim the points, right?

And, again, there’s other ways to skin a cat, right? But you get the idea, right? That’s one way, right? So, a team that can establish a stable velocity against the, I can’t write today, against a known backlog can start to say, “Okay, cool,” right? We know what we can produce every sprint. Why is acceptance criteria or definition of done or deployability or even so far as to extend it out to like we actually have deployed it with customer? Why is that important? Because when we get to a point where we have a really clear definition of done, I never know how to draw a software. Sometimes I want to draw it like as a box but that gets kind of crazy, right? But you guys get the idea, right, software.

So database table, right? That kind of thing. It’s a screen. So the idea is that we produce this working tested increment. And the reason why the acceptance criteria is so important is because if we are clear on what this backlog item is, and we have an idea of its relative size, we pull it into a complete cross functional team that has everything and everyone necessary to be able to deliver that set of user stories.

And we validate that it met the acceptance criteria and it satisfied the definition of done, which means that there’s no like shadow backlog emerging over here, that basically is all the things that we really didn’t get done that are going to be necessary to deploy, right, defects, technical debt, unrealized features, right? All the little different cruft that kind of accumulates as you’re building stuff, right?

If we don’t do that and we’re actually done then the math of Agile work is at the team level, right? So we know the size of the backlog. We know the velocity, velocity of a team, and then we can start to derive how many sprints it will take to get through the backlog or how much backlog we can do in a predetermined number of sprints, right? So that gives us the ability to reliably make and meet commitments at the team level. Now, think about how this actually works in practice quite often, okay?

Product owners not quite present or the product owners delegated to a BA. The BA doesn’t really have the authority to decide. And the backlog just kind of starts out indeterminate, okay? If I don’t know the size of the backlog, I can’t get to the point where I know how much that backlog I’m going to be able to do or how many sprints it’s going to take. Let’s think of another pattern, right, that happens quite often, okay, is the product owner is not partly present at all, slides in for the sprint planning meeting, and kind of just rattle some things off just like a sprint at a time, okay?

In that particular case, even if they write perfectly clear backlog items, we have no visibility into the rest of this, okay? Now, different organizations have different needs for predictability, right? In my organization, LeadingAgile, I have a software development team, I have zero need for predictability, like zero need for predictability. We are building an internal tool. It’s totally a proof of concept. We use it as an enabler of our consulting teams and we have absolutely no commitments to market. And as long as we’re investing to learn, my life is good, as long as we’re making reasonable progress, my life is good, I continue to make those investments in that team.

Really different from somebody who needs to have a feature set ready for a tradeshow in market in a quarter, really different than somebody who has a mature customer base and who needs to be able to publish a roadmap, right, so that their enterprise class customers can begin planning for different integrations with them overtime, right? And so, a lot of organizations don’t need to know exactly where they’re going to be but they have to have a pretty good idea where they’re going to be.

Or let’s say you’re bidding on a fixed price contract for the government or something and you’re going to be locked into fixed time, fixed costs, fixed scope, you need even more predictability, right, more ability to figure out how to make tradeoffs within constraints, and all that kind of stuff. So different organizations have different needs for predictability. So, if you’re an organization that doesn’t need any predictability, this is probably a wrong talk for you, right? If you’re an organization that needs three to six months out, this is valid strategy. If you’re an organization that needs a year or a year and a half roadmap, that’s the next level up in the conversation, right?

So, predictability can be all over the place. What I find sometimes, right, and this is where we get sideways with our executives, is that the executives want predictability. And as Agilists, we approach it with like a very lean startup mindset and we go, this is Agile, you don’t get predictability, right? That is a surefire way to get excused out the door if you’re a consultant and it’s a surefire way to get marginalized if you’re an internal employee.

If the organization wants predictability and is asking for predictability and has enabled you as a team of Agile coaches to provide predictability, you may say, “We’re Agile, you need to change your need for predictability.” Like, “Okay, right cool.” If you want to fight that fight, fight it, but that’s a very low probability win for you, okay?

So generally, the strategy is meet the organization where it is, this gets in the whole transformation strategy, meet the organization where it is, help it become predictable using Agile tools and techniques, and then figure out how to help it reduce batch size and make decisions more rapidly, right? So we’ll get into that when we talk about some of the early return on investment stuff, okay?

Well, let’s get back to our story, right? So, let’s think about some of the anti-patterns. So, the product owner comes in, backlog is not very well defined, team doesn’t know how to plan for it, can’t stabilize velocity, build software, starts accumulating this cruft on the backside of stuff that doesn’t really work, breaks our predictability, okay, just breaks it, right? Or alternatively, let’s say everything is right but the product owner comes in at the last minute and gives us a sprint at a time.

Like my work in some environments would work for me, right, in LeadingAgile, my software team, but it would not work for an organization that’s trying to hit a tradeshow in a couple months, right, because we don’t know we’re it going to get. Or is trying to deliver on something that they promised the customer, it’s not going to work that way, right? So we have to put a lot of effort into grooming that backlog further out so that we can establish predictability.

What gets in the way of teams being able to be predictable, right? So I kind of went through great lengths to say the team is a group of six to eight people that has everything and everyone necessary to be able to deliver a working tested increment of software, okay? So, what if I don’t have everyone and everything necessary? In some form of fashion, that means I have a dependency. So when I have dependencies between my team and somebody else’s team, or my team and somebody else’s resource pool, then I am dependent upon them to be able to do what they say they’re going to do so that I can make and meet commitments and establish stable velocity.

So, one of the big hallmarks that we try to go for when adopting Agile is to pull the team together in such a way, to design the team in such a way that the team has everything and everyone necessary so that it can establish stable velocity. And hopefully that velocity is stable overtime, right? There’s obviously variation and things like that but if you can get kind of a good rolling average, that’s probably good enough, enables you to make tradeoffs, right? But dependencies get in the way, external resources, technical dependencies or all kinds of different dependencies, get in the way of being able to establish a stable velocity.

If you can’t establish a stable velocity, you can’t be predictable. Now, here’s a really common thing, right? So people say, “But my team, we’re like the typical Agile team,” right? So we build the product and we support the product so we can predict the build side of a product, right? Maybe we’re great at doing user stories and estimation and kind of release planning level stuff. We’re really great stabilizing velocity, we have a complete cross functional team, but part of our backlog is interrupt driven.

That’s an interesting problem, right? Because anytime that you are mixing, what I call a determinant backlog with an indeterminate backlog, right, then you have to basically deploy buffering strategies, right, so that gets complicated. And so a lot of times, what the team will do is if the break/fix work is kind of predictable, right, it kind of comes in an even flow and you have good relationship with product owners, you just buffer some time, right? I’ve seen teams run Scrum for their product development and then throttle work in process via the like a Kanban queue that they kind of run on the side.

I’ve seen teams rotate team members out of a team or put somebody like in responsible, like he’s responsible for triage. Back when I was at VersionOne, this guy, he’s still there, I guess CollabNet now, a guy named John. And he was like the support guy and so they would assign one developer to John every sprint, they called it being on the John that sprint, I thought that was kind of funny. And so that one guy on the John, but that was their strategy for triaging and having one person on the team kind of separate to deal with most of the break/fix stuff.

Now, if you’re in a situation where you’re like your software is so chaotic and you’re dealing with tons of break/fix stuff and it’s just totally indeterminate, just a crazy wave, that becomes a different problem. Because now, you’re just not going to be able to make and meet commitments. So now you’re not talking about like, how do I do Scrum, right, to be able to be predictable? You’re like, how do I stabilize my codebase, right? How do I stabilize my product so that I’m not in this situation, or you have a bigger class of problem than just figuring out how to do Scrum or form teams or something like that, right?

And I’ve been in teams in those situations as well, right? Very difficult to be successful when you’re dealing with those kinds of constraints. So, a lot of my mental model isn’t to say, how do you do Scrum in the face of impossible circumstances to become predictable? Like a lot of my mental model is, this is what’s absolutely required to be predictable, you have to create the conditions for the group to be predictable.

Because you just won’t be predictable otherwise, right, unless you create the conditions for predictability. And that is known backlog, whatever planning horizon is appropriate, a stable cross functional team with few if any dependencies, and then the ability to get to a definition of done, right?

And that definition of done in effect is no defects, potentially shippable, right, different contexts are different, right? So it’s like I love you to have any production every two weeks but that’s not realistic in a lot of context, right, ERP and different things that have longer app release cycles, right? But basically, the principle though is to get it to a place where you’re not dealing with this indeterminate backlog on the backside, right? Okay, cool.

So we’re about halfway through. I always wonder whether I’m going to be able to fill up the whole hour talking about these little micro topics, but it’s inevitable, right? Because some of these principles, and I also feel like a lot of times I’m repeating myself because it’s like we’ve been talking about these ideas for so long but I still, Tim reminds me all the time based upon search traffic and the things that people are engaged with, these are still like really, really common problems. And what I’m trying to do is I, and again, even though they’re common problems, the solutions are nontrivial.

But, again, the mindset you guys have to come with is if you want Agile to work and you want it to deliver this particular business driver, this predictability, the ability for the CEO, CIO to make and meet commitments, these are the conditions that you have to create, right? So now, when you start to scale up this conversation a little bit, and we’ve often talked about it like this, right? So we’ll say, I call it the three things, right? So we talked about teams, backlogs, working tested software.

And I wish I would have rolled it off my tongue the first time as backlogs teams working tested software because then it would be congruent with how I typically draw it, but it just wasn’t to be, right? So there’ll be probably a forever incongruence between that, right? So, teams, backlogs, working tested software. As you start to think about scale and being predictable in the large, okay, now we’re dealing with what we call structure, right, which is the way that multiple teams relate to each other. Backlogs becomes governance. And working tested software and today it’s probably still working tested software but what I talked about is metrics, right? How do we measure value across multiple teams?

And it all boils down to the same fundamental concepts. But now as we start to scale, we have a slightly different class a problem. We have more of like a Theory of Constraints problem. We have bottleneck problems in the system. Now, if you go back to some of the early thinkers around this, and I don’t even know if you consider these guys early because everybody’s still out and about and doing things. But I go to some of the early Schwaber stuff on scale, some of the [inaudible 00:30:58], Craig Warman stuff around Scaling Scrum and what’s kind of emerged in the Large Scale Scrum framework now.

Those methodologies, I think, are really spot on, right? And I think they brought a lot of wisdom into our community. The challenge is I think it kind of hand wave over the fact that most organizations, at least initially, are products, or excuse me, projectized organizations, right? They approve dollars in project tranches, right? And they have a lot of dependencies and a lot of misalignment within the organization. And so, the way I look at a lot of those models is if you are a well-formed organization, and you don’t have a lot of dependencies, and you are doing team or business capability or value stream-based funding, then I think those methodologies are spot on.

But what do you do in a system where you have, what I would call, uneven investment at the team level, right? The reason why people want to move people around and not form the right kinds of teams and not build the right kinds of backlogs is because they want to deploy resources, people, I apologize if that offends anybody but it’s kind of ingrained in me from 30 years as a project manager, right? If you want to deploy people into projects, right, then what you end up having to do is you have to slice people and slice teams into little bits to be able to get them to fit right into the project metaphor.

The flip, this is a big, it’s really a high level strategic thing that maybe we’ll talk about towards the end of the series. But it’s like one of the big things that we’re trying to get a lot of our large transformation customers to do is to, after they’ve established this Agile enterprise, really get the governance to stop thinking about funding projects as an investment vehicle but funding products. And products can be a lot of things, right? It can be a business capability, it can be a value stream, it can be a subcomponent. There’s lots of different platform strategies and different things like that. But the idea is that you’re funding teams, right? You’re not funding projects.

This goes back 20 years in Agile. It’s like what we want to do is we want to bring projects to teams, not bring teams to project’s right. So it’s a flip of that mental mindset that’s still particularly relevant. But when you’re in transition, right, or when you’re in an unbalanced, non-team funded environment, what you end up with is something like this, right? You end up with multiple teams, right? So let’s say you’ve done everything right, okay? So now we’re on an established baseline, right? Everybody has perfectly formed backlogs. Everybody has groups of six to eight that have everything and everyone necessary to be able to deliver working tested increment of product, and every team is able to produce a working tested increment at the end of the sprint, right?

So, now we’re talking about perfect execution at the team level, right? So, this is why it’s so hard. So Tim was talking about our Elevate Agile conferences coming up. We ran a pilot of it effectively last year. And, I mean, we had some really, really cool speakers, we had clients like guys who are like, VP, Senior VP, enterprise architecture, right, all this kind of stuff, totally get this idea of scaling and governance and like how do I do this, I’ve worked with them for a long time. But it’s like, what’s super hard about is everybody wants to start at the team level because that’s the building block, right? If you don’t get this team level stuff right, it’s really hard to do the higher level stuff right?

But here’s the problem. This is why we’re doing this Elevate Agile thing. It’s like, as soon as you start talking about the team, you lose the business, right? So I’m kind of talking to you guys as kind of insiders on this to understand the problem. Team level agility is absolutely team level predictability to make sure we’re really anchored in in this context. Team level predictability is absolutely essential for enterprise level predictability. You’ve got to get the backlog straight, you got to get the teams formed, you got to get the dependencies broken, you got to get each individual team the ability to produce working tested increment at the end of the sprint, okay?

But team level agility is insufficient for enterprise level agility. Let’s talk about why, right? Because at some point, you have this thing called a project that gets funded on high, right, some governance structure, some group of executives is approving a tranche of dollars. I don’t use the word tranche a lot and I’ve used it like three times in this call, so I don’t know I have to evaluate my vocabulary here. This tranche of dollars is associated with the project because projects are often the thing we think about to achieve business outcomes, right?

And so, the mental model is, is the business brings this initiative to the table, I want to do this in the software stack. I’m going to ask for dollars because the idea is I’m going to get more dollars on the backside, right? And, inherently, what ends up happening, right, is that we take people out of these teams and we assign these human beings up here, right, and we go, we send them to do that. Well, let’s say we had this layer in place and we kind of fix the structure and we got agreement that we weren’t going to bust up teams to go deliver projects. But now we’re going to bust up the project to be able to send the components to the team, okay?

And so, what would that look like, right? So you’d have some key, I like to call these epics. I think of projects as like epics. I know some people think epics is lower level like just bigger stories, but I tend to think of epics as something that has a value to the business, right? So I’m going to use my word, right? So, we take our epics and we break them down into features, right? And then those features get assigned to users or they get broken down into user stories.

Let’s say this particular epic, right, was really heavy, I’m going to switch to different color here, was really heavy on team one. That’s supposed to be a T, it looks like a crazy Y, right? It’s really heavy on team two, has some work for team three, right? And no works for team 4, no works for team three and team five, right? So, what we find a lot of times is we break up work this way that we end up with, we end up with teams that have way more to do than they can do and we have teams that have very little to do, right, so what are they going to do, right?

And so you start to say, “Well, let’s figure out what’s the next thing,” right? Well, what if the next epic, right, that’s the highest business value, it just further exacerbates the problem, right. So we have people, we have teams deployed into these capabilities that are necessary and then we have starved teams. A lot of times what happens, one of two things happens, right? This is what’s fascinating. We go figure out, so we go through and we go through like the stack rank list of all the initiatives and it’s only the 20th initiative, right, that requires teams three and teams five, okay? But the 20th initiative also requires a little bit from team one, a little bit from team two and a little bit from team four.

So we say, okay, we want to get teams three and five busy so we load up their backlogs. But here’s the reality, this little itty bit of work down here never gets done, right? So all this work that teams three and teams five are dealing with… That’s interesting, we got almost like an ink spot on my screen there. They’re never going to realize business value, right? So it’s not like a prioritization problem. It’s not a dependency management problem. It’s not a commitment problem. It’s a you were never going to be high enough in the queue to get the attention of these constrained teams, right. It’s just not going to, right?

So the strategies that we tend to try to employ are things like balancing at the portfolio level and making investment decisions that are aware of the capacity of each of these teams, right? So if we could have a high level hypothesis at the portfolio level that basically says, look, we have constrained capacity on these high value teams, we have tons of capacity on the lower level teams, and what we have to do is we have to balance our portfolio to make sure that we’re not overloading the high value teams and we’re not assigning work. And I say low value teams but teams that are working on things that are not the highest priority or strategically aligned with the organization, right?

And so, what tends to happen and… see if I can do this again here so that I can move out of the way. This is where kind of these multilayered portfolio strategies kind of came in. So, you want to have, what I usually represent, is a Kanban-based governance model, right, up here at the top, right, that is pulling epics and effectively small projects, hopefully two to three months, right, because we want to batch size limit work in process, all that kind of stuff, right? You can even do things like gate one, gate two, gate three, gate four because there’s usually a Kanban-based type flow there, right?

Those things get kind of translated into a middle layer which I haven’t done this in a while but, provocatively, I put like analysis design, build, test, deploy kind of waterfall there. I have a funny story. One time I wrote this up in a blog post, probably pushing 10 years ago, I might have been at VersionOne at the time. And I provocatively titled that Kanban as just waterfall small batches. And David Anderson, the guy who invented Kanban, he tweeted or texted me, I can’t remember at the time. And he’s like, I want to be pissed at you when I read the title, but when I read your article, it was actually dead on, right?

Because it’s not a waterfall, right? It’s not big batch, it’s not big handoffs and things like that. But you can effectively take a feature and run it through an analysis, design, build, test, deploy Kanban without changing the organization structure at all. And just the smaller batches and limiting work in process in the different metrics will actually make workflow through the system more effectively. So, I think about epics is being decomposed into features, right? And then the result of the analysis and design comes down to your Scrum teams, right, and user stories.

So, let’s look at predictability at kind of a more global scale, right? To be predictable across the enterprise, what you need is you need an ability to look at the portfolio of work that’s coming in organizationally and make some hypotheses, right, make some guesses, make some assumptions, establish some constraints, that basically assert that the organization down here, right, based upon the predictable delivery and performance of those individual Scrum teams, right, because they become reliable delivery capacity now, right, based upon their predictable reliable delivery capacity, we can start making some bets about what the organization is capable of delivering.

So we align the portfolio level to the execution ability of lower level teams. But we know it’s not going to be perfect, right, because there’s going to be variation. There’s going to inevitably be cross-cutting concerns on things that we don’t anticipate. That’s where this middle tier comes up, right? So, this middle tier is going through kind of rolling wave planning, right, taking the highest value epics, decomposing them into features, right, decomposing them in a way that they’re scoped to be able to live within the higher level of constraint. And then decomposing those user stories out of the features and assigning them to the teams with the product owners, and basically making like feeding the system.

Dean Stevens called this, Feeding the Agile Beast, right? So it’s how do you feed the teams and align with strategy, right? So you have like a working group, like it’s decomposing work in real time based upon the capacity of the teams so that the teams are getting the right things, such that as they build it and it gets validated, there’s a steady flow of features coming out the backside. And as these features get delivered, there’s a steady flow of epics coming up this side, right? Very tactical, very mechanical explanation of the way a multitier architecture works.

But in the context of being predictable, there’s a couple of things at play, right? So, a predictable Agile enterprise absolutely demands predictable teams or else nothing else works, right, this doesn’t work, right. So that’s where we get into all the other things we are talking about over here in screen, right? All the things we talked about here, all of those rules still apply, but now we’re dealing with the conversation at scale. So now, we have a predictable substrate of Agile teams, we have to make sure that we are feeding those teams ready backlog. All those same rules apply, right, three to four to five sprints out, however many you need for a rolling wave.

And then to be able to make tradeoffs in those backlogs to balance where the constraints are across the teams. And then as those features are being delivered, we’re making tradeoffs at the feature level to make sure that we’re delivering the epic at the highest level. So let me tell you one of the things that I’ve kind of historically disagreed with, with Dean and the whole SAFe thing. And I’ve disagreed with him to his face. So if he happens to watch this or I doubt he’s on the call, but if he sees this at some point, I don’t think there’s anything that would throw him off in how I’m thinking about this.

One of the things that I think SAFe hasn’t done a particularly good job at, is talking about the architecture of the teams such that we create stable, reliable teams at this level. Now, don’t get me wrong. It’s absolutely implied. If you go back to your original Scrum material, absolutely implied. But in practice, I think, a lot of folks are not sitting on this as a fundamental building block, right? It’s like the encapsulation, orchestration, trust versus trustworthiness conversation we’re having a few weeks ago, right? So you absolutely sit on this.

The other thing that I think is a bit of a fallacy is that when you wrap this with PI planning, right, so we all get together with you big room for two days, right, two days, right, maybe to review kind of a thing. What’s implied if you’re running this in a Kanban is that there’s a limiting of a work in process and there’s a flow and a prioritization and a sequencing. So we might do a dependency map, right, in this level of planning, right. But the problem is, is that, again, in practice, it’s hard for me to distinguish what’s prescribed versus what’s intend versus what’s practiced sometimes, because a lot of it changes. But the idea is it’s almost like we’re all going to get together. We’re all going to do this two-day planning and then it’s kind of free for all. And then we come back here on the backside and [inaudible 00:48:13].

I think there’s kind of like two challenges with that, is I don’t think there’s enough feedback in here and I also don’t think that two days is enough to get everybody on the same page. I understand why we want to do it and I understand why it feels good, okay? But at a minimum, what I would want to do is I would want to have a background thread coming and this is what I advise SAFe teams on quite a bit because I want a background process running that basically says is that we are going to walk in to this meeting. And we are going to have every team with the dependency aware, backlog, groomed when I walk in.

And I would want to understand where most of those dependencies were in the system. And I would want to front load the dependency work earlier in the release. So that the things that are dependencies for other teams get resolved and dealt with early so that as I move later into the release, I have less worry about the nature of those dependencies or a late breaking dependency causing me problems, okay? But by the time you do that, in my opinion, right, my understanding which is probably less than perfect, is that you’ve kind of broken this framework to some degree and you’ve created a bit more of this framework.

So, often in early stage transformations, predictability is like the number one goal for us especially in an organization because a big part of the reason why you need to get predictable first, aside from the goal that organizations want you to be predictable, right, and that’s what the CEO cares about, that’s what they’re willing to fund and pay for. One of the things they’re willing to fund and pay for is it being predictable also builds trust with the organization. So we come and say, “Hey, we’re going to do Agile, it’s going to solve all your problems,” and then it’s chaos, right, it erodes trust.

If we can come in and start to use Scrum and Agile and Kanban and these metrics and methods and stabilize the system and get it really predictable right out of the gate, even in the presence of dependencies and teams that aren’t perfectly formed, we build a lot of trust with the organization. So, a lot of times, what we end up doing is we end up doing something like creating a working group at this level, I’ve called these things product owner teams in the past. And a big part of their job, maybe not a full time job, they’re not like a real Scrum team, they’re more like a Kanban team. Their job is to breakdown work and to validate completion in a continuous pattern.

And so, I like the idea of continuous backlog grooming, right, by a separate group of people that is punctuated with release plan. So, what that might look like in practice is I’ve got a team that’s continuously decomposing kind of through this analysis and design phase. And there’s like a little batch here in the Kanban where I’m queuing up a release worth of work. At the point that I have a release worth of work ready, all dependency aware, cross-cutting concern aware, load balance, all that stuff, right? Then I would bring it to a team during a two-day planning session and let them work out the fine-grained details.

All the work would be sequenced in the release so that the scary high dependency stuff is done early, the lower risk stuff is done late. That’s just good strategy to begin with. And then I reduce the risk. And so the release ends up being this build phase, but we’re probably going to loop between build and test, right, that would make sense, right? And then we get to the end of the release and we do a deploy, something like that, okay?

So, just real simple. We’re kind of run out of time here. And I’ll ask Tim if we have any questions. But like the two things, right, are at the team level, teams, backlogs, working tested of software, right? Absolutely a precondition for any sense of enterprise agility is to get team level agility right. And then once you get team level agility right, it’s really about balancing the portfolio and the decomposition processes to make sure that we’re exploiting the capacity of the delivery organization in a way that maximizes its ability to create flow.

And so if we have our portfolio items broken down into small pieces, and we have this group that’s breaking the portfolio things into program level features at a regular cadence, even if we’re cuing it up in a safe like world, right, we’re batching up releases and then we’re going into like a big room, big release planning, totally fine, right? I just prescribed something that’s before and after that, right? It’s okay, right? I call it safe plus sometimes, right, because in the presence of dependencies and more complicated environments, sometimes you need a little bit more, cool, right?

But these processes up here are what is going to basically establish flow at the enterprise level and, again, exploiting the flow at the team model. And if these two aspects of the system are not working in tandem, we don’t actually get the predictability that we want. And then I’ll just kind of put a dot on it and we’ll call it done here. But it’s like you can be predictable and perfect at your Scrum team level and the organization sees no predictability and value at the enterprise level because you didn’t build the structures in place to make sure that the system was getting fed in a way they basically kind of funneled everything through from an early release perspective, okay?

So predictability, super important. It builds trust, executives want it, they’re willing to pay for it. If you guys can show them how Agile is solving that problem for them, right, and the things that they need to do, you make a really strong case for transformation, okay. And so, hopefully, that’s what you guys got out of this.

Tim, any questions that would be kind of a quick hit before we wrap?

Yeah. I think you touched on this probably a bit but somebody asked about, it’s a dependency related question. They said, what if my team is doing Scrum and dependent on other teams who are waterfall?

Yeah. Well, that’s a tough thing, right? So, that’s a more advanced organizational design question, right? But you have to realize that when you take something that’s really fast, right, design to be really fast, and you mix it with something that’s really slow, right, you’re going to end up somewhere in between. Okay. We see this a lot, right?

So we’ve had historically a lot of financial services customers, a lot of manufacturing customers and pharmaceuticals right now. But like in financial services, that’s kind of where I grew up was, you would end up like big mainframe stuff that’s kind of doing waterfall or you’d have like clients, integration partners that were waterfall, you need to have this really cool front-end team, right?

And so what you tend to try to do is to get the waterfall teams to work in slightly smaller batches, maybe it’s like three, four months’ batches instead of 18-month batches, so you try to compress them a little bit. And you also try to get them to publish roadmaps because waterfalls never like perfectly waterfall. There’s usually some increment in iteration in there. And then what you end up with doing is that the Agile teams end up going fast within that but then there’s sync points along the way, right?

There’s some strategy around that but there’s just no world in which if you’re building an integrated product with Agile teams and waterfall teams that you’re going to get the release performance and the predictability and everything that you would have if you had a full blown Agile organization. It just not going to happen, right? Again, fast stuff and slow stuff. It’s a little bit like where I talked about is like predictable stuff and unpredictable stuff is going to, you’re going to end up someplace in the middle, is what it comes down to.

Awesome. Well, thanks, guys. I appreciate everybody who joined us. And we’ll see you next week.