In Setchu, instead of permanent teams, we suggest the use of transient, feature-oriented teams (we call these “Feature Sets” or “Feature Teams” if you prefer).
The basic premise is that you have a requirement for a large area of functionality (a feature), that is independent enough for a separate team to work in parallel to other product features. The team will own this feature end-to-end.
Agile Team Lifecycles
Feature Sets are usually assembled for any feature taking more than 2 weeks to produce – anything smaller should generally be assigned to the backlog of an existing team.
Outside of a feature (project), each team member will generally exist within their specialisations from an organisational structure perspective. There will be some cases where your team may include an outside specialist for the duration of the feature, if there are niche skills that aren’t quick to learn or readily available in house (usually a consultant or contractor).
Once the feature is complete and delivered, each resource returns to their “pool” (if not immediately assigned to another feature), ready to be assembled in a new feature team or added to an existing team.
There is a possibility (initially) that teams take time to socialise (or “gel”) well enough to reach peak productivity, but after a period of time it actually socialises the wider team, allowing better collaboration beyond single teams. Longer-term this approach should help prevent “them and us” environments, where hand-offs and conflicts of interest can be much more costly with a silo mentality.
Team Sizes
From experience, we’ve found that smaller teams typically produce more (person for person) than larger teams. Teams of around 6 (including Feature Owner and Agile coach / Feature Master) are the ideal, with the aim of having no more than 10. The reason for the preference towards smaller teams is that once you’ve divided your work into logical, largely independent features – the chances become less that the work within that feature can be sub-divided again successfully.
Agile Training
If the feature would involve 20% database, 40% back-end, 20% front-end and 20% testing effort, we’d ideally match that distribution in the make-up of the team (maybe 1 DBA, 2 Java developers, 1 web developer and a dedicated tester) along with the business feature (product) owner.
Obviously in the real world things never line up so neatly, but that’s typically a good thing. If one area requires slightly more resource than what’s available, some cross-skilling occurs. So, by the end of the feature, your tester may have picked up some basic database skills etc.
This single feature, multi-skill approach has the effect of providing exposure to different concerns, whilst allowing people to focus on their specialisation. So there’s often no additional training costs required.
Example Scenarios
In its most basic form, we have a team assigned to each key feature, each requiring similar levels of effort:
Next we have some examples showing feature prioritisation with different teams at different levels of scale. From a single team focusing on the minimum viable aspects of the three key features, to multiple teams able to work on the MVP concurrently:
To expand on the previous example, here is a scenario where there is a fourth key feature, but still only 3 teams available to deliver the product:
In this case, you’ll notice that the MVP of the fourth feature is delivered after the additional core additions of feature three. This should be a reflection of business value – if the Product Owner valued the fourth feature MVP over the core additions of feature three, that would have been picked up first (immediately after the third feature MVP).
Setchu - Agile at Scale 