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.
Nice article !
I just disagree with one “cheating” aspect: Teams (even young and inexperienced ones) need to have the chance to fail in order to learn.
So if you are as a coach study them in oder to find areas “where the team can reasonably decide”, you are hindering them to grow. Of course you can tell them what you suggest but they decide !
In my eyes as a coach it’s not part of your responsibility to make decisions or find proper areas for them to decide.
Let them do the job and they will learn from it. Even if they miserably fail.
Just my 2 cents
Thank for your comment, you’re #1 on this blog 😉
In theory I fully agree with you. Before this project I did exactly what you’re saying: explain what I would do, and let the team democratically choose. But in this project it appeared that bad decisions were too many. The team had quite some pressure to deliver to the market on time with a minimum set of features, and couldn’t do it.
You’re right, mistake is the best place to learn. But I think that sometimes we need to find a compromise: if the project fails completely, nobody learns, and change is not adopted. At least, you have to make sure that mistakes are detected and corrected before consequences are too bad. But how can we accelerate this in the general case?
I agree I’m probably too extreme in this article (I’m learning). At least, it’s leading to discussions. And I’d be happy to hear about potential solutions or approaches for such cases.
Well speeding u the process of learning is having good retrospectives of course.
And the results should be visible to everyone so that the teams (best the Scrum master) can follow up and ensure that the teams really do what they agreed upon.
But of course sometimes there is nothing else you can do than ‘strongly suggest’ to do thhgs now, meaning: do it or you will fail 🙂
Still I’m personally holding back as much as I can, but I must also say that I have all the backing from upper management to proceed like this 🙂
Any good way to get in contact with you via email, Skype ?