Each team operates under a different context. The purpose of this post is to characterize team context using objective factors. This characterization should improve our understanding about what can matter most when developing a team Agile process.
Client driven or infra-structural
Client driven teams face the client and are expected to deliver value based on their client demand pattern. Infra-structural teams provide common components to be used by other teams and therefore are less affected by client demand pattern.
Some products require short release cycles while others can accommodate long release. Many clients (e.g. banks) don’t prefer frequent releases, while other clients require short cycle.
Some teams produce products which have estimated revenue from each MMF in the release. These teams have to timely release the MMFs or they might lose first to market opportunity. The cost of delay for such teams is higher than other teams.
Distributed or collocated
By geographically disbursed I mean that not all stages of the value stream are owned by a single location. For example, an architect in the west-coast owns the architecture stage while development is completed in New York. This for me adds consideration when establishing the visual board and how to conduct the Agile ceremonies.
Duration of a typical request
Even if we have iteration-less implementation of Agile, I suggest establishing regular review demos. I would like to associate a request with MMF to have meaningful and valuable item to be tracked. Sometimes it takes multiple demos before we can complete the whole MMF. This can determine how we breakup the request into cards to coincide with demo schedule.
A predictable pattern for demand should be our objective, but it takes a while before we can achieve this objective. Till then, analyzing demand pattern from various request types can impact how we structure our teams, designing class of services and of course prioritization.
Agile in general doesn’t mandate dedicated teams. However, understanding team allocation helps in planning ceremonies, agreeing on WIP of various stages, addressing bottlenecks, prioritization, target date of requests and others.
Interfaces with other teams
Some teams have high impact on other teams. For example a change on a component can trigger ripple effect with multiple teams. This situation can impact the value stream, for example, add stage for impact analysis. Also, it might require involvement of other teams in part of the Agile ceremonies.
Appreciating the above factors can help to:
- Justify why we can’t have uniform process across all teams of the organization.
- Ensure that each team process is sensitive to its context.
- Mitigate risks associated with imposing one process to various contexts.
- Allow the team to own the process and and therefore to improve it since it’s tailored to team’s situation.