October 2007

I don’t know how many people realize that, but the roots of modern project management are in the early 20th century and stem from heavy industries, military logistics and… civil engineering. Gantt himself was working in the late 19th century steel industry, his chart (in its current form invented in fact by Karol Adamiecki) was used in the major construction projects of the New Deal (like the Hoover Dam). It was long before any software projects that it has become an icon of project management along with a whole set of methods, practices and theories.

There is no doubt that these methods were proven to work for the industries they were invented for. They got refined over the years, getting to the point where they could be considered scientific. A whole body of knowledge was gathered over time, institutionalized in bodies like the PMI, their PMBOK and certifications. Then all that was applied to software engineering, which someone erroneously mistook for another form of engineering or even manufacturing.

The problem is that a typical software project is very unlike an assembly line, but also differs very significantly form any civil engineering construction project. Let’s take my favorite example – building a bridge – and compare it to a software project.

When you build a bridge the environment (layout of the river, hills around it etc.) is largely known and very unlikely to change, as opposed to modern software projects. Also the requirements of the client are very simple, clear and not likely to change – no one sane will ask the bridge to be drastically changed midway into the project. The complexity level of the object being created is much lower than in an even small software project – depending on how you count even a simple software package contains hundreds of functions and thousands of variables.

The human side is also very different. In traditional industries, like civil engineering, organization is based on few knowledgeable individuals having a picture of the whole at the top and a command chain that transmits their design to the workers executing it. A typical construction worker doesn’t have to know the whole design of the bridge, nor is he required to be capable of understanding it. He has to be able to do well some specialized task (like pouring concrete or laying reinforcements) where directed. It doesn’t mean he is stupid – don’t get me wrong – but his training and knowledge are very different from that of the civil engineer who designed the whole structure.

This is quite contrary to a typical software developer who not only has to be capable of understanding the whole of the project he works on, but also has to know and understand the design to be able to effectively contribute. This is why organizing software development with command chains and “architects” leading the (largely ignorant) flock is wasteful and wrong. There is no doubt that developers with bigger experience are better at design and are better suited to lead juniors, but there is no fundamental difference between them.

There is nothing new going on here – humanity has always tried to apply methods from the past to the problems of today. It mostly worked, but sometimes it didn’t and the visible failure of existing methods or assumptions usually led to a positive change. The same is now happening with the software engineering. After realizing that the classical waterfall approach rooted in other industries from another time led to poor quality and even worse predictability the IT industry moves forward with the agile movement.

Agile is now quickly becoming mainstream because it reflects the reality of software creation. That’s why itn most cases it delivers on its promises of delivering better product and increasing teams effectiveness.

Building a bridge is my personal favorite example, because that’s what my father was doing before he moved into materials science.

After my last posts I did get asked how I convince clients to go for agile software development services we offer instead of fixed bids and waterfalls. Well, it is not easy and it is worth a longer post which I’ll write one day. So for now, since it’s late and I’m tired, just a few words about clients.

My experience shows that to accept agile development the prospective client has to be agile in his ways too – even if they never ever heard of Scrum, XP or Agile Manifesto. That is they have to understand and accept that what they do is an inventive process, hardly as predictable as it is portrayed by snake oil vendors and hence inherently risky. Instead of giving their project away to experts for a fixed bid and hoping for the best a good “agile client” wants to stay on top of his project, wants to have a say, get involved and be able to change direction or add new ideas.

This mixture is, indeed, not as frequent as I would like it to be. And this attitude is almost completely absent in governments and large corporations. Because of that I don’t even try to sell agile projects there. Some brave souls did succeed in this waters, but I stay away from them – for the time being. So if you try to sell an agile project to company of 1000 people or more (and it is not Google, Yahoo, BT or one of the other corpos known to use agile) you are going to have a hard time and little chances of winning.

Fortunately, most clients do not fall into those categories. Most clients are privately owned business of various sizes, who thanks to web technology can afford now to have a system custom developed for them. And they are spending money that is perceivably theirs, which means they want to spend it well and control where it goes. They understand much faster than corporate managers the benefits agile gives them and hence are more likely to go for it.

So, for now I’d recommend going after medium-sized, privately owned companies with a pressing need for a custom system unless you’re an expert salesman able to convince a corporate behemoth not to behave like one.