You raise an interesting point: agile crowd is loud indeed and people we consider though-leaders lead the agile bandwagon. However if look for alter-agile voices count me in. I don’t say “agile is good, no matter what.” You won’t hear me praising any specific agile method as a silver bullet. I won’t say Kanban is the best even though I use it now and in this specific situation it works great.

And talking about that: I’m very far from merging best software engineering practices with agile approach to manage projects. Almost none of practices we consider today as agile were invented along with agile methodologies. I used automatic tests before I even heard about agile. I was refactoring the code when I worked with old-school PM methods.

I’ll give you a good example – you’ve read “Code Complete” written by Steve McConnell almost for sure. Most of engineering practices you have in your toolbox today is described there. The book was written long before agile has launched. Does it mean Steve’s ideas didn’t work back then?

People wrote, and are writing, great code in non-agile projects all the time. Agile and good code aren’t bonded.

I don’t say people should just ignore authorities or thought-leaders. If someone uses “they don’t work here” argument just to ignore advice which otherwise would be good that’s a problem of defending status quo.

I don’t say though-leaders know nothing either. As you write they know a lot, otherwise we wouldn’t care about them. It’s just we should choose a right perspective to look at what they bring to us.

I neither share over-skeptical nor uncritical approach. Both are quite popular. We came to the point where skeptics usually find adversaries and discussion about changes in their organizations is in this way or another ongoing. On the other hand I often see people spreading the word about new cool thing telling you how great it is without even one thought about specific of their audience.

What drove me even more to write this is hearing one of thought leaders using from time to time the same approach. If someone is going to convince me to their ideas using oversimplifications instead of focusing on specifics of my situation it just isn’t going to work.

However, I also see some of this as a slippery slope. This line of thinking should not be used to just write off what thought-leaders say simply because it doesn’t seem to fit your current context. They may not know it all, but I would say they know a lot (else they wouldn’t be thought leaders). Also, many of them do not let their craft go stale, and many also play the role of coach, staying around to help change organizations or demonstrate principles at work.

I guess all I’m saying is that people need to make sure they do their due diligence to learn and understand both agile and their organization. I’ve seen too many people that were too quick to say things wouldn’t or couldn’t work, and I’ve heard arguments like the ideas proposed in this article misused to justify their position.

I’m yet to see this kind of point in any consulting deal. To be honest I don’t expect to see it anytime soon.

I don’t even say solutions brought by a consultant must be wrong. But to be honest: do people pay you to fight with office politics or to show them the way to improve their work? I guess the latter. And how long it takes you to stop trying to overcome existing order?

Anyway, it wasn’t the point. Actually the point was consultants are often wrong. What they see is usually just a surface. And they sure have a lot of solutions, unfortunately these solutions are rarely tailored to the specific situation.

I can give you an example – I’m learning my current organization for a year already and there are still things new for me. And my opinion about the company has changed much after about half a year of working there. Note: I’m rather privileged when it comes to access to information. Now, how long is typical coaching/consulting spell? And besides consulting on top level how much less information you get access to?

Take it to the next level – one of industry thought-leaders. They don’t even take the time to learn the organization and they still serve you recipes to heal it. Should they give back their money if their recipes don’t work? I didn’t think so. But on the other hand we shouldn’t expect they will always work either.

A good consultant ensures that they never get into that situation; they figure out how to make their theories successful and repeatable across diverse situations.

If not, time to get a regular job again.

David Wright
Requirements Consultant

I like your approach and if I think about environment I’d like to consult in I’d look for similar to your description. On the other hand I’m aware of problems you point. Once you’re a colleague people don’t want to hear your advice any more.

Anyway, that’s not a standard consulting path. Consultants/coaches usually put themselves in a position of short-term teachers – today they are here and tomorrow they’ll be somewhere else and people would have to deal with their problems by their own.

It’s understandable why people easier accept standard consultancy – it’s easier to ignore it and work as before.

The thing with consulting is that it is tough to convince your client that you have any skin in the game. One way to do so, it so play an embedded ScrumMaster/Agile Coach for an extended period of time.

That tends to introduce other complexities such as:
- People will undermine you
- It is longer than most consultants prefer
- You can get “pickled”

It’s a delicate agile carnival tightrope act between adapting your real world experience to new situations & pushing the envelope.

Looking forward to your other articles on this subject!

-David