Scaling Scrum: Lessons from the Trenches

While in Paris, I had the opportunity to attend a talk by Scott Ambler, a fellow Canadian, on “Scaling Scrum – Lessons from the Trenches”.

Scott’s view is that Scrum by itself is not a complete solution for product development, which of course is true (duh!). The front end and back end of the business process also need to be involved and there needs to be some governance structure in place among other things to make sure a large distributed and complex development activity can be executed using Scrum and other Agile methods.

Anyone who works in a large organization understands the challenges of taking a powerful framework like Scrum and making it work across hundreds of teams across every time zone to deliver a single product. Knowing this is one thing, but being able to build an organization around large scale Agile practices for complex product development is another.

Scott listed the scaling factors that a large organization, with complex product development needs to keep in mind. Each of these factors is listed, according to Scott, in order of difficulty from easiest to hardest and each factor is scaled from simplest to most complex.
• Geographical distribution – co-located vs. Global
• Compliance Requirements – low risk vs. critical, audited
• Team size – under 10 developers vs. 1000’s of developers
• Domain Complexity
• Organization Distribution – collaborative vs. contractual
• Technical complexity – homogeneous vs. heterogeneous legacy
• Organizational complexity – Flexible vs. Rigid
• Enterprise complexity Project focus vs. Enterprise focus portfolio management, asset management, reuse management

In addition to the core Scrum roles, Scott also mentioned additional roles which may be required for Agile in the large. These roles complement the core Scrum roles and exist to handle special situations that arise in large complex development.
• Architecture Owner – Facilitates technical discussions, Coordinates technical discussions between teams
• Domain Expert or Technical Expert – someone who is not required in the core team full-time, but may be needed from time to time to handle specific domain is-sues like security, reliability, or other “ilities”.
• Independent Tester – Focuses on complex testing efforts, working parallel but independent of the team
• Integrator – Responsible for product builds end to end
• Specialist – Narrow specialties focus like business analysts

One BIG caution when considering these complementary roles; When making a transition to Agile from traditional project management methods, the addition of complementary roles can derail your agility focus, especially in the early stages. My advice is to apply pure Scrum as much as possible and when an impediment surfaces that requires the addition of one or more of these roles, only then should you consider how and why that additional role is required. The first objective is to change the culture.

Scott also talked about the lifecycle process with key milestones. These include:
• Inception – One or more short sprints + stakeholder consensus
• Construction – Many short sprints producing a potentially shippable solution each sprint with sufficient functionality
• Transition One or more short sprints to make the product production ready
• Production – deployment into the customer’s domain.
These phases are natural in large scale complex product development, however, the perfection vision of having a pure end to end delivery in a single Sprint should never change. This vision of perfection keeps us moving forward and forces us to think and act according to the Agile principles.

Contact me if you would like to get a copy of the slides. I can’t find them on-line yet.


One thought on “Scaling Scrum: Lessons from the Trenches

  1. I like these ideas. I have been struggling with figuring out how to take the concepts from come from the basic CSM course into our ALU situation with many SCRUM teams workign together to deliver a single product. Some of these ideas are very helpful. I also like the cautionary note to only add new roles when there is a real need, and not artificially creating roles and overhead.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s