Organizational Change Starts with Teams, Backlogs, and Working Tested Product

Agile transformation can feel like an uphill battle, especially when frameworks and processes overshadow the foundational principles of the Agile Manifesto. In this video, we explore why the industry’s common applications of Agile often fall short and how the focus on culture or process misses the mark without the right conditions. With 23 years of Agile history as context, we discuss the original intent behind Agile practices, the challenges of scaling them in complex environments, and the critical importance of creating cross-functional teams, clear backlogs, and working software. If you’re an Agile leader striving to align principles with practical outcomes, this discussion will inspire new ways to think about agility in your organization.

Video Transcript

There’s people out there that are struggling to adopt Agile. There’s people that think Agile is a process. When I do see things online, I’m looking for hopes that people understand this problem, that the industry is starting to wake up to it. And what we’re starting to see is that I think the Agile community is doubling down on the same things. There was an article I read a couple weeks ago, I want to say it was on scrum.org or something, but I don’t remember. And it was around this idea that frameworks are not the answer, but then it went right back to its mindset and principles. It’s the same stuff, right? It’s an encapsulation orchestration problem. It’s almost like you want to start and you want to have, okay, what is the current state of Agile? Where are we at? Right? So we’re 20 years into this thing.

We’re 20 years into the Agile movement, maybe longer. I guess it was signed in what, 2001 or no? Yeah, 2001. So we’re sitting here 23 years post signing of the Agile Manifesto. We have a community in this that I think is dwindling right now. And what I think the industry is starting to recognize is that the way Agile, as it’s commonly applied, is not working. We started this movement with the Agile Manifesto and it got a lot of traction really fast. The way that I’ve talked about this in the past is that when I think about the history of Agile, when I think about how it kind of grew up, don’t have firsthand information, just from reading stories and talking to people that signed the manifesto, it was like what we recognize was that big upfront plans were not solving the problem.

We recognized that incremental and iterative delivery was likely the way to go. My perception of the early days of Agile is nobody really set out and said, okay, let’s figure out how to build a new product from scratch in a large complex organization on top of a legacy monolith that was moved to the cloud that had really complicated data architectures and such, what they were largely doing was something was within the scope of 5, 6, 7 people. They had easy access to customers, they were able to everybody get in the same room. And there was an implicit part of it. It was like you get everybody in the same room, you put a customer in the room, you have Alistair Coburn’s idea of osmotic communication. Everybody hears everything that’s going on, and you can continuously deploy the software. You can continuously get feedback, you can inspect and adapt and change as you learn things.

And so where we started this conversation was around the idea that if we could create those conditions, then we could deliver greater business value faster. And the way that the story played out over the last 23 years was probably twofold. There was an aspect of our community that was largely, I dunno, victimized is the word I want to use, but it’s probably not the right word. They felt on the receiving end of a lot of management practices that didn’t make sense. They were not able to do the software craftsmanship kinds of things in the software because they’re under such crushing date and time pressure. There was this huge pressure to define all the requirements upfront and get sign off on ’em.

And so what kind of happened is that when the manifesto came out, it was a set of values and principles. And so it prioritized for things like a responding to change over, following a plan, customer collaboration over contract negotiation, stuff like that. And over the last 23 years, I think there’s really two camps that evolved out of this. I think that the one camp really indexed on what I might say, the cultural ethos of Agile, where it was about teaming and strategy and fun and games, very high touch, very high collaboration. And then the other side of the industry went to processes and frameworks. And when Jim Cundiff was the managing director of the Scrum Alliance and partnered with PMI, which ultimately led to the PMI Agile certification, what really Jim did is he caused the scrum training stuff to take off. And Scrum is an interesting thing because it’s really kind of a hybrid of a cultural ethos and a process or a methodology.

And so in that ethos, you have roles and responsibilities, you have ways you measure things. You have daily standups, you have reviews and retrospectives, you have sprint planning meetings and such. Mike Cohn came out with the Agile Estimating and Planning book and really put some structure and discipline around how we’re going to break down user stories, how we’re going to measure velocity, how we’re going to do release planning, such like that. And it gave this illusion in some ways that it was a thing. And that thing were pretty clear works when you have the conditions created to make that thing work. And those conditions are largely fairly simple.

And those conditions are, can I form a complete cross-functional team that stays together? Can that team operate off of a finely grained, well articulated backlog? And can that team produce a working tested increment of software? It’s what leading Agile we talk about is the three things. It’s like these three things must be true or else nothing else in Agile is really going to work. In the absence of those three things, what it’s really difficult to do is to create a teaming strategy that actually produces working tested software at the end of every sprint. It’s really hard to create a team that can establish a stable velocity. It’s really hard to operate off of a known backlog and be predictable at the end of every sprint. And I think what we’re seeing in the industry right now is that in the absence of those three things, we’re doing one or two things, depending upon which camp we’re in. We’re either indexing on process or we are over indexing on culture.