Tactical Scaling Complex Situations: A PM Guide

Tactical scaling complex situations is a skill that every Agile leader needs. The work you do depends on your organisation and the people around you. Therefore the level of complexity can differ a lot from one project to the next.

The Situation Context Framework lets Agile teams tailor their process, structure and tooling. So each team can build a customised strategy that fits the situation. The area of the graph from each team rating shows the level of risk. Thus the larger the area, the greater the risk the team faces. This is what we would call a complex situation.

Scaling factors in tactical scaling complex situations

To grasp the strategies for scaling teams, it helps to go through each scaling factor. These factors are outlined by PMI, so they give a clear and shared map. Next we walk through team size, distribution, organisation, compliance and domain complexity in turn.

Team size and how teams divide up

The greater the domain or technical complexity, the larger the team will be. Because there can be tens to hundreds of members, they are often split into sub-teams. Teams therefore divide work in several ways.

**Component Teams.** Responsibilities for subsystems or modules are divided to reduce sharing across diverse teams. So collaboration overhead drops.

**Feature Teams.** These teams implement functional requirements such as a user story or use case. Moreover they often focus on a single line of business to gain expertise. At other times, they take on specific requirements for a given application or system.

**Functional Teams.** Larger teams divide by development function, such as architecture, development, testing and deployment. Each team focuses on its own function and then passes the work on to the next.

**Internal Open Source Teams.** At times an open source method encourages open collaboration to build a component. Thus developers from across the organisation can contribute and evolve it over time.

Geographic distribution

According to the PMI Agility at Scale survey (2016), 71% of agile teams are geographically distributed. Consequently working in a co-located setting is now less common. Because these teams handle complex situations, coordination must happen in a careful way. Remote working keeps growing, so every team should plan for it. Still, success rates fall as people get more distributed.

Here are a few strategies that mitigate the risks of distributed Agile development.

**Up-Front Planning.** Effective teams invest more time in planning and finding major dependencies and milestone dates. This is done with the distributed developers actively involved. Furthermore they weigh all associated costs, including low-probability but high-impact risks.

**Integrate Regularly.** Large or distributed teams often find it hard to integrate regularly. So sub-teams handle the overall integration and end-to-end testing of the solution. As a result a dedicated integration team can lift productivity.

**Have Daily Coordination Meetings.** Agile teams will likely hold daily stand-up meetings, also called Scrum meetings. Time-zone gaps make this hard, so meetings may fall at uncomfortable hours. Therefore teams should consider rotating call times to ease the inconvenience.

Organisational distribution

Having teams from the same group within one organisation sits at the most desirable end of the spectrum. However, since we deal with complex situations, contractors and outsourcing often play a big part. So both sides of the relationship need clear habits.

Be an Agile Customer, and keep these habits in mind.

- Provide a technical roadmap to your provider, so they understand the team's technical direction, standards and more - Consider co-locating the Product Owner with the provider, so there is easy access to the PO - Actively govern the team, since outsourcing has its risks; set weekly demos and use a team dashboard and automated quality metrics - Most importantly, respect the service provider

Be an Agile Provider, and follow these in return.

- Be truly transparent with your customer - Schedule weekly iterations or sprints - Provide your customer access to the team's automated dashboard - Readjust your culture with that of the customer, because people from different parts of the world work in different ways

When working in complex situations, it can take longer to source the right people. As outlined by PMI, the availability of skilled people drives organisation distribution. Therefore outsourcing matters, since you may need partners to find the skills you need.

Regulatory compliance

According to a PMI Agility at Scale Survey (2016), 62% of Agile teams faced regulatory compliance and 20% faced organisational compliance. The Disciplined Agile tool kit outlines several strategies for regulatory compliance. Each one tackles a different part of the problem.

**Adopt a hybrid strategy.** Regulations cover a wide range of issues, so it helps to draw on different sources. For example, you can blend management practices (Scrum), agile documentation (Agile Modelling) and data quality (Agile Data).

**Focus on solutions, not just software.** Disciplined Agile recognises that delivery teams build consumable solutions supported by documentation. Moreover these teams may need to change the business process around the system. Sometimes they even adjust the organisation structure of the people using it.

**Be enterprise aware.** Disciplined Agile recognises that teams must work well with enterprise architects. Thus they tailor their whole process to fit within an existing organisation ecosystem.

Domain complexity

Working with a complex domain, such as an air traffic control system, needs more up-front modelling and planning. In addition, as the complexity of the domain grows, two things happen.

- This drives greater sophistication in the Agile testing strategy, which identifies how teams approach testing, obtain test data, report defects and govern quality - A greater burden falls on the Product Owner, which calls for more sophisticated Agile modelling skills (for example TDD) and the support of Agile business analysts

For large and complex solutions, one construct to adopt is the Solution Train. It aligns the business and technology missions of Agile Release Trains (ARTs). Furthermore it provides the extra roles, events and artifacts needed to build complex systems. So the Solution Train helps develop things like medical devices, automobiles, commercial aircraft, banking systems and defense systems.

Solutions are described as a set of capabilities and typically take multiple ARTs to implement. The figure splits capabilities into different features, which eases delivery by a variety of ARTs. Meanwhile Kanban, an Agile framework, directs the flow of work. Thus capabilities are evaluated and analysed before they reach the solution backlog for implementation.

Build these skills with PMCOE

These ideas sit at the heart of scaled Agile delivery. To go deeper, our PMI-ACP agile certification courses and the PMI-CP construction professional course cover scaling, distributed teams and compliance in detail. The frameworks here come from PMI, so you can also read more on the PMI website. Ultimately, strong tactical scaling complex situations practice helps your teams deliver under real-world risk.