“People are at their happiest and most productive if they can choose what they work on and who they work with.”
– Sandy Mamoli
Well, that’s not actually what happened, but close.
The “child” in this case was a metaphor for an early stage journey into Agile ways of working. The “car” represents anything familiar from the old ways of working.
I’ll share the rest of the metaphor but first, let me share a few related stories.
My wife loves playing the following “What if…” game,
“What if you were stranded on a deserted island, who would you rather be stranded with – person A or person B?”
If I ever get stranded on a deserted island, I doubt I could choose who I’m stranded with.
It’s about as preposterous as employees deciding what they work on, when they work on it and with who!
Or is it?
That’s exactly what happened over 25 years ago when I worked at IBM.
I was a senior software developer on a critical 40-person software project that was sputtering and about to fail. I and three of my colleagues were frustrated with our situation and the lack of progress being made.
So, we got together, hatched a plan and offered it to management. We essentially asked management to step aside and let us manage the project to completion. Without a viable alternative available and time running out on an executive commitment to the market, management capitulated and accepted our offer to help.
The first thing we did was work with all the staff to reorganize ourselves. The resulting project organization resembled a pizza pie with each pizza slice representing a different sub-team. Each pizza slice had clear responsibilities and the people that fit those responsibilities.
We did eventually succeed in shipping the project but what has stuck in mind all these years was how we managed to self-organize before it was a “thing”. We self-organized not because we were told to, but because we wanted to. We just felt there was a better way for the forty of us to work together.
About 18 years after that I was involved in another self-organization event. This time I was part of management. I personally sanctioned and sponsored what we called a “Team Creation Event” (TCE). We had started moving to Agile ways of working and needed to create 6 new Scrum teams and 2 new Kanban teams. We invited people from the Business and Technology. Most of the people from the business were there to observe and learn more about Agile ways. The rest were there to create teams and pick the work. We had an excellent Agile coach – Paul Heidema. TCE was his idea.
I said,
“A TCE sounds interesting. How many times have you done this before?”
His answer was,
“This would be the first time.”
Fortunately, I had faith in Paul and trusted him.
The practice of forming teams and assigning them work has always been the purview of management throughout the 20th century. It remains the dominant practice into the 21st century.
This practice is one of those familiar things from the old ways of working. The “car” in our metaphor.
Inviting employees to take over this practice would be tantamount to handing over your car keys to your 10-year old. At least that’s what it felt like for managers that have gone through this. Managers would rationalize that they were trained for this. It was their job. Employees were not trained nor would they want to do it if asked. These would be the typical excuses for not allowing employees to form their own teams and assignments.
However, there is a growing number of examples where management and organizations have demonstrated the courage to enable employees and staff to form teams with promising results. At the very least, it may help mitigate a protracted “storming” phase in the Tuckman model for team development.
About two years ago, my friend and fellow Agile coach, Andrew Goddard introduced me to the work of New Zealand’s Sandy Mamoli. Sandy is an Agile coach advocating what she calls “Self-Selection” of teams. She co-authored a book with David Mole called “Creating Great Teams”. It describes why self-selection is a viable alternative for creating teams, what it is and guidance on how to do it.
Andrew was eager to try running a self-selection event at a client we were serving. His enthusiasm was infectious and together, we shared the idea with our client. At the time, we needed to create 5 Scrum teams. The original plan was to have management create and assign the teams. After much consternation and debate, the management and staff agreed (narrowly) to try self-selection.
A couple of months ago, a tweet from another veteran and highly regarded Agile coach, Mark Levison pointed out a software company in California that was experimenting with self-selection practices. Redgate Software’s self-selection approach offers some great ideas and options to mitigate the anxiety associated with team self-selection.
A couple of weeks ago at the annual Gatineau Ottawa Agile Tour conference, a couple of managers from the Bank of Canada shared their experience with team self-selection. The session created a lot of buzz and questions.
The next time you or the organization you’re serving have an opportunity to create teams, why not handover the keys to your employees?
One last thought. With the emergence of autonomous self-driving cars, handing over your car keys to your 10-year old may not be so far-fetched after all!
nextchapterconsulting.ca 