One Team, Two Teams, Many Teams: Scaling Up Done Right with Giovanni Asproni

This is a past event

47 people went


We are delighted to join forces once again this month with the ACCU Conference (, which is taking place at the Bristol Marriott Hotel City Centre, 9-13 April.

Our speaker is Giovanni Asproni. Giovanni works as a Principal Consultant for Zuhlke Engineering in London. He has been helping software companies and teams become more successful for many years by providing consulting, training and advice, as well as coding, to projects of all sizes. He is both a frequent conference speaker, and organiser. He is a past Chair of the London XPDay and the ACCU conferences, the Industry & Practice co-chair for XP2016, and the Conference Chair for SPA 2018 and SPA 2019. He is a member of the ACM and the IEEE Computer Society, and contributed to the book 97 Things Every Programmer Should Know, published by O'Reilly.


Scaling up software projects is one of the trends of the moment—many companies, big and small, try to do that to increase the speed of delivery of their projects.

However, scaling up can be quite difficult (even going only from one to two teams), especially if it is done focusing on the wrong aspects – most companies give too much weight to formal structures and processes (e.g., mandating the use of SAFe, LESS or other frameworks), and not enough weight to other aspects that would give a bigger bang for the buck: e.g. removing friction, improving communication channels, setting clear goals, delegating responsibility and accountability, etc.

In this session I’ll share my experience in successfully helping companies to do the right thing in projects ranging from two to about eighty teams, and I’ll offer some tools that you will be able to use right away in your projects.

The session, among other things, includes:

• A description of what needs to be done right before scaling up

• Strategies on how to decide when to add new people to a team and new teams to a project

• Things to consider when deciding the structure of the teams (eg feature vs component teams), and its relationship with the shape of the system

• How to use simple rules to allow teams to collaborate productively

• An explanation on why each project has a upper bound in its ability to scale, and what to do about it