I’ve been on both sides of the Agile transformation equation, both transformed and the transformer. Over the years I have seen a couple of anti-patterns in engagements that should be avoided.

Prove that you can deliver and we’ll look at transforming your supporting teams later

This seems very reasonable on the surface, especially in enterprise computing, but it is doomed to failure. An agile project that is surrounded by waterfall teams is essentially in the toilet.

An effective agile team must control every aspect of development from UX to infrastructure. That is why small teams are often more affective than big teams. If you cannot change the database tables, choose the tooling or access the servers then you are not proving that agile works, you are proving that you can strangle agile to death. The good news is that it has been proven numerous times and does not need repeating.

What this statement is really trying to do is limit risk and that requires trust. Don’t give the agile team something that you are willing to let run in the cloud, or where you don’t mind if they administer the servers themselves. It doesn’t have to be small, just independent and watch the ecosystem you want build around it.

Please teach our developers how to do a better job. Just leave us out of it.

Agile is as much a business practice as a development practice and requires that practitioners are empowered to change the process they are working in. That can step on a lot of middle managements toes, but that is okay. There is still a lot for you to do: politics. Building relationships withing the company and using those relationships to really empower your team are now what you do and on a well oiled agile team, your practitioners are going to be too busy building working products to do it themselves.

If you can’t bare the idea of not being able to micromanage, demand documentation or ask for code review reports agile isn’t for you. I have worked in enough companies where all of those practices are the shield that keeps you and your team in a job. That doesn’t mean that you are doing it wrong, just that you aren’t ready for agile yet.

Can you show us how to be agile without any of that pair programming, or automated testing bullshit?

Pair programming and automated testing are core agile practices, but they are not written in stone. There are some very real reasons why you wouldn’t do some of the more ‘expensive’ agile practices.

Pair programming, automated testing and continuous integration have been demonstrated to significantly reduce the need for external training, reduce the time for new developers to learn a code base, reduce the number of bugs found and the cost of fixing them once they are found. If you do not care about these side effects then they are not for you. Lets break that down:

You are not hiring and your staff are intimately familiar with the code base and technologies already. You have a high tolerance for bugs. Bugs do not result in lawsuits, death or high customer loss. Finding and fixing bugs is not significantly affecting the release of new features

The real question then is why do you want to be agile? Cowboy has its place. If you are venturing out in to the unknown and the most important thing is that you get somewhere first: Cowboy. Once you get there and you are ready to replace the roadside shack that you built with a new, reliable place of business call in the agile consultants and build it with you.