The book “Collaboration Explained” by Jean Tabaka was published in 2006 and had been on my ‘books to read’ list for quite a while before I finally got my hands on it. Jean Tabaka specialises in Agile software development and has worked closely with a host of businesses and teams to implement Agile methodologies. In “Collaboration Explained” she describes how to best run projects in an iterative and collaborative fashion.
The key focus of the book is on working with self-organised teams, empowering teams to make their own decisions. Tabaka’s core point is that this ’empowerment approach’ requires a different leadership style; a ‘servant’ leader whose role is to facilitate instead of the ‘command-and-control’ leader who leads the troupes and tells them what to do.
The book explains in great detail some of the ways in which one can help create self-organised teams and foster a culture of collaboration:
- What makes a collaborative leader? – In “Collaboration Explained”, Tabaka explains the core aspects of facilitative leadership: “as a profession, facilitators work as guardians for teams. They manage a collaborative process that guides decision-making, consensus building, and productive team outputs (…). A facilitator owns the process, not the decisions for which the process paves the way.”
- Collaborative teams that are self-organising – Naturally, in order to create a collaborative culture one needs a team that feels confident and empowered to work in a collaborative and self-organised way. The book contains references to Agile authors such as Pete McBreen and Jim Highsmith who introduced a shift in thinking about the role of project managers; instead of prescribing tasks for the team to execute, their role should be much more focused on defining a ‘mission’ and on building relationships within the team.
- Defining project collaboration events – A lot of the chapters in “Collaboration Explained” are dedicated to the artefacts of collaborative project and product management. Good examples are planning meetings and Scrum sprint planning meetings (see Fig. 1 and Fig. 2 below). At times I felt that a large part of the book was spent on how to best prepare and manage meetings, but I can imagine that many readers will find these practical pointers helpful.
Main learning point: “Collaboration Explained” wasn’t exactly the book that I hoped it would be. I hoped for more practical advice on empowering teams, giving the team the confidence to make decisions and on how to best create one project or product team. Too often I see occasions where managers are prescribing tasks for others to execute on whereas I really believe in shared responsibility, feeling accountable for the same mission in equal measure. I was therefore hoping for more suggestions on how to nurture such a mindset on an ongoing basis.
However, “Collaboration Explained” is great for readers who are fairly new to Agile development or who wish to learn more about effective meetings. On those aspects, the book provides a great deal of detail on concrete Agile artefacts and on how to get the most out of team meetings.
Fig. 1 – Planning Meeting Cautions (from “Collaboration Explained” by Jean Tabaka, p. 55)
- Avoid extended status sharing
- Make sure information sharing is specific to the purpose of the planning
- Plan, don’t build
- Don’t finish a plan without defining actions to support it
Fig. 2 – An example overview of a Scrum Sprint Planning Meeting (from “Collaboration Explained” by Jean Tabaka, p. 57)
- Who is the product owner for this Sprint’s Product Backlog?
- Who is in the project team for this Sprint?
- What other stakeholders maintain “skin in the game” of this Sprint?
- What is the full set of items in the Product Backlog to be considered for this Sprint?
- What is the length of this Sprint?
- What concerns does the team have about the Product Backlog and the length of the Sprint?
- Based on these concerns, what changes must be made to the Product Backlog?
- What is the final priority of the items in the Product Backlog?
- What priority items from the Product Backlog are being placed in the Sprint Backlog?
- Given the items placed in the Sprint Backlog, what are all the risks to be managed during the Sprint?
- How shall the project team report its progress and risk management during the Sprint to the Stakeholders?
Related links for further learning: