To the most expert project managers, Scrum release management is paradoxical, complex but intensely rewarding. I’ve never seen a great project manager say that he or she can implement Scrum or Agile method easily—but they can do so effectively with the right team.

Why could Agile Scrum be so difficult to implement?

Here are 5 reasons I think that project managers find it difficult to use if you don’t have the right team:

1. It’s intensely collaborative from the client to the team member. Discussions and meetings make up about 50% of the whole project development.

2. You have a rigid set of roles that some people find stifling or hard to stick to. Sometimes, they find that their work is only confined to these roles and they don’t collaborate well. See how it can sometimes be paradoxical?

3. The team is supposed to self-manage. They have to stick to their roles while the client isn’t looking but be able to communicate readily at the end of each sprint.

4. The project design must be responsive. It’s like taking on a new project every sprint where you have to add to something that should have been working from the start.

5. The team has to be experts, senior developers and people who have lots of cross functional skills and knowledge. As you can see, you need an exceptional team of people to get the project done at all if you want to use Scrum.

Given all these conditions and difficulties (without the problems of the project itself), how does Agile managers manage their cyclical releases? For large projects that encompass hundreds of people, how do they produce a working software project that doesn’t conflict with everyone else?

I’ve had the privilege of seeing how a company was able to do so with a 450+ professional team working on a global enterprise healthcare product. Here are the best practices I’ve seen them use and suggest you do yourself:

1. Use the scalability feature of Scrum Release Management and define the activites at different levels.
This meant that some parts of the project had to be done outside the sprints. Coding, design testing, reviews, integration and acceptance happened within the sprints while analysis, refinement and architectural definition happened outside.

2. Get exceptional project managers.
Since Scrum Release Management (and Scrum in general) operates through a defined set of roles for each team member, the rigidity can cause the model to collapse under the weight of micro management. A project manager can bring vision, interpersonal skills , tech savvy, planning abilities and coordination skills that can bring all the roles together in a unified sprint that can cut across all levels of the project.

3. Always think in cycles.
Remember when I said that Scrum essentially makes you work a new project on an existing, working software every sprint? That means you have to be ready to define, initiate, plan, execute, monitor and control the results each sprint.

4. Develop the right teams with the right mix of skills.

With a huge number of stakeholders, it’s important that you make sure that each team gets a cross-functional mix of people. Scrum Release Management teams typically have more responsibility since they’re handling the product shown to the owner.

5. Standardize as much as possible.

6. While Scrum is supposed to be Agile, a huge team needs as much standards and fixed points allowed to function properly.
Meeting agendas for each team can be fixed so that everyone knows what to expect and things run more smoothly.

7. In the end, the scalability of Scrum Release Management is what made Siemens successful with such a large team.
At some point, the Agile Scrum levels even helped to make the project finish earlier since they standardized as much as possible.