Scrum scales with careful consideration

The myth is that Scrum is merely a methodology to be used for smaller projects.

This is a fallacy – many organizations have very successfully scaled Scrum and continues to have success with Scrum in an enterprise context. But Scrum does not scale intuitively; many of the elements of this methodology that makes it so successful such as collocation, daily scrums and the close involvement of key roles are factors that do not easily scale without some careful consideration.

Here are some ideas you should think about before scaling Scrum in the enterprise.

Scale the Scrum Roles

Scrum is dramatically different from waterfall in that roles such as ScrumMaster and ProductOwner play crucial roles that cannot be substituted with extensive documentation. Therefore, when scaling Scrum, make sure you also scale the roles of ScrumMaster and Product Owner. One way to ensure you have the proper representation of a Product Owner for multiple teams in several locations is to designate “Product Owner Proxies”. A proxy would have the same day-to-day responsibilities of a traditional Product Owner and help the team answer questions that come up during the sprint, but would be less involved in strategic work.

Create One Product Backlog

Instead of having multiple backlogs across many teams, consolidate all work on a given project into the same product backlog. This ensures that there is a common vision and understanding of the work remaining within the given project without having to manage multiple, disparate product backlogs.

Proactively Manage Dependencies

In large-scale implementations of Scrum, it is even more important to focus on identifying dependencies between and across team ahead of time. One way to help achieve this is to always plan 1-2 sprints in advance – in addition to the current sprint planning session. Obviously, your level of visivility will be less clear for these forward-looking sprints, but they do provide a good idea of the work that is coming up. By ensuring all teams adhere to this practice, a better vision of upcoming work can be communicated across the respective project teams.

Establish an Integration Team

An integration team consists of key technical members from each respective team within the project. By having members of the integration team meet on a regular basis, a common understanding of the current – as well as upcoming work – may be affecting other projects can be identified. The integration team needs to meet on a regular basis, but meeting more than every 1-2 weeks should be sufficient.

Scrum of Scrums

The Scrum of Scrums is an affective way to communicate findings between the different project teams. This team, although technically a scrum team, does not meet every day and their meetings should not be limited to 15 minutes. The key here is that during these Scrum of Scrum meetings, each team member reports to other members on any developments within their respective project that could affect other projects. In other words, this is not a status meeting – but rather a session focusing on items that may affect other projects.

Scrum Does Scale

Contrary to what may have been conventional wisdom a few years ago, Scrum is quickly becoming an enterprise-wide project methodology with a proven ability to scale across the enterprise. Although some modifications and enhancements of traditional Scrum techniques may be required, there is no reason the many benefits of Scrum cannot be implemented in larger organizations.

Share This Post:

Hide Sites