I would like to write a post on this subject for a while (amongst lots of other…), and a post of Mike Cohn about Agile in the Age of Hyperspecialization reminds me the subject (in addition it is also a recurring subject at work for me). I wrote some comments on his blog, but I would like to detail a little bit here.
First of all, I am not confortable with the analogy done between manufacturing activities (or buildings and civil works) and IT industry, which basically leads to reduce developers to “simple” workers that could work in a production line (cf. Ford, with respect for manufacturing workers)…and I think that’s a point that is totally missed with hyper-specialisation.
I prefer other visions more suitable to our industry. In this first post, I will talk about “cultivate your code” analogy, “mentofacturing”, and feature teams approach.
Then in a second post, I will dive into an illustration of what could be stereotypical organization nowadays with “hyperspecialization” and my vision (shared and applied in my team), which is best aligned with Agile and Lean principles from my point of view.
“Cultivate your code”, a refreshing analogy
Classic analogies applied to IT industry are with buildings and civil works or manufacturing. But IT industry is fundamentally different from these industries. I will expose some arguments of another analogy, called “cultivate your code” I discover through Benoît Gantaume (in French but page translation can help non French speaker).
We often mimic processes of buildings and civil works. They are justified by the fact that once you have built a building, it is very hard to change it, it will not evolve as much as an application will. So they need to make lots of studies, to check every details before they lay the foundations. At the opposite, in software, it is very important to be able to build an application that can evolve quickly and potentially in depth (i.e not only on the surface). Moreover, an application that is not evolving will degrade through surface maintenance only, that’s why Benoît Gantaume compares it to vegetal with lots of comparison of day to day activities with those we can see in a garden (I let you read his post). The main idea is that a garden needs constant cares and a software is comparable in this way.
We like (in IT industry) to use manufacturing wording, notably industrialization. Note also that products are completely different, in manufacturing, products are designed once and built several times on production line. Software is absolutely not in the same case, it is unique, designed once and built once. About industrialization, we apply recipes of the XXth century (or even XIXth) with industrialization through (overly-)manual production line adapted to IT through hyper-specialisation. We do not use enough tools and automation at the service of individuals in IT whereas it is far more simple and cheaper than in manufacturing (installing software versus building robots). These arguments are not covered by Benoît, but I think it is like using the good tools to maintain your garden, rather than using only your hands. Even worst, we often use tools that constrain individuals, as if you would try to dig with a rake…
“Mentofactoring”
I heard for the first this word at USI 2011 event (for those understanding french – even if you have an english traduction also – here is the webcast). It was presented by Vincent Lextrait. He started writing a book and first chapters are available at http://www.mentofacturing.com/. I try to summarize key points, but encourage you to read at least home page, which give a good overview.
The reasons why Adam Smith advises divison of labor was based on different parameters than those that characterize work today. First, there was a shift with computers, that minimize cost of loosing time by switching tools. Second, there is far more variations in intellectual productivity than in manual productivity. Third, there is far more interpersonal dependency in intellectual activities than in manual ones.
It concludes that management (and so work organization) of these kind of activities cannot be the same as in classical industries (buildings or manufacturing typically).
Feature Teams
I read this from Craig Larman and Bas Voode book on Agile scaling about organizational tools http://bit.ly/oFtSAM, and specifically in chapter Feature Team (accessible here). The authors focus on Lean manufactoring in their book (finally even manufacturing has new vision…). It is really well explained, I will just paraphrase some part.
The main idea is “one single cross-functional team that completes end-to-end customer features”. It is justified by Lean theory : “In lean hinking, minimizing the wastes of handoff, waiting, WIP, information scatter, and underutilized people is critical”. They also insist on the fact that each team member has not only one speciality, each one has primary skills, but with help of other team members, each member can complete an end-to-end customer feature (reference to “generalizing specialist” introduced by Scott Ambler). Moreover, learning is at the center to share skills and knowledge.
The difference between Feature Team and Feature Project is also very important. With Feature Team, you have less organizational noise due to needed coordination when several Feature Project are involved on one application. It also capitalize on a group that learn and does not break up at end of a project. And third, a Feature Team has shared ownership of code, process and skills.
These three visions illustrate other visions than the mainstream that advocates hyperspecialisation.