The Service1st, Tree, and Lapsec projects were all so complex that the usual project planning and control practices had failed. All of the projects required the close synchronization of multiple activities. All of the projects had multiple teams working simultaneously to produce a demonstrable product within a short period of time. And all of them were floundering as the teams tried to figure out how they should start and how they should recast their situations and create actionable plans.
Out-of-the-box Scrum doesn’t have practices that address the complexities of every project. However, ScrumMasters have only to refer back to Scrum theory to find Scrum practices that can be readily adapted to handle even the most complex projects.
The thread running through the Service1st, Tree, and Lapsec projects was self-organization. The complexity of the situation was too great for individuals to be able to settle on a plan of action. My job was to that of a coach or a mentor. I taught the teams how to deal with increasing levels of complexity through self-organization within and supported by the practices of Scrum. I reduced the complexity to a degree where the team could cope and function. I helped staff the team with people who had all of the skills needed to understand the complexity and commit to resolving it.
In the Service1st project, I reduced the confusion in the situation by focusing the team on just the next 30 calendar days. I asked the team to take one piece of functionality and figure out how to make it work. I asked the team to forget the rest of the release and to focus on a few concrete steps, assuring them that the rest would fall into place. I gave them permission to ignore their task-based assignments in the meantime. The team was able to focus and implement the foundation upon which the rest of the release and future Sprints depended.
In the Tree project, I reduced the complexity of the situation by staffing the teams so that all the expertise necessary to develop a piece of functionality was included within each team. Each team would be able to resolve any dependencies it had on other teams. Most members of each team were able to focus on the work at hand, while the cross-team members spent time synchronizing team progress with that of other dependent teams.
In the Lapsec project, I had to help the team practice Scrum. Lecturing on Scrum theory and practices proved inadequate in this instance. Until the team actually used Scrum to solve some of the problems it was facing, the team wouldn’t really grasp Scrum. By providing the team with an example similar to its real work, I broke through to the team and helped it understand how to use Scrum. When they entered the Sprint time-box with a real problem to solve, the team members attacked it like a pack of wild dogs. The time-box works well— as Mark Twain once said, “Nothing focuses the mind like a noose.”
The ScrumMaster applies Scrum theory to projects with different types and degrees of complexity. In every instance in which they apply Scrum, Scrum- Masters will be called upon to apply their understanding to a project’s aims and difficulties so that the ScrumMaster aptly supports the team’s efforts to achieve those aims.