1. Scaling teams
For enterprise class projects that contain at least 7 teams (or 50 to 150 people) the level of complexity increases.
This is due to content alignment, interdependencies and integration, making it hard to ensure consistency across the teams.
The first good practice to consider when scaling teams is the use of Agile Release trains. This ensures consistency across sprints and over multiple teams towards a release.
The use of release trains enables setting a common cadence, using a product owner council to align content and manage dependencies in sprints. The product management function ensures choices are made that make sense beyond the project lifespan and take maintainability into account.
2. Scaling across the value stream
Scrum is effective to manage development teams. When the value stream becomes longer, more complex and spans organizational domains Scaled Agile practices help to identify, map and prioritize value over a value stream.
For example to manage joint investments in manufacturing automation systems, in mul-tiple factories, supporting several product lines will require high transparency to balance the value of investments for affected factories.
In this case visual management and Lean toolkit (specifically Kanban) and value stream mapping will help to manage the flow of work towards Scrum teams. Considering the value stream as a whole will help to create mutual
understanding of the goals of the different stakeholders. This in turn will enable decision making with the entire enterprise in mind. Kanban (or visual workflow management) can be used to manage the flow of ‘big chunks’ of work towards the scrum team. This facili-tates breaking down work in small batches (slicing) and just-in-time processing of larger requirements.
3. Scaling across the business organization
Finally, when the work of 1 or 2 teams delivers to a multitude of business organizations there is danger in IT trying to solve all the business complexity that lies behind. This will often result in unsatisfied business owners.
Making the backlog transparent combined with objective methods to make prioritization choices is the solution direction for this type of scale. The business logic and value logic should be driving decision making. One of the typical challenges this type of scaling is organizing the different business stakeholders in a structure that facilitates trade-off de-cisions. The trade-off decisions need to be in line with the limited capacity of the teams. The capacity is usually determined by portfolio management.
An example of such type of scaling is web or portal technology that services many busi-ness areas. Making explicit choices based on metrics will reduce political power play. For web technology conversion rate and click ratio’s are good indicators for business value.
Finally: Creating one integrated solution
Large enterprise development efforts often need to result in a single integrated solution. To meet the end goal all the parts need to work and integrate into a single working solution. A good example would be an integrated enterprise application landscape or an integrated ERP software solution suite. This is not a scaling dimension in itself but
it puts requires a high level of coordination across multiple release trains. This is a high maturity scenario, when this is relevant all other dimensions are probably also relevant.
RISKS OF SAFE LIGHT
‘Silent discotheque’ syndrome
When many teams in the same program keep irregular sprint cadence it may make sense from a team perspective, but seen from the whole it will look like everyone is dancing to a different tune. This will never lead to a coherent ‘Swan Lake performance’.
‘Rebel without a cause’ syndrome
High performing teams that expertly manage their own team backlog without guidance to a program backlog and ulti- mately the companies strategic goals. Individual teams may be highperforming and self-organizing but it is ineffective to deliver a program.
‘Value cross-eyed’ syndrome
When everyone has their own view of what value is and there is definition across teams. If one team focusses on high au- tomation levels and others on reducing complexity with out- of-the-box functionality the outcomes will be challenged or even rejected by