How to Get the Most Out of Your Agile Methodology

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

Video Transcript

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

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

(Musical Interlude)

Defining an Agile Team

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

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

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

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

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

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

When You Can’t Form Agile Teams

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

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

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

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

How to Get the Business Benefits of Agile

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

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

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

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

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

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

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

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

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

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

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

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