There has been some recent interesting commentary by Martin Fowler and Jez Humble on the use of features branches in DVCS systems. Specifically Fowler started the conversation with this post on Feature Branches.
It was during my reading of Jez's commentary in his recent post that I had a little light bulb moment about management of organizations in relation to the blog topic.
So the light bulb moment I had related to how companies I have worked for tend to address specific 'project/program' needs within the organization. My observation was this: Companies tend to "Feature Branch" the organization as a way to attempt to accomplish a specific project/program, i.e. new teams or new groups are formed to handle high level work items for the organization.
I believe that organizations run into a great number of the same issues associated with feature branching code when they split their org. structure to do work in this way. Breaking off a new group invites Conway's Law issues and shoves a 'wedge' between the body of the company and this newly formed entity. The new entity slowly stops conversing with the organization - they become disconnected from the needs, the new teams stop being able to really effectively know that what they are developing is helping. The only way to combat this tendency to to have the new org occasionally "merge" what they are doing with the larger organization. If too much time has passed between this merge and the last merge that occurred (Status meeting, conversation or other people synchronizations) then the new team may have developed their software considerably far down a path that is not useful to the organization as a whole - making the merge efforts difficult at best.
Following this analogy I am curious if there is an argument to be made about branching the organization by abstraction, similar to how code might be branched by abstraction. I believe that this would look like having work stories divvied up amongst a bunch of pre-existing teams. Some of the teams may have an expertise in a given area but would be more generalist in nature. This would keep the teams engaged and involved in what the reset of the organization is doing and accomplishing, no thought merging required.
Very interested in any of your (dear readers) experiences or thoughts - this is just something I have been mulling around in my head about how the business of software development works.
Comments...
Subscribe to:
Post Comments (Atom)
1 comment:
It is certainly an interesting analogy, and not one I have heard before. There are some obvious ways in which the analogy fails (for example, merges of code may be tricky, but once done it is fully merged; merges of groups within an organization are unlikely to fully integrate information), but that is true of all analogies. The better question is whether the analogy provides any useful insight.
My gut feeling is that I'm less sure of the "merging" part of the analogy, but the explanation of WHY one would create a group within an organization for a certain problem rings true.
Post a Comment