How self-organized?

January 5, 2011

Agile teams are supposed to be self-organized. This can mean many things. You can decide on the architecture, the organization, the tools, the backlog, communication, rules, and so on… or you can have constraints on all or part of these items. And when we say that the team is self-organized, what do we consider as the team? Is the scrum master part of it, or an external facilitator? Is the manager, the business analyst, part of the team?

I worked on a project where a new team was set up, mainly made up of  juniors: developers, testers, analyst. People didn’t know each other, most of us were discovering agile, and we were discovering the business needs as we developed the project. As a coach, I tried to apply agile principles by the book: let the team decide on its rules, practices, architecture. I’m mainly talking about these three topics cause that’s where we had our major pain points later on. I tried to emphasize our need to keep things simple and to be able to give up anything that wouldn’t seem right. That allowed us to try things.

So we tried… We decided to use frameworks such as spring, hibernate, and aspectJ. No one had actually worked with them in the past. We could build a basic product with these, so we went on. When it came to build more complex features with more technical constraints, we estimate that these frameworks cost us about a month of work. And of course, it would be difficult to rollback, first because it would mean a big refactoring, and secondly because we always thought that the issue being fixed would be the last one. Today, even if I have a feeling that hibernate brings added value to this project, the whole stack seems like it is a lot more complexity and debt than value, and we don’t understand these bricks enough to be confident about them.

We also tried to decide on our practices. For example, one of the guys who were eager to work with agile because they had read about it, began to review others’ code. Because he had issues understanding quickly code that was sometimes written in a “personal” way, he convinced the team to use tools like checkstyle. And our style became a constraint in IDEs, on the CI pipeline, and so on. We ended up spending a lot of time on correcting style warnings, tuning the CI server to avoid builds to break because of style violations… I never was keen on checkstyle, but here it was a disaster.

Of course, I took concrete lessons from these situations: never adopt technologies that take you more than a couple of days to be confident with, use more deciders or make more people talk in retrospectives, to make sure that democracy is respected a bit more, discuss on adopted rules after a defined period, to understand pros and cons…

But more deep and important, that made me think a lot about self-organization. As I read lately in a mailing list, agile practices can only make a team as good as it is. It can’t magically create experience, happiness, know-how, intelligence. It can only help you accelerate knowledge sharing, face reality, understand real needs and cope with them, remove obstacles… So why consider that a team that doesn’t have enough maturity can take the right decision on any deeply structuring question?

Between anarchy and dictatorship, there are several cursors to tune. If teams were truly supposed to be self-organized, you wouldn’t need coaches (I also consider the coaching part of the scrum master, here). You would just give teams a white paper and let them write their own history. But we need guidance, at least to start with.

This means that, as a coach, you have to cheat with self-organization, especially with young teams:

• Convince teams using practices and tools, or just make them apply them. If you want to make them feel they adopted practices freely, don’t give them time to think before voting.
• Before letting teams decide, study them. Evaluate their maturity. If leaders emerge on some topics, it can be better to let them decide things on their own for the rest of the team. Filters topics where the team can reasonably decide democratically and freely.
• Lead retrospectives for real, organize items to talk about, lead discussions where they need to go, for the team’s sake.
• Observe on the field how practices are implemented. Be very cautious with anomalies and weak signals.
• Show, demonstrate, teach, explain the roots of practices. As I tried to show with the checkstyle example, the cargo cult is a great danger.

As any powerful tool, self-organization must be used with caution. It’s a compromise. If every tool was a fit-for-all-size silver bullet, we wouldn’t need coaching. In every situation, we need to identify trade-offs to make, and fine-tune cursors. Self-organization is one of them.

Written by Antoine Alberti Posted in agile, kanban, lean, scrum