A self-managed developers' team experience: what it was like

About a year ago, I had the opportunity to start a project with a team designated to be self-managed by our manager. I enjoyed this way of working and I would like to share the advantages I appreciated.

This article shares a specific way of working we used at Bonitasoft. However, I believe it is suitable reading to anyone interested in methodologies, whether Agile or not. I will sometimes talk about technical tools and technologies that developers are familiar with, but this is definitely not mandatory to understand my points here.

Context

At Bonitasoft, our Continuous Integration environments (CI) were getting old: we were using Jenkins 2.0, configured with XML files under version control in a dedicated repository, which was separate from the repositories containing the source code to build and test.

Maintaining those environments was laborious. Not all of our developers shared the necessary knowledge, and it was not possible to scale easily when we had parallel developments (because of the team’s growth, or because we we becoming more productive!)

Five of us in the team really wanted to rewrite the whole thing from scratch, with newer tools and technologies.

We took the opportunity to create a new project and experience a new way of organising ourselves, with a methodology by developers, for developers.

The advantages of self-management

Autonomy is a mark of trust

Our manager constantly seeks ways to keep developers engaged. He felt that leaving us as much freedom as possible to lead and carry out this project was a way of keeping us motivated.

This did not mean we had no reviews to show other teams. On the contrary, every other week we had to demonstrate our progress, and most of the time, we were pretty proud of it.

Freedom to organise appropriately

At Bonitasoft, we use Atlassian Jira to manage our tasks, support tickets, bugs, and more. We decided not to introduce a new tool for this project.

However, we did decide to use a specific Jira Project (in the Jira meaning of “project”) for this initiative, with its specific workflow, that we deliberately chose to be light and non-restrictive. After all, our tools are here to serve us, not the contrary. We created our own dashboards to follow our progress.

This allowed us to easily create as many tickets as we needed, delete them when necessary, resolve them, and close them, without the pain of having to fill in many fields that would not necessarily match our workflow.

Our Kanban board with our lightweight workflow.

Freedom to choose our tools

Rewriting a whole Continuous Integration environment for the entire R&D team is a lot of work, and choosing the right tools for the job was key. We took time for technological research. We investigated several tools, framework, ways of implementing security, means of writing proper Jenkins jobs / pipelines, and so on. We also became “experts” on Docker containers and their integration with tools like Gradle.

The freedom - and responsibility - of choosing the proper technologies allowed us to train ourselves with some cutting-edge, current, trendy technologies. We also feel very proud of what we have achieved with these tools.

Everyone shares the same level of knowledge

There was nothing revolutionary in the contribution workflow. Like everywhere else at Bonitasoft, contributions are made via basic Github Pull Request review workflow, very familiar to developers (not just at Bonitasoft, but pretty widely).

Where we decided to innovate was to do our contribution reviews together as a group, and the decision to merge each Github Pull Request was agreed upon together as well. This might look like a strong constraint, but the benefit is huge: the main contributor gets the chance to explain the technology discovered, the difficulties encountered, why this implementation was considered the best option. The reviewers get the chance to ask questions, propose improvements - and discover new stuff.

Merging a contribution was done when everyone agreed.

If the contribution needed to be shared with developers in other teams, it was explained or demonstrated during the next advancement status, or in a dedicated technical talk, if appropriate.

Freedom to be as involved as needed

With five in the team, we had the option to shift our engagement, to have times to be more involved in developing the tasks we agreed to work on, and other times to pull back and just follow and review the developments made by others.

This allowed us all to work according to our interests and individual schedules, and keep each other motivated by working on items we were really excited about.

Problems encountered and how we managed them

Keeping CI environments up-to-date and adapted to our evolving needs is a never-ending project.

As with many long-term projects, keeping motivation up all the time is not easy. There were moments where little work was done from one week to the next, because the tasks were not the that interesting or exciting to work on, or because we were working on other concurrent priorities.

However, having the option to be less involved from time to time, and then come back later with more enthusiasm to try new things allowed us to have a good overall delivery rate, as well as pride in the work we accomplished.

Recommendations for success with this approach

Don’t stick with something you took that worked and seemed trendy at the time, but that does not fill the bill later on.

For example, we tested and used a Jenkins plugin that allowed us to provision Docker containers on the fly. We were happy using it for a while. Then came the moment when when needed to use it at a larger scale, and we decided it was not the right tool for the job. So we simply changed to another implementation.

My point here is that you shouldn’t hesitate to change, remove, or refactor something that you thought was exactly right 2 months earlier. Constant reassessment is normal in software development. It is ultimately more important to adapt the tool to the needs, than to preserve our pride.

Here’s what I feel are key requirements for a successful team:

• Self-managed team members should be able to choose to work together, not be selected by an outside person to create a team
• Self-managed teams must accept that some team members will not be involved as much as others, and this is not a problem. In fact it can be an advantage.
• Working as a self-managed team can only be successful if you have the full trust of your manager that you know what to do and how to work best together.

Summary

I have been working on a self-managed team for a year now, and I still am.

It’s great to have had the chance to experience so much freedom.

I’m proud of the work I’ve been able to contribute on an individual level, and even more proud of the work we’ve done as a team.

And technically, I have grown and learned a great deal through sharing with my coworkers.

I recommend every developer who loves what they do to try working in a self-managed team - try it if you can and see how it works for you.