Team self-selection (aka Squadification) is a growing ‘opt-in’ approach to building successful Lean/Agile teams, with resulting reports of increased effectiveness. It’s even starting to be a suggested standard approach for a SAFe kickoff.
Are there lessons we can learn from this in our wider Organisational Transformation approaches?
Based on Em Campbell-Pretty’s recommendation, I have been reading Sandy Mamoli & David Mole’s book
Creating Great Teams over the holiday period. In it, they make a powerful argument for allowing people to choose their own teams, rather than have management disappear into a locked room for three days and try to work out all the possible combinations within a complicated set of constraints, before finally emerging with a configuration that somehow doesn’t work for anyone.
Instead, they argue, articulate the constraints/design principles (for example: cross-functional teams, with a high degree of co-location, largely based on features as represented by Product Owners, with the most experienced people strongly distributed between the teams) and hold a team marketplace, where Product Owners each represent a team in the future structure, and everyone else has to choose which team to work on, and who they’re working with. You do it on a single day.
Those of you who have been through UK University might recognise the setup: it’s Freshers’ Week Societies’ Fair all over again.
I first heard of Team Self Selection via Marcus’ experience at Tradera (Sweden’s version of eBay), where they distributed the technical folks in a 40 person group into 5 feature-based teams. It seemed to me (in 2013) that where you needed to (re)organise people into teams, this sounds crazy, but it might just work.
Reading Em’s experiences of this in a SAFe instantiation of a Release Train, both on her blog and in her book, hearing about WWII bomber crews self-selecting and listening to arguments that autonomy supports better outcomes, while imposing a structure is a poor way to kick-start self-organisation, I’m gaining confidence that this is a repeatably viable way to structure a new team of teams, or restructure one that has acknowledged problems.
But I think there’s a fractal level above this which is interesting.
The Problem of Transformation
I’ve been worried about Organisational Agile Imposition for a while, reinforced by what Dan Meznick calls
The Agile Industrial Complex. It’s the same thinking: it’s counterintuitive to kickstart a mental model of self-organisation, and respecting the views of those at the sharp end — even when you take a Dreyfus Learning Journey into account that will always start with rules — with an all-in directive:
We will all be Agile from Next Thursday. It’s not as if enterprises are democracies that only change on a unanimous referendum. That would ensure that nothing ever changes, and we surely don’t want that.
The counter problem is this: given that we’re convinced that Lean/Agile is a path to Better at an organisational level, when we wish to run even an experiment that achieves team of teams benefits, then avoiding local sub optimisation implies alignment of approach. Everyone needs to do it. Starting together. Even if this is joining up teams who are each already running an Agile approach, the alignment will likely mean undoing some of what each are doing. What each has identified as an optimisation in their local context, but which is a sub optimisation to the system.
So how do we combine these contradictory thoughts? How do we avoid imposing Transformation on a group when we all need to work together with a high level of alignment of approach?
Self-Selecting Organisational Transformation
It’s highly unlikely (and more so if we’re running an experiment) that an entire enterprise will transform into Lean/Agile ways in one go.
Transformation is a process. Different parts of the organisation will start at different times and progress at different rates. And during that process, some of the the organisation will be adopting new mental models and some will not.
So how about this:
During the process — and starting from the very first team and then the first team of teams — we only accept volunteers into our Brave New World. Our first Agile team, and our first Agile Release Train, are composed entirely of people who want to be there, and are opting in on the understanding of what it’s going to be.
That way, for those who are directly impacted by the change, we effectively do have a unanimous referendum result.
In our new group, we can embed new cultural norms with much less inertia; we set the expectation up front, and volunteering to be in the group implies accepting those norms. Once we’re up and running, in this part of the organisation, anyone we add or move over from the rest of the organisation will be moving into a group where our desired behaviours and mental models are the default case, and we can reasonably expect each new person to either have them already, or to rapidly adopt them to avoid cultural dissonance.
At last, we’ve tipped the playing field and cultural hegemony is working in our favour.
What About The Non-Volunteers?
Of course, those who don’t volunteer must still be afforded respect for this to be a choice, and not another management fix; the advantages of
better ways should need no structural enhancements to sell themselves anyway.
While the whole organisation is on the journey of transformation, each person makes their own way at their own speed, and generally reaches an
Aha! point at their own time. Having an in-house model to provide a daily illustration that working life can be better will surely help, but should not be used as another blame and shame lever for later adopters.
One element of that respect is that there will likely continue to be some parts of the organisation, some products, some components, that have not yet undergone a flip; bi/multi-modal delivery is sure to be a reality for quite some time. Working in those later-adopting parts should still be a respected and valid career option for the time being, while the whole organisation is on the journey.
It may be that your organisation will always have some groups where plan driven work is a valid approach, and the effort in treating that work as complex and uncertain will always be a hard argument to make. Or it may not. In which case, when the last few areas are clearly coming for change, it will be time to have a respectfully frank and open conversation with the people who just don’t want to work in new ways.
This is an experiment, and at the moment, at best, a thought experiment. It’s simply the next step along a journey of self-selection, with all the same mental models and theoretical explanations informing it. It very roughly enables some of Simon Wardley’s wonderful Pioneers, Settlers, and Town Planners model, allowing people to find which part of that model they fit in, while its overall Overton Window shifts in the organisation over the course of the adoption cycle. I remember having a conversation with Bob Marshall at the first Lean Agile Scotland in 2012 about the idea of running with a parallel organisation, and pouring people over from one side to the other to enable greenfield cultural norms in a brownfield organisation. And it’s entirely valid to accuse me of stealing wholesale from Kotter.
But it’s not (to my knowledge) been tried in this way — as a pure volunteer-driven shift that takes the team self-selection principle and takes it up a level — in a software-intensive organisation.
So: who wants to be a Settler on this idea and try it?
Comments below if you’ve seen anything like this, if you’ve tried it, or if you’re willing to give it a go.