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.