I’ve been an advocate of using feature teams instead of component teams for a long time. Back in the 1980s and 1990s, when I was working on embedded systems using 8-bit microprocessors, I often did both the hardware and software development. The easiest way I found to work was to develop both in parallel, adding complete functionality feature by feature. Working in this fashion also gave me great insight into choosing whether to implement a particular bit of logic in the hardware or software. Sometimes a software implementation could save a lot of expensive hardware, and other times a small bit of hardware could save a lot of software or provide better performance. Since I was working on both sides of the fence, I could easily move the logic from one to the other, sometimes changing my mind as I learned new information while implementing the functionality.
When working in larger teams, the work was usually split between hardware engineers and programmers. Occasionally I could influence a change in the hardware while working as a programmer, but not always. I really missed the ability to optimize across the hardware/software interface that I’d had when doing both sides.
When you scale up to large numbers of people working on a system, things can get out of hand, though. What happens when a lot of people make changes to the same components without talking with each other? Usually, the conceptual integrity goes out the window. So, what to do?
Bas Vodde and Craig Larman, in their book, Scaling Lean & Agile Development, advocate “a component guardian whose role is to teach others about the component ensur[ing] that the changes in it are skillful.” Where the issue is not just a fragile component but a heavily used one, I suggest you might want to go a half-step beyond a component guardian to a component steward.
Whereas a component guardian teaches people about the component and reviews changes, a component steward collaborates on changes. When a team needs to make changes to the component in question, the component steward would work with them on the change as though they were temporarily part of that team. This ensures both that the component design and the business needs are kept in mind for the change. Neither of these concerns should be sacrificed for the other.
A component steward could be a single person, but I would generally recommend a group of two or three. This raises your “truck number” and also provides multiple viewpoints to aid in keeping the component robust. There is generally more than one reasonable way of designing a component, and using multiple heads helps find more of those ways. Also, given that the issue being solved is that frequently multiple teams may need modifications to the component at the same time, having multiple people in the component steward role makes it easier to satisfy those needs. These people should, of course, talk with each other very frequently as they do this work. They may want to get together multiple times a day to coordinate their work.
Large scale software development is hard. It’s tempting to abandon the business focus for a technical focus that protects the code. This extracts a high price from the organization as a whole, though. With component stewards, you don’t have to make that sacrifice. There is, of course, additional overhead, but you should find that only a very few components really need such stewardship.