The Agile Architect
Improving Agile With Self Organization
Agile proponents promote self-organization. But what does this really look like? It turns out that achieving real self-organization takes...organization.
I recently attended three agile conferences, which got me thinking about what self-organization means in an agile environment. However, it wasn't the content of the conferences that intrigued me. It was the structure of the conferences themselves and the extent to which they allowed participants to self-organize.
Let me explain.
The first conference was a traditional single-track conference. The self-organization by the participants was simple: You could attend the session or not and, once in attendance, you could stay or walk out.
The second conference was a traditional multi-track conference: Conference organizers chose the tracks and the speakers for each track. Self-organization by the participants consisted of choosing which session to attend, if any, and whether to switch to a different session.
The third conference was an open space conference. How many of us have attended a traditional conference only to discover that the hallway conversations are more valuable than the scheduled sessions? The goal of an open space conference is to replicate this as the conference itself.
An open space conference has no agenda and no set list of speakers. Instead, it has a goal or theme. The content comes from the participants. This is achieved using a light organizational framework. At the start of each day, the conference organizers gather everyone together, explain the rules of the conference and offer up a large empty schedule grid that lists the times for sessions and the rooms available. The floor is then opened to the participants who offer up topics that they will present or activities they will facilitate. They then post their offerings on the schedule in an open slot. Throughout the day, sessions may get rescheduled and new sessions may be offered as desired by the participants.
Sounds crazy, right? So what happened?
Levels of Self-Organization
Self-organization at the single-track conference was pretty simple: You could go to the conference or not. You could go to the current session or not. You could stay in the current session or walk out, which I did for one talk. Boring!
Self-organization at the multi-track conference was similarly straight-forward, with the additional flexibility that you could choose from a collection of sessions.
Self-organization for the open space conference was much deeper. Not only could we as participants make the choices above, but we could actually change the nature of the conference. And we did. At the beginning of the first day, I had one session I was prepared to offer, the schedule looked sparse, and I was wondering what we'd be doing for three days. By the time the three-day conference was over, we were all exhausted from a full and productive schedule. I had facilitated five different sessions, and they were all well attended because they were on topics that my fellow conference attendees had asked me to discuss. And likewise, I was happy to go to their sessions because they were ones that I had asked them to discuss.
At the two traditional conferences, the organizers did a tremendous amount of work to figure out what they thought the participants would want.
In the open space conference, the organizers did very little but they did it well. They provided a light-weight but well defined structure for soliciting choices and making decisions, and then trusted that the participants would find their own path. In essence, they facilitated a morning planning session by the participants who then executed their own plan throughout the day.
So what does this have to do with agile software development?
My biggest epiphany from this experience is that self-organization itself requires organization. That may seem unintuitive, but without the open space conference organizers providing some level of organization, including setting the goal, booking the venue, defining the schedule and setting the rules for offering presentations, the conference would have devolved into anarchy. By defining not the content but the structure, we had an extremely successful, meaningful experience.
As an analogy to the conferences mentioned above, when a team is told they are to self-organize according to a particular methodology, e.g. Scrum or XP, this is equivalent to the single-track conference. The team can make some basic choices but for the most part, the methodology tells them what to do.
When a team is told that they can choose their methodology, for example choosing between XP, Scrum or lean, this is equivalent to the multi-track conference. Yes, the team can make some choices, but for the most part they are still following someone else's organizational structure.
To get closer to the open space approach, a team must be given some organizational guidance but not too much. They can go through a chartering process, like the one described in the book Liftoff: Start and Sustain Successful Agile Teams by Diana Larsen and Ainsley Nies or a completely different process such as the mob programming example I described in a previous article. Chartering still calls for a facilitator who may set some light rules of engagement for the chartering discussions, but the team owns the content of the chartering meetings.
And for an even lighter touch but still closer to the open space approach, the chartering facilitator can, rather than planning the chartering meeting for the team, facilitate a team planning meeting to plan the chartering meeting.
In all the cases above, the facilitator could be someone (or several people) outside the team (like our conference organizers) or inside the team.
Self-organization is tricky. A team with no organizational structure is not self-organizing. It is anarchy. At some point, someone or some group has to accept the authority to make a decision, even if that decision is how to decide.
Dr. Mark Balbes serves as Vice President, Architecture at WWT Asynchrony Labs, and leads multiple Agile projects for Government and Fortune 500 companies. He received his Ph.D. in Nuclear Physics from Duke University in 1992, then continued his research in nuclear astrophysics at Ohio State University. Dr. Balbes has worked in the industrial sector since 1995 applying his scientific expertise to the disciplines of software development. He has led teams as small as a few software developers to as large as a multi-national Engineering department with development centers in the U.S., Canada, and India. Whether serving as product manager, chief scientist, or chief architect, he provides both technical and thought leadership around Agile development, Agile architecture, and Agile project management principles.