Disciplined Agile

How Does Team Size Affect the Way We Work?

Large teams will often adopt the following strategies to address the challenges that they face:

  1. Do a bit more up-front requirements exploration
  2. Do a bit more up-front architectural modelling
  3. Do a bit more initial planning
  4. Adopt more sophisticated coordination activities
  5. Adopt more sophisticated testing strategies
  6. 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.

2021 Project Management Institute Explore Scope v5.2 Explore Purpose Ideathon Ideation board Impact map Mind map Modified impact map Outcome Really round robin Value proposition canvas Explore Usage Design sprint (User experience (UX)) Epic Persona Unified Modeling Language (UML) use case diagram Usage scenario Use case User story User story map Explore the Domain Domain/conceptual model Event storming Glossary Logical data model (LDM) UML class diagram Explore the Process Business process diagram Data flow diagram (DFD) Flowchart UML activity diagram UML state chart Value stream map Explore User Experience (UX) Design sprint (user experience (UX)) User interface (UI) flow diagram UI prototype (high fidelity) UI prototype (low fidelity) UI specification Explore General Requirements Business rule Context diagram Feature statements Impact map Mind map Modified impact map Shall statement Value proposition canvas Explore Quality Requirements Acceptance criteria Explicit list Technical stories Apply Modeling Strategy(ies) Agile Modeling (informal) sessions Open space Joint application requirement (JAR) sessions Interviews Choose a Work Item Management Strategy Work item pool Task board Work item list/backlog Requirements (product) backlog None Level of Detail of the Scope Document Outcome driven Requirements envisioning (light specification) Detailed specification No document

Figure 1. The Explore Scope process goal (click to enlarge).

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.

2021 Project Management Institute Identify Architecture Strategy v5.2 Identify a Delivery Strategy Extend existing solution(s) Build from scratch (IT) Build from scratch (Citizen Development) Configure a commercial package Extend a commercial package Select an Architecture Strategy Existing proven architecture Multiple candidate architectures Single candidate architecture Explore the Architecture Discuss Event modeling Hackathon Minimum viable product (MVP) Mob programming Model Open space Proof of concept (PoC) Spike Apply Modeling Strategy(ies) Agile modeling (informal) sessions Interviews Joint application design (JAD) sessions Model-driven development (MDD)/computer-aided software engineering (CASE) Open space What-if discussions Model Technology Architecture Architectural stack diagram Cloud architecture diagram Network diagram Threat model UML component diagram UML deployment diagram UML state chart Model Business Architecture Business process diagram Capability map Data flow diagram (DFD) Domain/conceptual model Event model Logical modules diagram UML component diagram Model User Interface (UI) Architecture UI flow/wireframe diagram UI prototype (high fidelity) UI prototype (low fidelity) Investigate Legacy Assets Collaborate with asset owner(s) Reverse engineer models Run regression test suite Read overview documentation Analyze data sources Read source code Read detailed documentation Level of Detail of Architecture Document High-level overview Executable interface specification Detailed interface specification Detailed specification No document

Figure 2. The Identify Architecture Strategy process goal.

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.

2021 Project Management Institute Plan the Release v5.2 Source of Plan Self-organizing team Team leadership Manager facilitated Manager-driven Scope of Plan Product/solution Release Scheduling Strategy Continuous delivery Cost driven Date driven Timeboxed Scope driven Level of Detail of the Plan Rolling wave High level Detailed None Choose Schedule Cadences Internal releases Iteration length Phase duration Production releases Estimating Strategy Educated guess by an experienced individual(s) Educated guess by team Similar-sized items Relative mass (grid) valuation Planning poker None Function points Cost set by stakeholders Choose Estimation Unit Relative points T-shirt sizes Normalized points Hours Capture Plan Burndown chart Burnup chart Business canvas Cost projection Desired outcome(s) Gantt chart (detailed) Gantt chart (high level) Iteration schedule Milestone schedule PERT/GERT chart Ranged burndown chart Ranged burnup chart Staffing plan Table Value projection

Figure 3. The Develop Initial Release Plan process goal.

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.

2021 Project Management Institute Coordinate Activities v5.2 Share Information Nonsolo work (pairing, mobbing) Informal reviews Formal reviews Individual (solo) work Artifact Ownership Collective ownership Disparate ownership Coordinate Within Team Coordination meetings/scrum meetings Just-in-time (JIT) modeling Just-in-time (JIT) planning Look-ahead modeling/planning Regular conversations Status meetings Visualize work Facilitate a Working Session Agile modeling session Open space Big room planning Joint application design (JAD) sessions Coordinate Across Program Architecture owner team Common cadences Coordination meetings/scrum meetings Divisor cadences Facilitated working session Management team Open spaces Product coordination team Product owner team Program manager/coordinator Scrum of scrums (SoS) Visualize work Coordinate Across the Organization Enterprise professional as team member Enterprise roadmaps (detailed) Enterprise roadmaps (light) Enterprise service teams Facilitated working session Coordinate Release Schedule Continuous deployment (CD)/release stream Regular releases/release train Release windows Unique project releases None Coordinate Between Locations Move team to a single location Gather physically at critical times Adopt collaborative tools Ambassadors Boundary spanners

Figure 4. The Coordinate Activities process goal.

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).