Agile management practices, which include Scrum, were originally conceived for use in small, collocated teams. Ideally, a team’s size falls between five and 10 members, all of whom are located in the same place. With no obstructions to communication, that arrangement facilitates ongoing collaboration and optimizes the team’s productivity. According to research, teams in such an environment prefer highly visible communication and coordination tools that reinforce collaboration. For example, physical task boards, dry erase boards, Post-It notes, index cards, and other “manual” devices are among the most effective ways to track projects for Scrum teams working in ideal conditions. However, most complex development environments contain too many variables for small team, manual agile techniques to work effectively. As team members increase, the attributes that make manual agile so effective in small teams don’t hold up. In fact, they actually become impediments in large-scale installations. So how do team members uphold Scrum’s tenets of communication and collaboration when they’re spread across offices, buildings, or even continents? And how they replicate manual agile in this context? Facing the challenges of scaling teams usually requires an agile tooling solution. While there are several solutions available, including my own company’s product, ScrumWorks Pro, I will focus on the most common challenges to scaling manual agile. Large Groups and Collocation Collocation is essential for teams using manual agile. When everyone works in the same vicinity, posting requirements and updates to a physically visible location is a great solution. But once a project team grows in size beyond 10 or 20 members, it begins to lose its impact. In short, as the visibility of the posting decreases as a team member’s geographic distance increases. As the group grows larger and larger individual group members will become farther and farther from the single physically posted requirements backlog. In this case, some group members will be hindered by the lack of convenient access with requirements and prioritization decisions. In scaled agile, individual teams could employ a taskboard, which would be a convenient information radiator for all team members. But others — such as related teams — would struggle to stay informed of the team’s progress and impediments, since the board is outside its members’ immediate proximity. This is a problem that happens even when all group members are collocated on a single floor, within relatively close proximity to the backlog. Furthermore, this situation is amplified when team members are spread over several floors in a building or in different buildings altogether. Clearly, this problem does not go away when teams are distributed across countries, continents, and time zones. Management of Data in Large Groups One of the most common ways small agile teams store data, including stories and tasks, is with note cards. This marks another challenge of manual agile for large organizations. Regardless of the benefits of using note cards and sticky notes, it quickly becomes impractical when dealing with large projects. Consider a project comprised of thousands of stories and ten times as many tasks. The task of sorting and organizing that many cards would be impossible. Suddenly, these cards would only be of value to those in possession of them, since creating and maintaining copies of thousands of cards only compounds the implausibility of the situation. Considering that cards are often revised, archiving would need to occur daily. In general, standard data organization functions are made difficult in large agile projects that use manual tools. Visibility and Reporting Issues Manual, paper-based tools work so well in small agile projects because they increase visibility and communication for everyone involved in the project. As mentioned before, however, using manual tools on large agile projects actually obscures data rather than make it more visible. In such a scenario, reporting will struggle to keep up with real-time updates and may convey inaccuracies, thanks to the time-consuming process required to manually compile statistics. The backlog is a living, breathing artifact, with new cards being added, existing cards being altered, and obsolete cards being thrown away. For instance, a swing of 20 to 30 percent in total backlog effort from sprint to sprint is not unusual. For minimal summary statistics (net change), manually re-summing backlog effort is necessary each and every sprint. If more detailed change statistics are required, a manual change log of activities must be kept in tandem with the note cards.