Post on 16-Mar-2018
transcript
Giovanni Asproni email: giovanni.asproni@zuhlke.com twitter: @gasproni linkedin: http://www.linkedin.com/in/gasproni
Scaling Agile Done RightXP 2017, Köln, Deutschland
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/
• Context specific shortcut strategies • Give flexibility but maintain some
consistency • Can produce better decisions • Allow for synchronisation “on the fly”
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