Fowler: "Agile Imposition is a Very Red Flag"

by Deborah Hartmann Preuss on Oct 10, 2006 |

Martin Fowler, one of the original creators of the Agile Manifesto in 2001, reflected last week on reports of agile process being imposed on teams from the outside. He states his reaction succinctly: "Imposing a process on a team is completely opposed to the principles of agile software, and has been since its inception."

Fowler goes on to look in detail at the principles underlying Agile culture, including its emphasis on "motivated individuals" and "self-organizing teams." His conclusion:

An important consequence of these values and principles is that a team should choose its own process - one that suits the people and context in which they work.

Fowler insists that imposing a process on a team is "a very red flag," but warns that from the outside it may not be possible to tell exactly what's going on - he says, "There are situations that may look similar from the outside, but aren't really the same." For example, he notes that the temporary imposition of a set of practices for the purpose of learning should not be assumed to indicate permanent imposition of those practices. Fowler states, "it's very difficult to tailor a process until you've used it for a while." He wrote about this in an earlier article on Extreme Programming - in which he identifies three levels of process maturity, where his "Level 1" corresponds to Alistair Cockburn's "Shu" stage (a concept drawn from the martial art, Aikido, and one which Fowler also uses). In this stage, particularly for XP, it's widely agreed that teams need to use the practices "as is" for a while, to understand the basic patterns before customizing them to suit their own situation.

So, it may take a little investigation before determining whether process is being imposed, but the fundamental point remains - imposing agile methods introduces a conflict with the values and principles that underlie agile methods.

Related Editorial

10 Key Guide Points for Continuous Delivery

How do you Develop a Shared Understanding on an Agile project?

Continuous Delivery: A Maturity Assessment Model

How do you estimate on an Agile project?

Agile Executive Primer: Partnering Across the Organization

Related Sponsor

Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

Catch 22: non-agile and pre-Shu individuals by Junilu Lacar Posted

Re: Catch 22: non-agile and pre-Shu individuals by Deborah Hartmann Posted

Re: Catch 22: non-agile and pre-Shu individuals by Junilu Lacar Posted

Re: Catch 22: non-agile and pre-Shu individuals by William Pietri Posted

Re: Catch 22: non-agile and pre-Shu individuals by Junilu Lacar Posted

Re: Catch 22: non-agile and pre-Shu individuals by William Pietri Posted

Re: Catch 22: non-agile and pre-Shu individuals by Junilu Lacar Posted

Levels of imposition? by jared richardson Posted

Re: Levels of imposition? by Junilu Lacar Posted

Is Imposition Sometimes Required? by Chris Gardner Posted

Catch 22: non-agile and pre-Shu individuals by Junilu Lacar

From my experience in trying to get the teams I have worked with to go agile, I see the truth in what Fowler says. However, the reality is that you can't always build your projects around the ideal: motivated individuals and self-organizing teams. The inertia of old habits can be very hard to overcome. More often than not, non-agile teams will tend to keep following their non-agile ways and they will most likely never get around to going agile unless somebody forges the way and starts imposing agile practices and processes on them. These kinds of teams seem to be still in the majority in the rest of the world. Is there no hope then for the 80% of developers who do not belong to the 20% most productive teams?

As a student of Aikido, I too have been through the Shu stage of learning (still am). It takes a while to get used to doing things differently. Just as it takes a while to get used to entering into an attack instead of backing off from it, it takes a while for developers to get the hang of Test-Driven Development. And for the longest time, I could not bring myself to relax and receive the force of an attack rather than tense up and try to go against it. Many developers have the same kind of difficulty when trying to learn agile practices. It makes people uncomfortable to have to abandon old but familiar habits and adapt to a new style of development.

Students in the Shu stage of learning have form imposed on them by the instructor. What other option besides imposition do you have then to try to overcome the inertia of old habits and get developers rolling with the agile way of doing things?

Re: Catch 22: non-agile and pre-Shu individuals by Deborah Hartmann

I guess, for me the question is: was the instructor invited? or imposed? Once the instructor is there, yes, they need to deal with the "shu" phase as they see fit.

Can an entire IT organization, right down to developers and testers, "invite" the instructor?

