Trouble with component teams and an alternative: feature teams
Traditionally, large products have been organized around the architecture. This was first observed by Mel Conway in 1968. Though he stated that this is not necessarily a good idea.
After de-constructing the component team approach, an alternative way of organizing will be presented, organizing teams around large end-user features (feature teams). This is not a new technique at all, though it’s rarely implemented on large product development. I will go over all the drawbacks of feature teams and look at agile tools for overcoming these drawbacks. Also how to go over 100+ developers.
This talk is a summary of one of the chapters of the upcoming book by Craig Larman and Bas Vodde called “Scaling Lean & Agile Development: Successful Large, Multisite & Offshore Products with Large-Scale Scrum”
This is a presentation/talk which will be done completely with the usage of flipcharts. Using flipcharts, I’ll gradually build up the component team structure and point to the common problems, then I’ll gradually build up the alternative and make a visual comparison between them.
Agenda:
- Short introduction
- Component teams problems
- Feature teams
- Requirement areas