Fowler: "Agile Imposition is a Very Red Flag"

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?

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?

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.

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.

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.

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.

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

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?

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."

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!