Organizing at Scale: Implementing Spanning FeaturesPosted on August 7, 2009 by Dean Leffingwell in Distrib. Development, Enterprise Rollout, Feature Vs Component Teams
Prompted by the discussion of feature and component teams, a reader recently sent in the following question:
“I have a user story, that on its face, appears to have been structured in such a way that it simply cannot be independent. That is, the story itself cuts across teams, and even across product lines. If the story were to be broken down any further, it would only be into its constituent tasks. Moreover, it appears the cross cutting nature of this story will lend itself to the necessity of creating a virtual team of sorts as it will take individuals from many teams to coordinate. Moreover, we have identified many new stories of this nature.
The team involved is rather large (300+) and spans several countries. So I suppose what we may be looking at is one very large project team with many sub-teams and that many stories may impact many teams. My first inclination is to suggest that if a story such as the one above exists, then it should be decomposed into smaller stories that each team can work towards. However, I’m struggling with the lack of delivering anything tangible on a per story basis.”
Here was my response:
Your first inclination is generally the best one. At enterprise scale, many features span teams. This is indeed the common case, especially as the customer value stream pile moves up the stack to where they are using multiple products, web services, or whatever, in new and innovative manners. However, there should be no reason to create new teams, or programs, just to coordinate content of this type.
Don’t worry so much about the fact that each team-level story doesn’t appear to deliver user value by itself, (although you should take every opportunity to see if you can define team-level value stories that deliver value to their users too) as that is taking the user value story metaphor too far. Since you can be dang certain that the bigger feature is delivering value to your customer, it doesn’t matter that some team is having to build an adapter-API –widget-whatever, or has to refactor some code that they wouldn’t otherwise have to refactor. It’s just part of what they do to deliver larger end-user value.
Indeed, this is such a common occurrence in the enterprise that the Big Picture was designed in part to address it: Here’s how it’s handled.
- A Product Manager or program manager who understand the need for the bigger feature expresses it to the teams at the release planning boundary
- During release planning, teams break the feature into smaller stories that that they deliver to the baseline in the iterations. (Note: In the lean and scalable agile requirements model, I don’t call these breakdowns tasks, as tasks are reserved for the individual activities to coordinate completion of a story).
- A scrum of scrums, a release management team, the system team, or the program or product manager, helps coordinate the delivery of the feature over time. The system team, or some like construct, performs end-to-end level testing of the new feature.
If you are organized this way, you should be able to handle any number of larger spanning features. In the Big Picture, features and stories are just “content” to the teams prioritized backlog. The process just runs and runs, without the necessity for reorganization.
Whether currently organized by feature, component, product or service, if you attempt to reorganize every time a cross cutting feature comes along, everyone will spend too much time figuring out where their desk is or who the product owner is, and too little time cutting code.
Note: also see the following post on the same topic.