Self-managed teams in Agile software development, Can it actually work?
Updated: May 4, 2022
I see it in many organizations and heard a lot about the benefits and success of self-managed teams working in the Agile environment. For some organizations and their managers, the change can be liberating, whereas it might be a pain in the Ass for others.
Providing a team of people the responsibility and accountability on all project aspects, such as planning and scheduling the workflow and managing their daily tasks, can be challenging (to say the least).
During my career, I was involved in many Agile transformations that involved creating self-managed teams for various reasons (which I will cover in a future article) that failed because the people involved did not have the necessary mindset and motivation to participate. In addition, there were always the common issues you would expect to have in this team form:
The team failed to move forward without a specific leader.
One or Two people with the most experience and technical knowledge ended up doing most of the work, while others were left beyond.
Team members were only wanted to focus on the technical aspect of the project and failed to communicate with other team members.
Team members have not felt comfortable telling other people what to do.
Some team members look to be assigned tasks and do not take the responsibility to take one step forward and do it as part of the collaborative team effort.
So Self-Managed teams can work in the Agile environment? Does it mean these teams cannot make an effort to be Self-Managed? The answer to the first question is ‘Yes' I see it all the time and across different organizations and with different types of people working on various projects. And what about the second question, can they make it? The answer again is ‘Yes’; they need help.
I find it very helpful to conduct an initial meeting with the team to discuss the main aspects of the project; it includes a review of its content, setting its goals, and ensuring the group has 100% of information related to both the technical and business aspect related to the project. In addition, I use this meeting to ensure the team members feel comfortable with all the information shared in the forum, answer their questions and help the team set ground rules with key stakeholders attended in the meeting such as the project manager, Development manager, etc.
As a consultant, Manager, or Facilitator (it all depends on the role I have in the project), I can work with them to define the significant project milestones that will gap between the team technical efforts and the business goals. However, I always let them determine how they will work together. Now, if you’re practicing the concept of “Self-Managed” teams and if you’re in a lead or managerial role, keep the genuine concept of “Self-Managed” teams by delegating most of the responsibility to the team that is supposed to have all the necessary skills, motivation and goals to succeed.
After the project starts, the team that is just beginning to practice with this concept will most likely have some difficulties that demand external help and guidance, so it will be a good idea to have weekly sessions with each team member to discuss her or his issues and potential contribution to overall team efforts. Based on my experience, I can say that such sessions will have a significant (positive) impact on the team and its individuals. One example that I can share is a team build from a majority of programmers, and a single tester that is the primary job was to create test plans and let other team members make the automated tests; as you may know, some programmers found it very annoying to invest in tests while other team members are not. In one of the 1:1 sessions, I discovered that he has a vast knowledge in Java that he can use to take more responsibilities in the team, automate some repetitive work, and investigate the CI reports, which help other team members appreciate his contribution to the team.
In addition to the technical focus in these sessions, the conversation must include other non-technical aspects such as handling conflicts in the team, Time management, and more. Remember, providing them with the tools to manage these topics will allow them to focus more on execution and not on other issues that they may not have the means to handle at this specific time.
The last thing I want to address is the trust between team members, which is even more critical for a self-managed team. Some teams share common hobbies, interests, and even technical approaches that create the personal relationships that are so important when working so closely with each other. So, my tip here is that you should always aim to make your Self-organized teams with groups of employees that share the same area of interest. Also, try to increase team trust by using different techniques that the team respects. For example, in the sprint review meeting, congratulate them for the team collaboration that led to the success; another example is the sprint retrospective. Ask what works for the team to reinforce good behavior and discuss what team members find challenging to help make changes.