Large teams will often adopt the following strategies to address the challenges that they face:
- Do a bit more up-front requirements exploration
- Do a bit more up-front architectural modelling
- Do a bit more initial planning
- Adopt more sophisticated coordination activities
- Adopt more sophisticated testing strategies
- Integrate regularly
Strategy #1. Do a bit more up-front requirements exploration.
Figure 1 depicts the process goal diagram for the Explore Scope goal. This Inception goal strategies to elicit and capture the initial requirements for our solution. We want to do just enough work to understand what our stakeholders want so that we can confidently begin Construction. Because larger teams typically take on more complex problems than smaller teams, you’ll find that you need to do a bit more, but just a bit more, up-front requirements so as to ensure that the team understands the problem that they’re tackling. This will often mean that your team needs to address several view types so as to explore the problem from multiple directions and potentially capture a bit more detail than they would in less complex situations.
Clicking the diagram opens the interactive DA Browser where you can learn more about all goals, decision points and options of DA.
An important consideration is which team members to include in modelling sessions. Do you include all of the team members during all modelling sessions? Do you include only a subset? Do you include a subset during each modelling session but rotate people through so that everyone is involved at least part of the time? Including all team members in all modelling sessions has the advantage that everyone hears what the stakeholders want and provides them with opportunities to ask probing questions. However, this strategy doesn’t scale well to very large teams because it’s costly, not everyone is interested in attending anyway, and there are space limitations in modelling rooms. Having a subset of team members included in all sessions is less costly and likely to be faster, but requires you to communicate your initial requirements to the greater team afterwards. Rotating a subset of people through the modelling sessions gives everyone an opportunity to potentially learn new modelling skills and to hear at least a portion of the requirements details, but still requires communication of the overall requirements to everyone on the team and potentially makes it harder on stakeholders due to the risk of them having to repeat themselves for the changing makeup of the modelling team.
Strategy #2. Do a bit more up-front architectural modelling.
Figure 2 depicts the process goal diagram for the Identify Architecture Strategy goal. This Inception goal describes how we will identify an architecture strategy, or potential strategies, for producing a solution for our stakeholders. As with requirements, larger teams will often invest a bit more effort in initial architectural modelling to ensure that the team understands their strategy for producing a solution. This means they are likely to address several view types and potentially capturing a bit more detail.
Clicking the diagram opens the interactive DA Browser where you can learn more about all goals, decision points and options of DA.
In the case of both requirements and architectural modelling, the larger the team the more likely you are to capture your models in a more sophisticated manner. For example, smaller teams are likely to use inclusive modelling tools such as whiteboards and paper (e.g. sticky notes and index cards) whereas larger teams may also choose to use software-based tools to capture their work.
This greater investment in up-front modelling, and in capturing that work, helps to build a stronger understanding within your team of what needs to be done and how you intend to do it. This common understanding will make coordination within the team easier later on and thereby reduce project risk.
Strategy #3: Do a bit more initial planning.
Figure 3 depicts the process goal diagram for the Develop Initial Release Plan goal. This Inception goal describes how we will approach creating an initial plan for our team. Although the details will emerge throughout Construction, we still should think about how we’re going to work together and the general timing of that work. As with modelling, the larger the team the more likely it is that they’ll want to invest time in thinking things through. At a minimum your initial release plan should identify major dependencies that you have with other teams, the cadence(s) (in particular the iteration length(s)) adopted by your sub-teams, any major sync up events (such as interim planning and modelling sessions), and even your projected end-date.
Clicking the diagram opens the interactive DA Browser where you can learn more about all goals, decision points and options of DA.
Strategy #4: Adopt more sophisticated coordination strategies.
Figure 4 depicts the process goal diagram for the Coordinate Activities goal. This ongoing goal describes how we will coordinate our activities within our team and with other teams within our organization. As we described early, the coordination strategies that you adopt within your team become more sophisticated as your team size grows. A small team can operate with non-solo work strategies, daily coordination meetings, and by visualizing their work via information radiators. Medium size teams will need to hold a second coordination meeting across the teams, a “scrum of scrums” (SoS), and may need to start moving towards more sophisticated integration strategies (see below). Large teams will need to go beyond an SoS to adopt more sophisticated coordination strategies such as Architecture Owner teams, Product Owner teams, and an internal Management team.
Clicking the diagram opens the interactive DA Browser where you can learn more about all goals, decision points and options of DA.
Strategy #5: Adopt more sophisticated testing strategies.
Figure 5 depicts the process goal diagram for the Accelerate Value Delivery goal. This Construction goal describes how our team will ensure that our solution is ready to be deployed. This goal addresses testing, configuration management, documentation, and deployment aspects of development. As we discussed earlier, team size is often driven by complexity – the more complex the problem domain being addressed, or the more complex the technology infrastructure being used, the greater the need for additional people to address those complexities. These greater complexities also drive the need for more sophisticated approaches to agile testing and quality assurance, potentially including a parallel independent test team (which SAFe calls an integration team).
Clicking the diagram opens the interactive DA Browser where you can learn more about all goals, decision points and options of DA.
Strategy #6: Integrate regularly.
Regardless of team size, agile team strive to integrate their work regularly. Better yet, they do so constantly via the practice of continuous integration (CI). Because integration becomes harder the larger and more complex your solution is, and because large teams tend to work on such problems, integration tends to become more difficult the larger your team is. Integrating the work of ten people is reasonably straightforward, the work of fifty a bit harder, the work of several hundred much harder. As a result you may need someone(s) in the role of Integrator, one of DAD’s secondary roles, who focuses on integrating the overall work of the team (or sub teams as the case may be. People focused on integration will often work closely with any parallel independent testing efforts you have underway and will often be one of the people doing such testing.