The LeadingAgile Transformation Manifesto
I’ve been noodling around on how to distill the LeadingAgile perspective on agile transformation down to its most non-negotiable core. I thought it might be fun to write up a manifesto to guide thinking around transformation.
The LeadingAgile Transformation Manifesto
Agile transformation is about systematically creating an environment for agile to thrive in your organization.
At the delivery level, agile is about forming teams, building backlogs, and producing working tested increments of product.
At the enterprise level, agile is about team-based organizations, adaptive governance, and metrics that support the flow of value.
Anything that prevents you from doing these things, either at the delivery level or across the enterprise, is an impediment that must be removed.
Of course, this is a tightly packed description.
It doesn’t say anything about the attributes of an environment where agile can thrive, or the nature of an agile team, a description of a backlog, or even what it means to produce a working tested increment of product.
It doesn’t describe anything about what it means to form a team-based organization, to apply adaptive governance, or the nature and form of metrics that support measuring the flow of value.
It doesn’t describe the kinds of things that will inevitably get in the way of forming teams, building backlogs, or producing working tested increments.
It doesn’t describe the kinds of things that will inevitably get in the way of forming team-based organizations, applying adaptive governance, or installing metrics that support measuring the flow of value.
It doesn’t say anything about installing Product Owners or ScrumMasters or what kind of training you need to do, or what to do about culture, or what to do about the people that don’t seem to want to get on board.
The point is… if you form teams, build backlogs, and produce working tested software… and you remove all the impediments… whatever they happen to be… I believe everything else will take care of itself with minimal effort.
At scale… if you form team-based organizations, use lean/kanban-based adaptive governance, and install healthy metrics which promote the flow of value into the marketplace… everything else will take care of itself with minimal effort.
In the absence of this minimal subset, nothing we do works.
In the presence of this minimal subset, nothing much else matters.
So… you’re job in leading an agile transformation is to create an environment where agile can thrive. Your job is to form teams, build backlogs, and produce working tested software. Your job is to create team-based organizations, apply adaptive governance, and install metrics that promote the flow of value.
Anything that gets in the way is an impediment to transformation.
Anything else is vanity and won’t make any difference at all.
Comments (5)
Bob Allen
I LIKE it, a LOT. There is one thing that you might consider polishing: “…, build backlogs, …”
This one part strikes me as too open to being mangled. I honesty don’t know the BEST way to rephrase it, but something like “.., build backlogs as they are needed, ..”.
The likelihood of someone interpreting the given phrasing as just another way to define (and size) all requirements up front (waterfall with Agile varnish) is too great.
Adam Yuret
“Working, tested, increments of valuable capabilities.” perhaps. While I can agree that the way most enterprise organizations currently operate building and testing anything on a regular basis is a step up, I don’t think the purpose of a software organization is to create volume of software. More software misses the point that customers desire outcomes. Sometimes served by less software E.G.”your product has so many useless features it’s hard for me to do the things I care about.” is not an uncommon customer complaint. Hyperproductivity of product output is not the point. Not saying you’re promoting that, but it’d be easy to read “working tested increments of product.” as an outcome. It’s an activity, which could result in a desirable customer outcome or not.
I look forward to watching this manifesto evolve and the incite discussion about what matters in making the future of work a better place for people while delighting customers.
Thanks Adam. My next pass I’ll probably define my terms… explode the model a little… and see if that leads to any deeper insights. For the folks we work with… I’m trying to make it so super clear what we are trying to do. I get generally frustrated at our collective faith that process is going to solve the problem, when it’s fundamentally the organizational impediments that are getting in the way. I’m trying to be so clear and so explicit about that. To make the tightest inarguable point I can. Thanks for your feedback.
Adam Yuret
Definition is a hard problem to solve, especially without context and in text.
Ultimately there are things which will help any organization to significantly improve their effectiveness (optimizing for flow of value delivered vs. effort at a given time expended, visualization of impediments and throughput, agency to make meaningful decisions without permission from the hierarchy, etc. ) but once you write down detailed framework and include practices you open yourself up to lizard brains everywhere seeking to find fault of an example where something in the framework would’ve failed or exacerbated an existing problem.
Not saying it’s an unworthy endeavor, just it’s a very hard one. Arguably the careful prescription of Scrum is what led to it’s ultimate monetization and loss of the original message which I believe was “We’re in a complex world and will only thrive if we work as empowered teams to respond to the changes which we shall inevitably encounter.” or something. ;-)
Best of luck, I’ll be keenly observing.
Thats part of my point. When we write down detailed processes, people focus on the process and not the preconditions required to make that process effective. I’m just super focused on the preconditions. I find in practice that when you take all the noise out of the system, if you don’t do these three things you fail. If you do them, while not a guarantee of success, you have a shot. Some of the things you explicitly call out would be imbedded in my definition of a healthy team, healthy backlog, and a healthy iterative and incremental deliverable. Thanks for the comment Adam!