Scaling Agile: Feature versus Component Teams?

Kenneth S. Rubin presented during International Institute for Learning’s organized its first Agile and Scrum Virtual Conference. When exploring scaling agile to benefit from the experiences in individual teams, you may have heard about feature or component teams. Are these similar or different? Why not use Discipline teams?

Discipline Teams consist of groups of people with the same skillset. Traditional development or test teams , or outside projects you could think of programmers, analysts, testers, DBA’s and project managers each operating in their own team. It’s a throwback to 1995 when I started working.

Location teams are geographically bound teams, which may or may not be multidisciplinary. Think of on-site versus off-shore, Attempts then are regularly made to give a one-team feeling applying communication tools, joint meetings or exchanging team members for a while. Coordinating / collocated teams then become deliberately distributed teams. Be aware that distributed delivery teams may be considered as different from dispersed delivery teams. In that case, distributed teams are self-containing teams working on different locations acting as multiple teams. A dispersed team is a multi-location group of people acting as a single team. I have been there and done that with people located in The Netherlands, Belgium, Spain, India, etc.

Architectural layer teams are multidisciplinary teams focusing on front-end, enterprise service bus / middleware / mid-office, and back-end applications. I led projects in many large financial institutions having their IT department set up in this way.

Component teams own a software asset, a piece of code. The disadvantage is, that most organizations don’t sell re-usable software components. Changes impacting several components increase the complexity of the project or development cycle. Feature items from backlog need to be split up strictly along the lines of component teams. Who’s accountable for integrating the software and guarantee that everything is working ensemble? Silos revisited, complexity increasing because of planning and priorities dependencies. Asynchronicity among the teams hit predictability. The end result: agility at risk, delivery power weakened, when scaling up this way.

Feature teams consist of all the skills needed to get the job done if features equal the added value, a product or service, a customer is asking for. You may include component team members fill up positions in a feature team to be self-sufficient and spread knowledge. It would benefit T-shaped skills. But, at scale, this isn’t going to work.

Focus, limit the number of projects being executed simultaneously. The other obvious alternative: increase capacity. Life at scale is still a balancing act.

Don’t scale on dogma!

It’s the economy, stupid!

As an economist myself, I loved Rubin’s use of an economic framework to evaluate the decision how to scale. He uses variables like a waste of time, customer satisfaction, variability, innovation power, etc. Business case thinking expresses these variables into money. Rubin uses lifecycle profit.

Stewards, guardians, and community of practice

It makes sense to have component stewards or guardians in place. Nothing new here, we did the same in the 1990’s when I started working as a system analyst. This role serves a couple of goals:

• Teach other people about this component.
• Ensure changes maintain or improve the conceptual integrity of the component.
• Take a leadership role in promoting reuse.
• …without ‘owning’ the component.

Create a community of practice from feature team members. Think of testers, UX designers. Note, that the community of practice is no delivery unit, but a grouping mechanism of like-minded, experts.

Check the full presentation on Innolution’s website.