How to Self-Assemble and Sustain a Self-Organising Team
The Scrum Guide defines the Scrum Team as “self organizing and cross functional.” How does one successfully create an effective self-organising team? The Scrum Guide states that “self organising teams choose how best to accomplish their work, rather than being directed by others outside the team.” A number of commentators have recently shared experiences and ideas which discuss how the core principles of self-organisation can be used to facilitate self-assembly of the team itself. These experiences also demonstrate that facilitation is a key factor to successful self-assembly and the sustained effectiveness of a self-organising team.
Mike Cohn, an early contributor to the formalisation of Scrum and one of the founding members of the Scrum Alliance, recently reported on the need for balance between facilitation and top-down guidance during the formation and life of a self-organising team. He writes about his experience of seeing facilitation turn into governance, reporting that it is easy to create mandates about working practices, meetings, and other well intended factors, however “one rule too many will push a team over the precipice” and away from self-organization. Mike warns:
For each rule, consider whether that rule alone is worth the risk. If it's not, don't put the rule in place. Also, any time you consider adding a rule to a team, see if there's another rule (or constraint on how they work) that you can remove.
In a recent article about self-assembling teams, ScrumMaster Rok Prešeren shared project experiences which illustrate that team formation is a critical factor for the sustained success of a self-organising team. He writes that the next traditional management paradigm to be transformed by Agile forces will be that of the team-formation process. He also points out that top-down team building is usually more focussed on the availability of individuals rather than competence blending.
...management should start facilitating self-assembling of a team, because on average this will yield better project results. Anyway, who knows better about perfect team composition that those who actually work on a project?
Prešeren cites the experience of Craig Larman and Ahmad Fahmy within Bank of America's Merrill Lynch (BAML) Global Securities Operations Technology, successfully facilitating 35 individuals from 5 functionally specialised groups, to reassemble themselves into 4 cross functional teams within a 3 hour session. Larman and Fahmy used logistical constraints and three cycles of facilitated self-organisation to force individuals to form teams outside of their comfort zones. The constraints placed by Craig and Ahmad were that the teams had to be well-balanced, co-located, cross-functional and cross-component. Prešeren points out that facilitation is required to guide formation and avoid nested command and control structures:
Only after the facilitators pushed the people out of comfort zone by asking them to assess team compositions against constraints, things start to change. In the second cycle the teams start to self-form, but here the natural team leaders started to use the top-down approach in team forming. Again facilitators intervention was required to prevent internal top-down forming.
Thomas Cagley, author of Mastering Software Project Management: Best Practices, Tools and Techniques, wrote a piece last year on team problems which can arise in Agile scenarios when there is top down interference with the stability of a team’s composition. He points out that Agile is built on the basic assumption that “teams will be stable and that membership and focus will not be changed during a sprint or iteration.” He writes about the importance of relationships between team members and points out that every time a team is altered, the chemistry of the team changes. He states:
Violating the basic assumptions about the composition and tenure of team members will disrupt the trust and effectiveness of the team. It will yield a group of vaguely related individuals, rather than an Agile team.
Nitin Mital of Infosys also recently discussed the success factors required for the creation of a self-organising team. He writes that the creation and successful continuity of a self-organising team comes from a three step-process of training team competencies, coaching the team to enjoy working effectively together and continued mentoring and learning. He writes:
...a self-organizing team doesn't need "command and control," but it does need coaching and mentoring.
In the same spirit, Cagley and Cohn’s articles also discuss the need for coaches to facilitate and guide the feedback loop which helps teams self-evaluate and embrace Agile. Thomas shares an anecdote about a team which had wandered away from Agile practices and started allocating work. He points out that with the introduction of coaching and new feedback mechanisms the team was able to get on track again.
Mital reminds us that:
...building a self-organising team is an ongoing process and we're never done. Whenever a team's composition changes, we need to repeat the whole process.