How to create a Chapter in an Agile Organisation
How to get Chapters going by making them for the people and by the people.
I was at a meetup recently that focused on how to set up an Agile Chapter. The meetup started with a “show and tell” from the participating organisations. One by one, using flashy presentations, graphs and even movies, they showed us how they had designed their Agile Chapters. Each group painted a picture of neat functional groupings, metrics and clear responsibilities. Like all good command-and-control scenarios, each Chapter had a Chapter Lead. The Chapters also enjoyed HR powers to manage “resource” deployment and performance.
I was so shocked that I left before it was my turn to present our approach. Usually, I have no trouble presenting a different perspective, but this time I felt such agreement in the audience about the structured approaches being presented that I just felt too alien — too weird.
Later, trying to understand my misgivings, I put together the following analysis.
Top-down
Why would you tell people to set up an Agile Chapter? Have we learnt nothing about autonomy and motivation? The whole idea of Scrum is based on self-managing teams, experts in determining what needs to be done to achieve a goal. You would expect the same to apply to establishing a chapter.
In my experience, a top-down approach is in fact the best way to ensure the whole endeavour will fail. It starts with managers being given a mandate and a budget. They set up Agile Chapter meetings with the best intentions, only to see them lose steam over time. And when developers lose interest, managers often turn to mandating attendance with controls and sanctions. Which makes the whole thing even less interesting - a positive feedback loop, but not in a positive sense.
The way I see it, an Agile Chapter arises from a need, and developers will only invest time in a chapter if it tackles that need.
What is that need? The need is to share knowledge. Most developers have a deep need of sharing and managing knowledge across teams. In my experience, Scrum teams, in their journey to mastery of their craft, reach a stage in their journey when they recognize the advantages of collaborating with other teams.
That is not to say that management should just stand by and do nothing. If management should notice the need for sharing and managing knowledge, there is nothing wrong with encouraging developers to create an Agile Chapter. The key is not to tell developers to develop a Chapter but to invite them.
Management can offer this invitation by:
making developers aware of the need,
facilitating the Agile Chapter, by for example providing space and time. And pizza.
If this does not spark action, I think management should start by looking at the level of autonomy in the teams. Do teams feel they have the room to invest in an improvement such as an Agile Chapter? Or are they continuously under pressure to deliver user stories?
A Chapter Lead
In the same vein, why on earth would a group of high-performance self-managing professionals, used to working in a Scrum setting in which hierarchy is discouraged and leadership is a shared act, need someone to lead the Agile Chapter? Wouldn't it be realistic to expect the same kind of self-management in the Agile Chapter as in the teams?
From my experience, having one person in charge trying to keep up with the needs of all chapter members is tough and prone to create a bottleneck.
Or in the opposite extreme a true servant leader, versed in coaxing alignment and delegation, I would expect this person to have little to do. So why would you create such a position? Couldn’t alignment and delegation come from management directly?
Finally, we must consider the human factor. Just creating the position, whether it be implemented well or not, has a psychological effect on those participating. Having someone appointed as the leader discourages people from taking the initiative, simply because there already is someone appointed to do so.
In contrast, I have been involved in Chapters without a Chapter Lead where leadership became a shared passion. It was a pleasure to see how leadership varied as time passed by in a kind of organic relay, depending on the subject at hand and the time available to the different people. There was always a pool of enthusiastic people ready to take up the mantle and support each other in that role.
Silos
During the meetup, I was struck by the way Agile Chapters were set up along strict and clear-cut job description lines.
Just like with the idea of segregating leadership in a single hierarchical role, I feel that we should also be terribly careful about segregating knowledge along the lines of job descriptions. One of the things we try to achieve with Agile is broadening the interests and skills of our developers. I worry that by setting up Agile Chapters this way we are actually reinforcing silos, which to me is just about the ultimate nemesis for Scrum.
Again, I think the need of the developers should be the only driver of the subject of an Agile Chapter. Sure, this will probably result in most chapters focusing on a functional area, such as front-end development. But it leaves room for other possibilities.
Take for example a developer working in a place where developers and testers have clear-cut roles. This developer is convinced of the importance of having some testing expertise to increase team flexibility and effectiveness. Wouldn’t it be wonderful for this person to be able to join the Testing Agile Chapter? Isn’t this precisely the kind of innovative thinking we try to encourage with Agile?
Taking this thought further, I think it would be interesting to use the variety of job functions involved in an Agile Chapter as an indicator of healthy T-shaped skills in an organisation.
Another example, an organisation wrestling with implementing Continuous Integration. Wouldn’t it make sense for developers keen on that subject to set up an Agile Chapter to address that need? Whatever their expertise? Even more interesting, wouldn't it also make sense for this Chapter to disappear once the continuous integration was realised?
Flexibility is the key here. It is all about keeping the rules as simple as possible and trusting those involved to make the best choices. Chapters should be open and dynamic, allowing anyone interested to feel free to join. Those involved should determine the subject to focus on.
HR powers
Maybe the biggest surprise for me was the idea of adding HR powers to the Agile Chapter. The idea is to have Chapters take responsibility for things like performance reviews, hiring people and even for managing ‘resource’ deployment.
My immediate reaction is that this conflicts with the self-management of the individual teams. Members of a team create a synergy geared towards a Product Goal and a Sprint Goal. Members of a team depend completely and intimately on each other to realise value, which in my opinion makes a team the most suited to reviewing the performance of its own members. Why would you take this out of the teams? This also holds true for ‘resource’ management. Who knows better what the needs are of a team than the team itself?
To me, this feels like an organization trying to hold on to its traditional roles and responsibilities.
An Alternative
The first step we must take with setting up an Agile Chapter is to be very clear about the goal. Like I mentioned above, Agile Chapters are meant primarily as a tool to promote knowledge sharing between teams that may not otherwise easily find each other.
The knowledge to be shared will mainly consist of technical dependencies between teams and shared code. But I imagine there will also be other interests, such as for example:
a common voice regarding policy,
setting out standards and capturing best practices.
All these kinds of knowledge share one characteristic: they arise from a need for synergy between the teams. As such, they form a context that can only be approached by the teams together.
That should be the one and only focus of an Agile Chapter. Everything else is a distraction, and as Scrum tells us, focus is essential for success.
The second step should be providing enough room for the Agile Chapter to shape itself and function. Allow it the autonomy to discover its own needs and to develop mastery.
Everything else, like Chapter leads and HR powers, are just fear, making us cling on to the command & control, process-driven way of working. Afraid of the unmanageable nature of self-organisation and organic leadership, we very creatively try to find new ways of setting up those trusty hierarchical structures which give us the feeling of control.
A Chapter lead makes it so easy to fall back to unproductive practices such as setting out roadmaps, demanding status reports and tracking metrics.
HR powers, so clearly an example of centralised control over ‘human resources’, continues a familiar tradition of management divorced from the human aspect.
And that is precisely the thing we are trying to change with Agile. Agile is about people and interactions, placing people above other matters, especially process-like matters. People are chaotic and strange and unreliable, but they have surprising strength. With Agile it is that strength that we are trying to unleash. Humanising our organisations is one way to unleash that strength. Keeping self-organisation and self-management firmly embedded in the teams ensures that humanity.
Trying to remove these responsibilities from the teams maintains the ‘human resource’ idea alive.
I think we should have faith in Scrum and in leadership as something that happens organically, especially with serious professionals. No one at that level likes to be told how to do things.
Like the Tameflow framework puts it:
Leadership becomes an act, and is no longer the privilege of a single role