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.

Copyright Project Management Institute All Rights Reserved Coordinate Activities v5.3 Share Information Nonsolo work (pairing, mobbing)Informal reviewsFormal reviewsIndividual (solo) work Artifact Ownership Collective ownershipDisparate ownership Coordinate Within Team Coordination meetings/scrum meetingsJust-in-time (JIT) modelingJust-in-time (JIT) planningLook-ahead modeling/planningRegular conversationsStatus meetingsVisualize work and workflow Facilitate a Working Session Agile modeling sessionOpen spaceBig room planningJoint application design (JAD) sessions Coordinate Across Program Architecture owner teamCommon cadencesCoordination meetings/scrum meetingsDivisor cadencesFacilitated working sessionManagement teamOpen spacesProduct coordination teamProduct owner teamProgram manager/coordinatorScrum of scrums (SoS)Visualize work and workflow Coordinate Across the Organization Enterprise professional as team memberEnterprise roadmaps (detailed)Enterprise roadmaps (light)Enterprise service teamsFacilitated working session Coordinate Release Schedule Continuous deployment (CD)/release streamRegular releases/release trainRelease windowsUnique project releasesNone Coordinate Between Locations Move team to a single locationGather physically at critical timesAdopt collaborative toolsAmbassadorsBoundary spanners

Figure 4. The Coordinate Activities 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 #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).

Copyright Project Management Institute All Rights Reserved Accelerate Value Delivery v5.5 Optimize Team Borrow team member Drop team member Focused solution team (FST) Generalizing specialists Utilize existing talents Optimize Work Avoid over production Make work visible Make workflow visible Quality checklist Optimize Flow Align cadences Introduce slack Reduce batch size Focus on finishing Reduce work in process (WIP) Remove delay Remove handoff Remove handback Choose a Deployment Strategy Continuous deployment (CD)/release stream Continuous deployment (CD) - internal only Regular releases/release train External release as appropriate Internal release as appropriate Single release Plan Deployment Continuous deployment (CD) Continuous deployment (CD) - internal only Active stakeholder participation Continuous planning Plan late Automate Infrastructure Automated regression tests Continuous integration (CI)/Continuous deployment (CD) pipeline Feature access control Feature toggles Monitoring instrumentation Self-recovery Self-testing Manage Assets Configuration management (CM) Version control Shared folders Choose an SCM Branching Strategy Branch by customer/organization Branch by developer/workspace Branch by module/component Branch by phase/quality gate Branch by purpose Branch by task/story Branch by version/release Single branch (trunk based) Choose Testing Strategies Automated regression testing Behavior-driven development (BDD) Continuous integration (CI) End-of-life-cycle testing Integration tests first Manual testing Parallel independent testing Test-after development Test-driven development (TDD) Choose Testing Types Accessibility testing Alpha/beta/pilot/canary testing Component testing Database testing Exploratory testing Functional testing (FT) Performance testing Prototypes Quality attributes (ility) testing Security testing Simulations Split (A/B) testing Story testing System integration testing (SIT) Unit testing (UT) User acceptance testing (UAT) User experience (UX) testing User interface (UI) testing Workflow/scenario testing Verify Quality of Work Static analysis Dynamic analysis Nonsolo work Definition of done (DoD) Informal reviews Formal reviews Maintain Traceability Generate from tools Generate from test code None Maintain manually

Figure 5. The Accelerate Value Delivery 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 #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. 

Related Resources