A lot has been written about this and as always the final solution seems to depends on the teams and the nature of the system. My team is finally at a stage where we need to grow up from a team of 8 – 10 to about 30. This is our stab at organizing ourselves while keeping our Agility. The days to come will tell us how this plays out!
Recommended team structure is to organize teams by customer-centric feature sets (sizable number of related features).
System components still exist, and we strive to create good components, but we do not organize teams by these.
- Long-lived—the team stays together so they can gel for higher performance; they take on new features over time
- Cross-functional – has members from Dev/BA/QA needed to go from requirements to delivery
- Cross component – typically a team would work more on certain components but they can enhance any/all components needed for feature set delivery
- Multisite – spread over at most 3 offices – to avoid regional silos
- 6 ± 2 people
- Single-function specialist teams (UI, DB and such)
- Non-dedicated team members or “partial allocation.”
- All components have an owner or a pair of owners
- Is the ‘go to’ person(s) for any technical or architectural issues related to that component
- Promotes buy in and active involvement from team members
- Hands on dev – at least 50% of their time
- Focus on conceptual integrity between components
- Day to-day co-ordination for delivery
- Tie breaker(s) if team can’t reach a consensus
Inter team communication
- Multiple teams need to agree on cross-team working agreements—standards. Over time, the working agreement evolves because teams reflect, learn, and improve.
- No separate group owns the cross-team working agreement; the teams own them together.
- Scrum of Scrums can be the formal co-ordination mechanism. Weekly. More high level in nature.
- Ambassador activities each team to send a team representative (chicken) to the Daily Scrum of other teams they are interested in. Either the same day or the following day, the chickens report back to their team so that their team can determine the needed coordination actions.
- Roaming specialist moves between teams to pair and bring people up to speed quicker on niche tech.
- Open Space is a method for airing current issues and self-organizing around them. Team driven according to needs. Members of relevant teams get together, create topics related to coordination, and organize around them.
Avoid…Separate architecture group
Evolutionary design culture — the initial design vision is rarely great, and in any event since software is ever-changing, encourage a culture in which people view the design or architecture as a living thing that needs never-ending incremental refinement
- Interested representatives from different feature teams spend time together on common infrastructure design
- Once decided – all teams must strive to comply
If needed we can form an infrastructure team
- Works on infrastructure for a few iterations (incremental delivery)
- A temporary role until they return to normal feature team responsibility
When multiple teams start working on related features with a common theme, joint requirement workshops can be useful. The Dev teams get a joint walk though of the ask and they can evaluate the impact on relevant components
All components should auto deploy into QA – Functional test suite (Selenium et al) runs over the end to end scenarios
- Avoid … long-lived branches – Branching during development breaks the purpose of CI
- Useful… Release branches – snapshot of code in production
- Very short-lived branches that are automatically integrated in the mainline—adopt Git.