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.3 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 Backlog Management Strategy Lean backlog Agile backlog Requirements (product) backlog Unsequenced 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.

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.

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.

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.

Copyright Project Management Institute All Rights Reserved Plan the Release v5.4 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 Artificial intelligence (AI) generated Similar-sized items Relative mass (grid) valuation Affinity estimation 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 forecast 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 forecast

Figure 3. The Develop Initial Release Plan process goal.

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.