Month: July 2006

I have worked in, or in relation to, multiple large organisations. They have all been organised in functional or compentence stovepipes, most adding a project work view across, resulting in a two dimensional hierarchy.

I have always felt that this was not a good way to organise people, or work. I dislike the common project model, for reasons that I might come back to, but my main objection to the matrix organisation is that the strongest binding force between people is working towards common goals, such as the delivery of a developed system, not their function or competence.

Every time we organise people according to competence or function, we will introduce a need to do detailed activity planning, estimation and resource allocation which makes it almost impossible to be responsive to any change in the environment of the development. This is one of the main reasons that rigorous planning more often hinders a project, particluraly to become agile and responsive. For any change the detailed planning of activities allocated to persons has to be updated.

Project planning in the traditional sense, like what is supported by project planning tools like Microsoft Project, is based on the idea that there are activities that can be allocated to multiple persons/resources, e.g. 10 carpenters working full time on the same activity, when in fact most development work is divided into tasks for which a single person is working a fraction of his/her time. This fact makes detailed planning of development work a nightmare, not to mention the follow up. It has also been shown that design is inherently different from much other work in that it often is comprised of selecting one activity, of several possible, to work on, it is this that is the competence of the designer or engineer.

Organising people according to function also induces a sense of protectionism within each such function. “We here at accounting/testing/acquisition…” This often is counterproductive since many such functions have other agendas than the total enterprise, leading to sub-optimal activities.

One way of addressing this problem is to describe the processes so that they encompass the whole enterprise. Again, this works fairly well for some types of organisations, e.g. those which rely on workflows such as insurance companies. And again, development stands apart, there is no workflow that start with the customer requirement and ends with a shipped system.

For a long time I have belived that the organisation is an important view of the enterprise, and that there exists organisational patterns and anti-patterns. And after having read Martin Fowlers book on Refactoring I realized that organisations probably could be refactored too. Unfortunately I have never had the opportunity to work with this issue, but recently I visited Organisational Patterns by Coplien&Harrison. Unfortunately it focuses on Agile Software Development, (although they admit to have opted for “agile” from a marketing perspective) and not on Development Organisations in general, but since the total text of the book is available I thought I’d share this link. It is interesting to see that they present organisational patterns as an alternative to classical improvement targeting the process.

I have yet to read the whole book, but even the introduction is interesting, particular the notion of the four styles of software development, of which “agile” is the fourth and current, and its connection to social styles. I hope to have time to read the whole book in the near future.

Perhaps with this set of patterns the idea of Organisational Refactoring can come true.