Adopting Agile Practices Isn’t Agile Transformation
Agile needs to be tied to business-driven results. If not, then we start measuring things like people trained, teams doing Scrum, or the organization’s sentiment toward Agile to tell us if we’re succeeding. But, in the absence of measurable business results, none of that matters. Agile is all about the ability of an organization to deliver in small batches, get fast feedback from customers, and quickly respond to change. If your Agile isn’t helping you do that, then it’s not really Agile at all.
Video Transcript
There are many people at the practitioner level who think Agile is about social aspects like engagement, interaction, and joy at work. While these aspects are important, they need to be linked to business outcomes. This brings me back to the topic I frequently discuss.
Whenever we witness Agile practices not working or see an engaged team that loves their work but still feels like they are failing, it always comes down to three fundamental factors. First, how are we forming teams? Second, how are we building backlogs? Third, how are we reproducing working tests in software? Additionally, we need to consider how we organize teams in the presence of dependencies, how we orchestrate and govern those dependencies, and what we measure and control around the team.
(Musical Interlude)
The Ultimate Success Criteria of Doing Agile
Over the past 13 years of running leading Agile, we often receive an intriguing phone call. The caller will say something like, “We’ve adopted Scrum, SAFe, or LeSS, but we’re not getting the desired business benefits from it.” This leads to a thought-provoking question: what does it mean to be doing Scrum well and still not achieving the desired results? When people make such statements, they usually mean that they have trained product owners and a proficient Scrum master, and their team consistently follows the cadence of sprint planning, daily stand-ups, interviews, and retrospectives. They may also be writing user stories, using burn-down charts, and practicing agile estimating and planning. Despite having the roles, responsibilities, ceremonies, and artifacts in place, they find that it’s not really working.
This creates cognitive dissonance for me. I question why they would implement a process that doesn’t yield the desired business benefits. It leads me to ponder what makes it challenging to achieve the business benefits of Scrum when they are indeed practicing Scrum. This dichotomy and separation of concerns often arise in conversations about Agile. Sometimes, I emphasize the importance of culture in an Agile ecosystem.
Certain individuals strongly believe that Agile is primarily about collaboration, team interaction, behavior, and how the team feels. While these aspects are indeed significant, I frequently emphasize that they are just a part of it. We also need to define the acceptance criteria of Agile. What is the acceptance criteria for Scrum? What is the acceptance criteria for SAFe? How can the business determine if it’s working?
The way I perceive it is that the business can gauge Agile’s success if the teams consistently and predictably release market-ready products in short cycles and regular intervals. These products should have well-architected, well-tested, defect-free code. The teams should effectively utilize their capacity, create opportunities for innovation based on new information, and build products in collaboration with customers to ensure the right products are being developed. Every businessperson I’ve spoken to considers this the ultimate measure of Agile’s success.
Some companies aim to engage their employees, modernize their methodologies, or improve their net promoter scores. They put effort into creating open and collaborative workspaces. While high net promoter scores and collaborative workspaces are beneficial, they are truly valuable when coupled with the ability to meet commitments to clients, receive regular feedback, deliver excellent products on time, operate within a reasonable and agreed-upon cost profile, build the right products, and disrupt the market.
The Problem with Going Through the Motions of Agile
When people ask such questions, they usually mean that they are going through the motions of Agile. They conduct Scrum ceremonies, have the Scrum roles and artifacts, or follow the Scaled Agile Framework (SAFe). They believe or have been told that by doing these things, they will achieve the desired outcomes. Unpacking this problem is intriguing as it delves into human nature. It’s similar to other significant topics such as religion, politics, or countries. Initially, these topics are vast and abstract, but underneath the surface lie scientific principles and thinking patterns that underpin agile methodologies.
Over the past 20 to 25 years, I’ve come across various books and resources that I believe people should read. The interesting aspect is that the early thinkers in the agile space were focused on uncovering the underlying theory of agile software development. Over time, these theories were transformed into practices, taught, and certified. However, as time passes, people tend to remember what they were told to do without necessarily understanding the reasons behind it. When you engage in practices without grasping the underlying theory, you may be led to believe that it’s solely the practice itself that generates results.
That could be that what you’re thinking or the other. The other challenge could be is that you’re doing the things that worked in one context, but because you don’t understand the theory or the underlying thinking, you don’t know how to adapt those practices to a new context. And so I think the challenge they were having in the Agile community right now and candidly for the last 20 years is that is that as certification took off and as interest gained, there’s a lot of folks that know the Agile stuff and they know the Agile words, but they’re not getting the business agility that they want out of that.
And because they’ve detached from the outcomes, a lot of times what they’ll do instead is attach to the practices or how those practices make them feel on the account.
Creating an Agile Culture vs Achieving Business Benefits
So sometimes people will tell me things like, Yeah, we’re doing Scrum really well, daily standards, reviews, retrospectives. We have a Scrum master, we have a product owner and the team really, really likes working this way and that’s a great thing, right? We want the team to like the way that they work. But if the methodology and the team’s engagement and happiness being at work doesn’t produce results that the business can rely upon, then then we’re kind of lost. And, you know, it’s interesting, right? I mean, I’ve been saying these messages for a long time in the marketplace, and I think a lot of people get it.
But I’ve gotten out recently and we’ve done some talks were up at Agile and beyond up in Detroit. We were at the TriAgile Conference in North Carolina talking about like the role of culture versus practices versus structure, things, you know, the things that I talk about a lot. And I still think just a lot of people at the practitioner level in particular, they think Agile is about these, you know, I guess like social Aspen folks, right?
The engagement, the interaction, the people, the joy at work and all of those things. And again, all that stuff is really important, but it has to be attached to the business outcomes. Which leads me back to the thing that I talk about all the time. Every time we see the practices of Agile not working, every time we see a really engaged team that loves what they’re doing, but yet still feels like they’re failing, it always comes down to those basic three things, right?
How are we forming teams? How are we building backlogs? How we’re producing working tested software, how are we organizing teams in the presence of dependencies? How are we orchestrating and governing those dependencies? And what are we measuring and controlling around the team?
Getting Your Agile Teams to Be Agile
And it’s our belief that you, if you want your agile teams to really result in business agility, like we actually want our Agile teams to be agile, then we have to create the conditions for those teams to be agile; decoupled teams of 6 to 8 people operating off of really clean, well-articulated estimated backlogs with the technical capabilities, the release capabilities to produce working texts that are increments of software at the end of every sprint.
And the challenges is that is that the you’re agile will never really result in agility if you’re not able to create those conditions. And so, Agile Transformation really becomes about the idea of understanding the constraints of the current environment, what kinds of things do we need to do now? How might we adapt our methodologies and what compensating controls do we need to put in place while we change the underlying conditions in the organization so that we can create the conditions to actually achieve agility?
Walking in with a two-day certification or a one-week SAFe certification, even lots of certifications and not knowing how to adapt those certifications into the current reality, or believing that doing those practices is going to create meaningful change is really causing a lot of problems in our industry right now. And so it always comes down to is that every methodology was designed to work in a particular ecosystem and the active transformation is not to introduce practices or tell people that they need to behave or think or feel differently.
Transformation is about meaningful change. It’s about changing the organization in a way that that enables or allows for agility to happen. And then we enable and support that agility with solid practices and good discipline and behavior. And then all of that great teamwork and everything and all that culture emerges out of that. And that’s the way it works when it works, right?
And and, you know, sometimes, you know, if you’re in a small work group, you start doing Scrum like everything’s really clear. You’re in a big organization and you’re a small team and you don’t have a lot of dependencies. But in the presence of dependencies, right, in the presence of a lot of organizational dysfunction, in the presence of legacy monoliths, in the presence of technology architectures and organizational architectures that don’t lend themselves to Agile.
Agile is not going to do a whole lot for you. It will actually cause you problems. So what we do at leading Agile, right, is we figure out where you are and where you want to be and help craft a very structured, disciplined, outcomes based, performance based transformation strategy. So that over time you can achieve the business benefits because that at the end of the day is what we’re after.
We want great teams, we want positive work environments. I’m a huge advocate of Scrum, huge advocacy. I think those methodologies can work and I think they do work quite often, but they only ever work when we’re creating the conditions for them to work. And that’s the difference between adopting agile practices and doing an Agile transformation. Transformation is about changing the underlying organizational design, governance metrics, strategies, right, that are going to lead to true Business Agility.
The same principle applies when considering cloud migration or digital transformation. It also holds true for concepts like a composable enterprise, domain-driven design, and a business capability-aligned organization. There is a convergence of thinking around the idea that big things need to be broken down into smaller components with minimal dependencies. In the presence of dependencies, it becomes necessary to address and coordinate them. Over time, the goal is to reduce dependencies, allowing teams to operate with greater autonomy. This is the underlying physics of the situation.
I strongly encourage everyone to reflect on this concept. Although not everyone may have the authority to make significant changes within their organization, I often ask individuals what they would do differently if they had the opportunity. By looking beyond the current constraints, you can begin to envision the changes that would make a difference. When you hold a leadership position and have the agency to drive change, you will possess the knowledge required to make a substantial impact.
Even if you’re not currently in such a position, you can still be an advocate for adapting Agile practices to make them effective, rather than rigidly adhering to prescribed methods without fully understanding how they should be applied. The key question to ask is, “How agile is your Agile?” If the Agile methodologies you have adopted are not enhancing your business agility or enabling you to achieve your goals, there is a way to address it. There is a plan available, which you can explore on our website or by reading our white paper. It’s not a secret; it can be accomplished.
That’s what I wanted to share with you today. If you have any questions, please reach out to us through our website’s contact page. We are always happy to assist you.