Based on the context of the organisation you work in, and what kinds of people and processes you are working with, the level of complexity you are working with can differ. 

The Situation Context Framework, as shown below, allows Agile teams to tailor their process, team structure and tooling strategies to create a customised situation dependent strategy. The area of the graph that results from a rating of a team on each scaling factor represents the level of risk faced by the team. So, the larger the area the greater the risk faced by the team. This represents what we would call a ‘complex situation’. 

To understand the different strategies in scaling teams working in complex situations, it is best to go through each scaling factor (as outlined by PMI). 

TEAM SIZE

The greater the domain and/or technical complexity of the project, the larger the team will be. As there can be tens to hundreds of team members involved, they are often allocated into sub-teams.

• Component Teams

Responsibilities for subsystems or modules are divided up to reduce the amount of sharing and collaboration required between diverse teams. 

• Feature Teams

Responsible for implementing functional requirements such as a user story or use case, and will often focus on a single line of business to gain expertise. At other times, they may take on specific requirements to a given application or system within the organisation. 

• Functional Teams

Larger teams are divided up based on their development function, including teams in architecture, development, testing and deployment. Each of these teams will focus on their own specialised function and pass on that work to the other functional teams. 

• Internal Open Source Teams 

At times, an open source method (encouraging open collaboration) may be utilized to develop a component or subsystem. This is where developers from across the organisation can contribute to the project and evolve it over time. 

GEOGRAPHIC DISTRIBUTION

According to the PMI Agility at Scale survey (2016), 71% of agile teams are geographically distributed, which means that working in a co-located environment is less common.

However, as we are dealing with Agile teams working in complex situations, the coordination of team members must occur in a sophisticated manner. As remote working becomes increasingly common, this will be important for all teams to consider, especially as project success rates decrease the more distributed people are. 

Here are a few strategies to adopt to help mitigate the risks of geographically distributed Agile software development:

→ Up-Front Planning 

Effective teams will invest more time and effort into planning and identifying major dependencies and milestone dates. This is done with the distributed developers that are actively involved in the project and attempt to consider all associated costs, including the low probability/high impact risks. 

→ Integrate Regularly 

Large or geographically distributed teams may often find it difficult to integrate regularly. This is when sub teams will need to be allocated to deal with the overall integration and end-to-end testing of the entire solution. Having a separate team tasked with handling integration and testing issues can help to increase productivity. 

→ Have Daily Coordination Meetings

Agile teams will most likely have daily stand up meetings (or Scrum meetings) and can be done by largely distributed teams. Differences in time zones will make this difficult, so it is important to consider that meetings may need to be held at uncomfortable times and consider rotating the times of the calls to alleviate this inconvenience. 

ORGANISATIONAL DISTRIBUTION

Having teams formed by members from the same group or division within a single organisation is at the most desirable end of the spectrum of organisational distribution. However, since we are dealing with complex situations, it is likely that contractors and outsourcing will be a significant part of the project. 

Be an Agile Customer

• Provide a technical roadmap to your provider, so that they understand the team’s technical direction, standards and more 
• Consider co-locating the Product Owner with the provider, so that there is an ease of access to the PO
• Actively govern the team as outsourcing services has its risks. This can be done by setting weekly demos and having a team dashboard & automated quality metrics
• Most importantly, respect the service provider

Be an Agile Provider 

• Be truly transparent with your customer 
• Schedule weekly iterations/sprints 
• Provider your customer access to the team’s automated dashboard 
• Readjust your culture with that of the customer as people from different parts of the world will have different ways of working. 

SKILL AVAILABILITY

When working in complex situations, you may find that it will take longer to source the right people needed in the team. As outlined by PMI, the availability of skilled people is critical in driving organisation distribution. This is where outsourcing becomes important as you may need to partner with other organisations to find the people with the skills you need.

COMPLIANCE

According to a PMI Agility at Scale Survey (2016), it was found that 62% of the Agile teams faced regulatory compliance and 20% organisational compliance. 

The Disciplined Agile tool kit outlines several key strategies to address issues related to regulatory compliance. 

→ Adopt a hybrid strategy 

As regulations can cover a wide range of issues, it is critical to adopt different practices from different sources such as management practices (Scrum), agile documentation (Agile Modelling) and data quality (Agile Data). 

→ Focus on solutions, not just software

Disciplined Agile recognises that delivery teams work on consumable solutions that are supported by documentation. It is important to recognise that these teams may need to change the business process around the usage of the system that supports their software, and even the organisation structure of the people using it. 

→ Be enterprise aware

Disciplined Agile recognises that teams need to be able to effectively work with enterprise architects and tailor their entire working process to be compliant within an existing organisation ecosystem. 

DOMAIN COMPLEXITY

Working with a complex domain, such as an air traffic control system, will require more investment in up-front modelling and planning. 

In addition, as the complexity of the domain increases :

• This stimulates greater sophistication in the Agile testing strategy (identifies how teams intend to approach testing, obtain test data, report defects, govern quality efforts etc) 
• A greater burden is placed on the Product Owner (PO), which calls for more sophisticated Agile modelling skills (methodology for effective modelling & documentation, e.g. TDD) and the potential support of Agile business analysts. 

SOLUTION COMPLEXITY

For large and complex solutions, one organisational construct that can be adopted is the Solution Train. It aligns the business and technology missions of Agile Release Trains (ARTs) and provides the additional roles, events and artifacts that are necessary to build complex systems. The Solution train helps develop things like medical devices, automobiles, commercial aircraft, banking systems and defense systems. 

Solutions are described as having  a set of capabilities and typically take multiple ARTs to implement. The figure below depicts the capabilities being split into different features, which facilitates implementation by a variety of ARTs. 

Kanban, an Agile framework, can be used to direct the flow of work to guarantee that the capabilities will be evaluated and analysed before reaching the solution backlog, to undergo implementation.