Re: Catch 22: non-agile and pre-Shu individuals by Junilu Lacar

Teams are usually aware that they are not doing things the best way. Most folks will say "Yeah, that's good. I wish we did more unit testing, continuous integration, yada yada." They're all about improving the process. At least on paper. But when you start asking them to do unit testing, attend daily scrums, giving updates on their tasks and other things agile, the old habits start to drag them down.

When students of Aikido go to class, they expect the instructor to have a system of instruction that structures the learning of techniques. In football, coaches have their "systems". Same thing with agile. With most teams, expecting them to self-organize and continue to improve is just not realistic, especially if they've never been agile before. So, even if they did "invite" the instructor and say that they buy-in to the "system", there often needs to be a certain degree of imposition to help developers overcome the drag of old habits.

Levels of imposition? by jared richardson

I've imposed Agile practices on a team before, but I was the tech lead, working alongside the team. That strikes me as different than a manager reading an article about Agile and then sending a memo to some team they aren't familiar with and demanding Agile adoption.

I like the martial arts instructor analogy. It's very good. The teacher was invited, and expected to teach. That doesn't make it fun 100% of the time. :) But you stay because you want to learn and get better.

I've also introduced Agile practices to an organization by simply using them and letting others see how effective they were. Then you get others coming to you, asking you to help them use the practices. That's a great way to go "gradual agile". Introduction via grassroots.

Re: Levels of imposition? by Junilu Lacar

True, imposition of agile by management, which is what Fowler talks about, is different and less likely to succeed than if it comes from a tech lead. However, tech leads are still often regarded as being a kind of "manager". And while the grassroots route may be a good way to introduce agile, it still does not eliminate the need to overcome that initial drag (I prefer to call it that rather than "resistance" because folks are willing enough, it's just that the old habits are hard to shake).

Take for example an incident that happened to me recently. One guy on my team was asking some questions about debugging, tracing, and logging. After talking about the different ways he could go about doing that, I mentioned an alternative: that writing unit tests really helped to cut down on debugging time. "Yeah, you're really good at that." was his reply which had the distinct ring of "Yeah, it works great for you but I'm going to do it this way because that's what I'm comfortable with." I had spent some time with him doing test-first programming a few days before and his reply surprised me in a way, and yet I suspect it is fairly typical.

Re: Catch 22: non-agile and pre-Shu individuals by William Pietri

Who is forcing you to go to Aikido class? My guess is nobody; you go because you think it will benefit you. Do you think it would benefit you as much if your boss ordered you to go and implied he'd fire you if you didn't?

The alternative to imposing agile methods is to persuading people that agile methods will solve some problem that is bothering them. For me, that works much better.

Is Imposition Sometimes Required? by Chris Gardner

Perhaps there is sometimes a need to impose. Here's my take: cgardner.blogspot.com/#imposingagile

Re: Catch 22: non-agile and pre-Shu individuals by Junilu Lacar

You're right, I go to class because I want to. But then other concerns of life make it hard to go as often as I want/should and I start missing classes. Same thing for agile adaption. When the going gets tough on a project and pressure mounts, adherence to agile practices often suffers, even though the team members know that doing so adds to their pain. In many ways agile is like dieting or quitting smoking: you know it's good for you but some find it easier to fall back on old ways than to stick with the program. Isn't this where management should start imposing on the team?

Re: Catch 22: non-agile and pre-Shu individuals by William Pietri

Isn't this where management should start imposing on the team?>

In my opinion, no.

Instead, I think management should ask why it is hard for them to do the right thing and aid them. And it's best if the manager does that in a way that moves toward great agility. For example, if the going is tough and the pressure is mounting, the manager should make use of the planning game and yesterday's weather to make the team's workload fit the amount of time available.

I think the only effective time for a manager to pressure the team on agile practices is when the team comes to them and says, "We really want to keep testing; please remind us when we forget."

Re: Catch 22: non-agile and pre-Shu individuals by Junilu Lacar

Instead, I think management should ask why it is hard for them to do the right thing and aid them

That makes a lot of sense. And it's also a very Aiki way of approaching the situation: instead of trying to forcefully impose your will, you make a connection and gently guide the issue to a harmonious resolution. You'd think I would have learned that by now <g>. Thanks!