Hierarchical versus networked projects

I had lunch with my friend Robert yesterday. He’s also a programmer, but for a brief period he works as a tester in a very large project for a company in the insurance business. As I’m interested in hierarchies versus networks, I found it interesting to hear him talk about the project’s organization.

He told me about how, when a bug is reported and filed in the bug tracking system, there are two persons who are responsible for classifying the bugs, prioritize them, and assign each of them to someone “in construction” – to someone! Bugs are actually assigned to individuals! This fact says a lot about the level of control in this project: the bug guys not only know how to classify bugs, but also which people have the domain knowledge to fix them – and also which of these people have a “free slot in his/her queue” for fixing another bug.

Some bugs aren’t assigned to programmers, but to analysis and design people. This is done when the defects have architectural implications. At a previous lunch, Robert told me 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 analysts and designers, I guess this results in a stream of updated documents, which are to be accepted, estimated and scheduled, in turn resulting in new tasks for the programmers.

I also 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 each of which there is a sub-team.

This project clearly requires a lot of people just for management. It is also obvious 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 real users doing acceptance testing on a test release of the system. At this stage, the discovered defects often are caused by very subtle misunderstandings in the analysis process. They are possibly minor, but with big effects on the larger system.

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 such a project in an agile fashion.