10,000 Foot Developer

Do you know what this is?

It’s called a Chadburn, or an Engine Order Telegraph.     I don’t know if they make these things too much anymore, maybe they do.  You can see a bunch of them if you visit the Queen Mary, or maybe ride the riverboats Mississipi Queen or Becky Thatcher.

A Chadburn is how the captain would communicate to the engine room: how fast to go and which direction — forward or back.  That’s it.

The reason I bring this up is because I keep hearing more and more and more stories of management thinking agile works just like this.  The think this because they get tools like Greenhopper or Rally or Mingle or VersionOne and then they get to tweak the “daily” operations of the teams.  Big AAgile has enabled poor management.  Instead of enabling their team to succeed, they have in effect introduced micromanagement and put all of the accountability on the team for  work it did not agree to.

Unfortunately these management captains are nothing more than insane Ahabs forcing long hours and stress on the engineers hunting white business whales.  They forget that the software steamship needs fuel to run, and it can only go so fast or what we call “velocity.”  In fact, the very tenets of agile have been cast aside — it works best in the build box, and the people who do not know how to do that work should stay away or they severely impact the team’s productivity.

Agile is a contract.  Business says what they would like.  The PM prioritizes with the business and helps intra-team coordination.  The engineers and QA do estimates, and say they can build this much in that time based on their engine size.  Simple.

But now Big Agile is making empty promises to the management teams.  You don’t really have to be “overly technical” no!  You can make the estimates for your engineering team and hold them too it.   They think Agile is this:

But that’s not what software is.   Six Sigma failed trying to do this, and ISO 9000 failed trying to do this.   The breaking point is always the same: management wants the creative process to be predictable and controllable and on a time table.  Well, it isn’t.  Software making is creative, not manufacturing.  Sorry, but thats the reality.

Large companies are getting sold the wrong Agile bill of goods.  More heirarchy is being enabled because of the strict process the tools lay out onto the teams.  And in the end, what happens, is that watching the process so closely changes the process and people use the tools to report what management wants to see, not reality.  And as I’ve said time and again, when that happens, there is usually a shadow process happening to get the work done.  Management becomes a team impediment.

And then, at the end, with changing scope teams never agreed to, work being driven outside or reasonable capacity, burnouts happening your engine room ends up looking like this:

And that is not cool at all.