In my last post, I reintroduced this topic, describing the conundrum of organizing large number of agile teams to better address value delivery for new end user features and services. I described two basic approaches, feature teams and component teams, and some arguments for each.
I’m still waiting for some feedback from a couple of others before I conclude with my personal recommendations, which I’ll post in the next day or so. In the meantime, Craig Larman courteously responded with his comments on my comments on his work in Larman [2009]. Since wordpress, as a capable (and free!) as it is, tends to bury comments at a level where you really have to want to see them to find them (not sufficiently “in your face” from my perspective), I thought I’d elevate Craig’s comments to this post, as he provides some clarifications on his work and my interpretation, as well as some more expansive thinking on the topic. Craig’s Comments from the prior post below are verbatim below.
Note: please also see additional comments from others on this and the prior post.
========================
“hi dean,
(someone pinged me that this topic was under discussion). thx for raising the topic.
bas and i did not write or intend to write that feature teams are the only rational way to organize teams. rather, the choice of any organizational design (including team structure) can be evaluated in terms of the global goal for optimization (e.g., maximizing fast value delivery, minimizing disruption, etc). from a toyota or lean perspective and the first agile principle, the global goal relates to early/fast delivery of value to real customers.
in the context of that measure, if one has design 1 with more delay and handoff and design 2 with less delay and handoff, design 2 is ‘better’ — with respect to that particular measure.
the ideal cross-functional cross-component feature team minimizes delay and handoff, whereas (not an opinion, just by pure systems logic..) component teams (which per definition are doing only part of the work for a customer feature) have more delay and handoff and create mini-waterfalls with single-specialist groups passing WIP items to each other (analysts, architects, programmers, testers, …).
but feature teams are only the ‘better’ model depending on the global goal — which is worth identifying in any discussion. and as you point out, we note that an org design such as feature teams may optimize flow of value, but it raises other problems (which are solvable). from a systems thinking perspective however, optimizing around addressing one of the other issues (e.g., minimizing org disruption) is a sub-optimization from the the perspective of value delivery… but not a suboptimization if the group agreed minimizing disruption was the system’s global goal.
if one visits an org that was organized around component teams and then they successful transition to feature teams, and then one asks if delivery of value is faster, the answer will be “yes.” it is also common when investigating such an org that they will say that planning and coordination are simpler, and that the multi-skilled learning that arises when working in feature teams has been useful to increase their degrees of freedom and to reduce the “truck number” of bottleneck specialists.
i look forward to your future comments, and those of others.
regards, craig
=============
===================
References:
Highsmith, Jim. Agile Project Management. 2004. Addison-Wesley.
Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. 2007. Addison Wesley.
Larmon, Craig and Bas Vodde. 2009. Scaling Lean and Agile Development. Addison Wesley.
Scaling Software Agility 