Scaling Agile Done Right (XP 2017 version)
0 likes568 views
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.
![“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](https://image.slidesharecdn.com/scalingagiledonerightxp2017-170615202442/85/Scaling-Agile-Done-Right-XP-2017-version-27-320.jpg)
Scaling Agile Done Right (XP 2017 version)
- 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
- 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
- 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
- 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