Self-organizing is hard work

Self-organizing teams play an important role in agile methodologies. They might also be the hardest to accomplish. Although Ximedes is structured around the concept of self-organizing teams, only in the last couple of years have we started to reap the benefits. Reaching these high-performing, self-organizing teams is hard work and a lot of practice is needed.

• Combine the right people in each team
• Infuse the team with a common goal
• Involve everyone in reaching that goal
• Practice, guide and improve continuously

As a teenager, I used to play basketball. We were a bunch of misfits always fooling around, until one coach saw potential in a few of us. He started forming a team and gave us a goal: the Dutch championship.

I remember that just the idea of being part of that changed our mindset completely. We started working really hard, got stronger and better. When someone was ill or injured, the rest of the team filled the gap. We were a self-organizing team.

Two years later and two days before our championship tournament, one of our star players broke his ankle during practice. We were devastated. Two days later we were the new Dutch champions; the team automatically adapted to the loss.

I learned a lot of that period in my life, especially how much hard work and discipline it takes to win a championship. And during my professional life, I have been applying these lessons to the teams I work with to reach the same team spirit, confidence and performance we reached playing basketball. Below a summary of the things to keep in mind when working with software development teams.

Five developers do not make a team

During my years at Ximedes I discovered certain patterns in teams. Sometimes a group of very capable developers kept on struggling with their project. Other times having a certain duo in a team resulted in magic. We started to look more closely at combining the right people instead of a just thinking about the number of front-end and back-end developers.

A common goal

At Ximedes we build bespoke software for our customers. It's their software and sometimes that makes it harder for our teams to pursue a common goal in terms of the end product. But the drive to make our customers happy is in our nature, right beside a strong drive to build quality software. In my experience creating an environment where the team feels they are part of a quality product gives everyone a more sustainable focus. In the team I work in now, we used to work with bi-weekly releases, but we slowly and organically moved to Kanban enabling us to deliver quality software at any time.

Involvement

A good product owner will ensure that there is enough attention to delivering features. The team should counterweight this with their long term attention to quality. Having quality as a common goal makes everyone feel responsible for it. In my experience this is the best way to trigger involvement from the whole team. We used to work with retrospectives, but having a common goal and the right people in the room made retrospectives obsolete. The output you would like to achieve in a retrospective is now a continuous process. We celebrate things that went well and everyone comes with suggestion for improvements for both our process and our software.

A guiding hand

Never forget that all of this is not going to happen automatically. Just as in sports, you will need a coach that overviews things, challenges, facilitates and is not afraid to make small changes. You could call this a Scrum Master, but I'm not really happy with that term. I'm convinced it's just one of the characteristics or skill sets you need from someone in your team, regardless of their role. What matters though, is that this person has good connections with the rest of the organization and is able to make things happen.

Give it time

Most of the people in this team have been working with each other for at least 2 years. Everyone knows each other, recognizes when someone is stuck and can use some help. Everyone is ready to give help and to switch roles when needed. They 'practiced' a lot with each other and are now successful. And although we now have a lot of specific domain knowledge of the project we worked on, the way we operate is not domain specific. The team knows how to build and deliver quality software effectively. Of course, a completely new domain would take time getting into, but that just means more interesting sessions in front of white boards, not a fall back in terms of delivery capabilities.

There is way more work involved in creating effective and self-organizing teams, both for the organization and the team itself. Software development is a major league profession and it takes a lot of practice to stream line people, processes and technology into something so successful that everyone wants to be part of it. I think we are doing very well

Cover photo by Randy Fath on Unsplash