Hierarchical versus networked projects

I had lunch with my friend Robert yesterday. He’s a programmer but for a brief period he works as a tester in a very large project at a company in the insurance business. As I’m interested in hierarchies versus networks I find it interesting to hear him telling about how the project is organized.

He told about how, when a bug is reported and filed in the bug tracking software, there are one or two people whose job it is to classify the bug, prioritize it and assign it to someone “in construction” to fix it. To someone – bugs are actually assigned to individuals! This fact says a lot about the level of control in this project: the bug guy not only knows how to classify bugs, but also knows which people have domain knowledge to fix them – and also which of these people have room for another bug in their “queues”.

I too work for a company in the insurance business, so I know how complex the problem domain is. In Robert’s project, the problem domain is split into a number of sub-domains for which each has its own sub-team.

Some bugs aren’t assigned to programmers, but to analysis and design people, in cases where the defects have architectural implications. At a previous lunch, Robert spoke about how specification and design documents were organized – with version numbers coded to state whether the documents had been accepted or were mere suggestions for changes. So when a bug gets assigned to A&D, I guess this yields in updates of documents, which are to be accepted, estimated and scheduled, resulting in new tasks for the programmers.

This project clearly requires lots of people just for management. It is also clear that it responds very slowly to change. My take is that a project like this isn’t any less subjected to changes that stem from the actual users doing acceptance testing on a test release of the system. This is the time where subtle things arise. Where minor things can have big effects. Projects like these do lots of things to prepare for this, but they will happen simply because the subtle things are hard to nail down when doing analysis of the problem domain – and in a project structured like this, it must be done largely up front. The sheer amount of documents and money spent on defining the system surely makes the subtle things seem easily sacrificed: the organization will have to learn new routines, where the system doesn’t address things. Or, if it is an important subtle thing, the beast grinds to a halt, changes direction slightly and starts up again.

There surely are projects that must use processes like this, and maybe this project is one of them. But it is still interesting to think about what would be required to execute the project in an agile fashion.