Learning from the Toronto Scaling Workshop

Last week we had a Scaling with Agile Workshop in Toronto.

More and more I am convinced this scaling workshop is necessary for many people to apply Scrum well, in their business model.  They need to work through how to make it work in their context.  And many of the issues in ‘making it work’ have to do with ‘scaling’.

Of course, not every person, team or company has ‘scaling’ problems.  So, ‘scaling’ solutions do not need to be included with Scrum (for everyone).  Also scaling issues vary widely and differ from situation to situation, even in the same company.

I like to define scaling and the related words precisely.

Scaling as such, is limited to having 3 or more Scrum Teams working together on one Product.

‘Scaling’ does not include all the problems of implementing Scrum in the larger company (outside the Team).  Scaling is not ‘wider agile adoption’ (eg, within one company.  Scaling is not the problem of distributed teams (although often scaled teams include ‘distributed people.’  (I use other words for other problems that often come along with scaling or are included in ‘scaling’ by others.)

Scaling, as I define it, is a common problem. Often, as suggested, other issues occur; cultural change, agile transformation, distributed scrum, etc, etc.

In the Workshop, we gave the attendees a basic framework, and an approach to defining their scaling challenges.  We tried to focus on scaling proper (as defined above), but we also took questions and real issues with ‘scaling’ more broadly defined.

It was impressive how the problems differed, yet all were ‘scaling.’

To give them background, we discussed patterns in general, ScrumPLOP.org, classic Scrum scaling patterns, LeSS, and SAFe.

The key concept is: how do we try simple patterns that fit the specific needs of your situation?  Let’s see if we can make some progress today. And let’s try not make things overly heavy or complex.

With a few key concepts, they could then easily design solutions to most of their pressing problems.  At least they did, together and with our help.

One last key concept.  The real energy is inside the Team.  All the bright people running the scaling stuff do not add any value directly; so far as  the customer can tell.  They may be necessary, but not essential.

So, divert some energy from the Team(s) to the ‘Scaling stuff’ only temporarily.  Remember to focus again on the Team(s).  The real power of scrum is in the Teams.  The real power that you have is in the Teams, not in the scaling structures.  Never forget that. (Yes, a few individual contributors or managers had some key ‘power’ with their good ideas, but I say again… the real power is in the Teams.)

 

« « Halifax: Public Impediment List || Organizing a small-ish company to do Scrum and ‘regular work’ » »