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 
Hi Dean, thanks for elevating Craig’s comment to the level of a post. While your assertion about component teams minimizing disruption is valid… and Craig’s comment about that being a sub-optimization is also valid… I don’t think that is they key reason to consider component teams.
As you mentioned… there are systems being built that are systems of systems. Integrating disparate systems… disparate technologies… disparate build environments… disparate locations… disparate cultures… disparate politics… etc. into a single team is really not a sound organizational strategy.
While I agree that feature teams are THE starting place… they make everything faster… you have to acknowledge the realities of the organization. I find that even small to mid-size dev orgs (100-300 developers) are struggling hard with this.
Yes, there are increased costs associated with running large projects through component teams. Hopefully those costs are offset by the value of multiple platforms leveraging those common components.
Anyway… I am sure we will be talking about this for a long time to come. Acknowledging the validity of the component team approach will help agile methods be successful where otherwise they would have failed.
Mike
hi dean,
thx for posting my last comment — appreciate it.
to expand a little, in the chapter “False Dichotomies” in our last scaling book, we attempted to cover issues such as “component teams vs feature teams” and all other org design and process questions at a higher level of abstraction. the theme of the chapter is that, rather than thinking in terms of ‘good’ or ‘bad’ in some absolute or binary sense, recognize that all org design ideas (including team structure) are situational and appropriately change over time.
and an appropriate lean thinking or Scrum empirical process control approach is not to “define the process” then “adopt the process” but inspect-and-adapt based on endless process and org design experiments — continuous improvement, one of the 2 pillars of the Toyota Way. Inspect and adapt applies to org design, in addition to the product. To quote the chapter, “Practices adjust along continuums according to context.” for example, some feature teams and some component teams in the same product. the book is therefore organized as “experiments” (try… and avoid…); the opening chapter emphasizes the experiments may not apply or work in your context.
the chapter restates what i shared in my prior book “agile and iterative” which restates what Alistair Cockburn nailed in his Crystal work and then summarized in his excellent book “Agile Software Development.” In his “Cockburn model” — and what Alistair used to talk frequently about under the subject of “designing a light methodology” (this was before the term ‘agile’ was popularized). Alistair talked about designing (and re-designing iteratively) based on the dimensions of Criticality, Liability, Group Size, and more. And depending on these forces, the org design and process changes.
i.e., alistair has already said it all 😉
as another example of a global goal, “safey” is more realistically-common than “minimize disruption.” then, the ‘goodness’ of team structure or any org design element can (and should be!) evaluated against that. i work with one client in the defense industry where “secrecy” is the dominant global goal, and in that case it is ‘good’ to separate an end-to-end feature into parts and to *not* use feature teams, because by separating the work and teams, no one knows the big picture.
all too often, however, there is no clear global goal amongst the ‘leadership’ and the org design just drifts aimlessly. or, leadership does indeed want the dominant global goal to be the common lean or agile theme of deliver value fast, but then they do not consciously nor with insight have the ability to evaluate or adjust their org design against this system goal.
what we were trying to do in the Systems Thinking, Lean Thinking, Queuing Theory, and False Dichotomy chapters, was to help develop those critical thinking skills in terms of seeing the impact of a current org design, and how to think about experimenting with changes.
regards, craig
I’m seeing this dilemma in action in a large customer I’m working with. We have feature teams at the component level (e.g. Front-end, Back-end, Testing within the same scrum team), but component groups at the portfolio/enterprise level.
I see the solution in identifying a way to effectively combine the two models.
I agree with Dean and Mike that feature teams are hard to scale to really large projects/programs/portfolios. I also see the hardships of working with component teams – the integration, sequencing, feedback all are less than ideal.
Maybe the scaling solution should be in suggesting best practices for creating a cross-component feature team structure that will work at the “scrum of scrum” level, combined with engineering practices that support this structure.
–
Yuval Yeret
Well, I think in all models the answer comes from Lean thinking: what ever produces most value and least waste. In SW development, dependencies (between people, process, time etc.) are culprits for three main wastes(out of 7): handoffs, delays and context switching. If you analyze the dependencies in your organization and product structures, you should be able to find the best fit solution. In my company it currently seems to be a model where client SW is developed in feature teams separately from backend (feature teams) and service deliveries. But the whole picture is yours, create, refine and finetune your own model by just keeping the Lean and systems thinking in mind.