Giovanni Asproni email: giovanni.asproni@zuhlke.com twitter: @gasproni linkedin: http://www.linkedin.com/in/gasproni

Scaling Agile Done RightAgile Manchester 2017, Manchester, UK

My Experience

• Mostly projects involving 4-5 teams • One involving ~80 teams with ~700 developers • One involving ~120 teams with ~1300 developers • One involving 8 teams with ~80 developers

In One Slide

• Usual reasons for scaling • Gotchas • Prerequisites • How to do it

Fundamental Law Of Scaling:

Scaling up amplifies the bad and makes the good more difficult

Scaling up creates new problems

Why?

Before scaling up make sure you have some compelling reasons

Prerequisites

• Clear shared goals • High quality • Suitable architecture • Availability of resources • Automation • Communication • Skills • Metrics • User stories • Prioritisation and planning

Clear shared goals

High quality standards and ability to manage technical debt effectively

A system / software architecture suitable for scaling up the number of people and teams

Availability of hardware and software resources

Automate all the things

Effective and efficient communication channels

https://www.flickr.com/photos/qousqous/57607074

People with the necessary skills (managerial, and technical)

Appropriate metrics in place to measure productivity, quality and other interesting aspects of the project

Ability to create good user stories

Very good prioritisation, planning and coordination skills

Prerequisites Recap

• Clear shared goals • High quality • Suitable architecture • Availability of resources • Automation • Communication • Skills • Metrics • User stories • Prioritisation and planning

First Paradox Of Scaling:

Most projects are scaled up because they don’t fulfil the prerequisites for scaling

Second Paradox Of Scaling:

Projects fulfilling the prerequisites for scaling have a lesser need to scale

Try This First!

How do we do it?

• How much “faster” can we go? • How much more process structure is necessary? • How do we add more people and teams? • Feature or component teams?

“Adding manpower to a late software project makes it later [...] The number of months of a project depends upon its sequential constraints. The maximum number of men depends upon the number of independent subtasks. From these two quantities one can derive schedules using fewer men and more months. (The only risk is product obsolescence.) One cannot, however, get workable schedules using more men and fewer months.”

Amdhal’s Law

http://asprotunity.com/blog/scaling-agile-how-many-teams-are-too-many/

Process and structure

The only roles successful software products ALWAYS need are programmers and users. Everybody else is optional

The role of methodologies should not be to control people, but to help them become more efficient and effective

The right methodology depends on the context of the company and the project. One size does not fit all.

Large scale Agile frameworks have limited applicability

“My strong and increasingly passionate argument was that SAFe is not only a betrayal of the promise offered by AGILE but is a massive retrograde step giving the managerial class an excuse to avoid any significant change.”

David Snowden

http://cognitive-edge.com/blog/safe-the-infantilism-of-management/

1. Understand What Your People Do 2. Reinforce Integrators 3. Increase the Total Quantity of Power 4. Increase Reciprocity 5. Extend the Shadow of the Future 6. Reward Those Who Cooperate

Informal communication can go a very long way

What’s In It For Me?

“A complex system that works is invariably found to have evolved from a simple system that worked.”

Adding People And Teams

Involve the team in the decision of increasing team size. Then increase it incrementally and measure the effects using the metrics in place

When Adding A new Team

• Make sure scope is well understood, and with minimal dependencies on other teams

• Start small. 3-4 people maximum with the required skills • The team is given all the necessary resources to perform their

job • There is an architect available • Measure the effects. If necessary, revert the decision and

remove the team from the project

Team Organisation

• Feature • Component • Mix

Component teams with virtual feature teams

Recap In One Slide

• Usual reasons for scaling • Gotchas • Prerequisites • How to do it

Final Thoughts

• Scaling up may not be necessary • Often customers want predictability, not speed • Methodologies purpose is to help people do a good job,

not to control them • Methodologies are context dependent. Large scale ones

even more so