Thanks for a great post!

I love your sentence about the rigid top-down structures of Waterfall being “formed to suit the needs of project management, accountants, procurement and the lawyers who wrote contracts”. So many times I’ve seen consultants responsible for making money through their work, but spending their time jumping through hoops to make themselves easier to measure or manage.

I also appreciate you for sharing your insight into long-lived project teams. I’ve just joined a brand new team and it’s a long way from bonded yet. Oh, well… pub on Thursday!

Communication should, in general, be two way. However, that doesn’t necessarily mean that communication should be made just because it’s possible. Reporting that is too frequent becomes a distraction and dulls the initiative of the people at the sharp end. Often problems can be sorted out quickly by different teams speaking to each other immediately. Reporting up the line can waste everyone’s time. Unfortunately, some managers respond to uncertainty and their own insecurity by micro-managing. They don’t have the confidence in their teams just to let them get on with the job.

An aspect of the top-down, command and control model with which I’m particularly unhappy is the implicit assumption that everyone affected comes within the command pyramid. In the olden days of corporate, in-house applications that was largely true. The users were given applications to work with, and if they hated them then that was tough. If they really hated them then they could find another job.

That was a dreadful, blinkered and inefficient way to develop applications and to work, but it was more or less effective in a brutal way. However, the model completely fell apart with the arrival of web applications and users who were real external customers, over which the corporation had no power. If they didn’t like the application they were off to a competitor.

If you persist with the traditional top-down approach you outlined, then the only way the customer fits into this model is as, er, the enemy! No battle plan survives contact with the enemy, and no first-pass design survives contact with the user.

Ironically, the way the military really works is more suited to dealing with user/customers than the traditional perception. Just after his 21st birthday my father was an artillery observer at the Battle of Arnhem. He was right on the front line, directing artillery fire from miles away onto targets within a few hundred metres of his position. The process was to call in a ranging shot, then home in on the target with rapid feedback and adjustment. Bright, well trained youngsters, with complete command of the technology and given the freedom to get the job done without constantly referring to their commanders. Oh, and incredibly strong team spirit. My father’s best friends for the rest of his life were those he made in the army.

So the freedom of initiative, and rapid feedback/iteration of Agile fits more neatly with the military than people have tended to assume.

The rigid top-down structures of Waterfall were never about doing the right job, or even a good job. They were formed to suit the needs of project management, accountants, procurement and the lawyers who wrote contracts. It’s a long time since the military was stupid enough to build their command structures to suit the convenience of staff officers.

In my experience of IT development it’s been a recurring source of frustration to see good teams being broken up, and new ones having to form from scratch as each project ends and another starts. By far the best work I’ve been involved in has been when the same team has been given the chance to run through a series of repeated projects. It’s great when you’re part of the same team working with users whom you’ve come to know well and you have the chance to learn from the last project and do it better next time.

Feedback from users about the “project experience” of the team comes naturally when you have that continuity. It’s usually not even considered when each project is treated as a one-off with a brand new team. One of the seldom mentioned benefits of Agile is that you really can’t work with these one-off, disposable teams, who have to learn expensive lessons from scratch each time. Great!