Mandated Agile - A Contrarian View

There was an interesting exchange recently on Twitter about Agile adoptions/transformations that are mandated. Dan Mezick asserted that:
Between 75% and 85% of all #agile adoptions fail to last. 99% of these adoptions are implemented as mandates. Any connection here?
I responded, asking for Dan's source to those stats. His answer was that it was "pro coaches" like myself. What ensued was a long conversation (such as one can have on Twitter) including people such as Mike Cottmeyer, George Dinwiddie, Glenn Waters and others.

Dan's position is that mandated Agile doesn't work, and his Open Space-flavoured version called Open Agile Adoption is much more inclusive and grassroots-driven.

Just to be clear, I have no arguments against Open Agile Adoption and I'm a big fan of Open Space and how it can be used to ensure that many more people are engaged in the work process. There are a couple of things, though, that bother me about Dan's statements.

First, even if his statistics are accurate, I want to see that his sources are somewhat more rigorous than anecdotes from other coaches. Laurent Bossavit has made a side career for himself of challenging statements such as Dan's, with much of what he's found catalogued in his book The Leprechauns of Software Engineering. I'm not suggesting that Dan's numbers are wrong, just that if he's using them to market his own product or service then it behooves him to "show his work", as a multitude of math teachers and profs told me.

My second issue is with the implication mandated Agile is wrong. Of course it would be better if a change such as that began and grew from the grassroots rather than as an imposition from management. Except... I was among the many who had great success with XP in the early 2000's on a single team, but precious little if any success trying to grow it beyond that point. Forget about management, other teams simply weren't interested, regardless of how successful we were.

There's also another funny aspect to this. If I'm working for a private company and the owner wants something done a certain way, it's absolutely her prerogative to do so! If the head honcho wants Agile and says, "Make it so!", then you're faced with a choice: you either work with the owner to make it so, or you can choose to leave.

While that view doesn't fit the mold of how we believe organizations should be run, it is how 99% of them are. OK, so I just grabbed that number out of the air. :) My experience has been invariably that this is how organizations are managed, for better or for worse.

We hear about the Semco's and the Gore and Associates of the world because they're so different, not because many other organizations are like them. Of course we should take lessons from those companies and apply them! But we also have to be wary of cargo-culting such as was done with the North American auto makers with Toyota's manufacturing model.

In the end, though, most businesses are not a democracy. Good ones are a benevolent dictatorship, and the leaders in those companies are much more inclusive of others in the decision making process. The people in those organizations feel valued and are motivated to do great things.

But even in those companies, every so often decisions are made by the top leadership without consulting the masses. Those decisions affect everyone, and are imposed via a mandate. If the people trust that the organization's leadership is making these decisions for solid business reasons, then there really isn't a problem. If the leadership communicates those reasons and the vision behind the change, then the people on whom this mandate has been imposed are much more likely to support it.

Not all mandates are bad, and some are necessary. Creating such a false dichotomy serves no one in the long term.

Since I've now given Dan's Open Agile Adoption some free advertising, I would like to state that my own position is to help groups determine what is most effective in their context. The definition of effective will change from team to team, even within the same organization. It will also change from domain to domain. I have accumulated a lot of great principles and practices in 25+ years, as well as the wisdom to know that "one size fits all" means "it doesn't fit anyone properly". If you think that's interesting, come on over to DaveRooney.ca to see how I can help.


Comments

Well said, Dave. There are many paths to organizational change, and all of them are hard. They're hard because there are so many people involved.

Sure you can mandate a certain way of doing things, and people will look like they're doing it that way. This may be enough for some changes, but I don't think it's going to give you what you want in terms of Agile Software Development.

Effective change usually involves leadership rather than bossing people around. It's important to get people "on board" with the change, so they're doing the new thing in earnest, instead of going through the motions.

If Open Agile Adoption is working for Dan, that's fine. I wonder, though, who mandated the decision to try Open Agile Adoption in the organization? Or was that chosen by all the members of the organization?
Daniel Mezick said…
Dave, thanks for posting your essay. The 15%/25% success number comes from pro coaches like yourself. I'm happy to name the names after I get authorization from each of them.

Open Agile Adoption (OAA) does allow for a mandated Agile direction. Naming a vision and the general direction to get there is a function of leadership. Where OAA draws the line is at the mandate of specific Agile practices. OAA is intolerant of that from leadership, and OAA practitioners will decline any offer to be part of that.

Having said this, it must be pointed out that a OAA practitioner challenge leadership, to explain "the why" of the Agile direction to the entire tribe. "Start with Why" as Simon Sinek's popular book suggests.

Agile adoptions are very triggering for people at all levels of authorization inside the company. A core intent to the OAA approach is to reduce triggering worries, fears and concerns, so the adoption can take root in a rapid and lasting way.

Thanks again for your fine essay. I look forward to much more dialogue around the ideas you share here.

Daniel
http://www.DanielMezick.com








Paul Boos said…
In my experience, you need both grass roots motivation AND executive support to be successful. Introducing the vision and ideas for practices from the top down can work IMHO (or from any direction), it just takes effort so that the originator is a catalyst and not a dictator. As a catalyst, the originator needs to needs to help co-create the adoption (for specific practices) and/or the vision for the larger transformation, help find ways to replace old organizational habits that don't support the change, and be mindful of how much change is being undertaken at a specific time so as to not overburden the system.

In general I see assumptions on each side of this 'argument' and feel the best comes from somewhere in the middle.

I unfortunately don't have time to create a more detailed comment at the moment, but I will try and post a more thorough response in the near future.

My final item to leave you is a simple expression around how a vision is transmitted to the audience...

co-creation > clear communication > mandate

Cheers,
Paul
Daniel Mezick said…
Co-creation is exactly what the Open Agile Adoption (OAA) approach is all about. That's how it works.

It demands something of formally authorized leadership (this is the "top-down").

To the tribe, the OAA process signals the emergence of certain values, and an emergently possible and new culture of openness, courage and respect. This is achieved via the Open Space events, the storytelling and in fact the entire OAA process (this is the "bottom-up")

Open Agile Adoption is social technology designed to help the top-down and bottom-up happen in a natural way that is frequently inspected and thus, co-created by participants at every level of authorization.

Co-created emergence is the name of the game with OAA.


See also: ON COMMUNITAS
http://newtechusa.net/agile/on-communitas/