This document summarizes Giovanni Asproni's experience with scaling agile projects and provides recommendations. It discusses that scaling often amplifies problems and makes things more difficult. The key prerequisites for successful scaling are clear goals, high quality standards, suitable architecture, adequate resources, automation, communication, skills, metrics, user stories, and planning. When scaling, teams should start small and incrementally increase size while measuring effects to avoid issues. Overall, scaling may not be necessary, and methodologies should help not control people.

1. Giovanni Asproni
email: giovanni.asproni@zuhlke.com
twitter: @gasproni
linkedin: http://www.linkedin.com/in/gasproni
Scaling Agile Done Right
XP 2017, Köln, Deutschland

4. 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

5. In One Slide
• Usual reasons for scaling
• Gotchas
• Prerequisites
• How to do it

8. Fundamental Law Of Scaling:
Scaling up amplifies the bad and
makes the good more difficult

9. Scaling up creates new problems

10. Why?
Before scaling up make sure you have
some compelling reasons

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

12. Clear shared goals

13. High quality standards and ability
to manage technical debt
effectively

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

15. Availability of hardware and
software resources

16. Automate all the things

17. Effective and efficient
communication
channels
https://www.flickr.com/photos/qousqous/57607074

18. People with the necessary skills
(managerial, and technical)

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

20. Ability to create good user stories

21. Very good prioritisation, planning and
coordination skills

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

23. First Paradox Of Scaling:
Most projects are scaled up because they
don’t fulfil the prerequisites for scaling

24. Second Paradox Of Scaling:
Projects fulfilling the prerequisites for scaling
have a lesser need to scale

25. Try This First!

26. 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?

27. “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

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

29. Process and structure

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

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

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

33. Large scale Agile
frameworks have limited
applicability

34. “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/

36. • Context specific shortcut strategies
• Give flexibility but maintain some
consistency
• Can produce better decisions
• Allow for synchronisation “on the fly”

37. 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

38. Informal communication can go a very
long way

39. What’s In It For Me?

40. “A complex system that
works is invariably
found to have evolved
from a simple system
that worked.”
Adding People And Teams

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

42. 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

43. Team Organisation
• Feature
• Component
• Mix

44. Component teams with
virtual feature teams

45. Recap In One Slide
• Usual reasons for scaling
• Gotchas
• Prerequisites
• How to do it

46. 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