For the past years, I have been working in a self-steering development team. For the past months, due to team setup changes, I have noticed that we are less and less aligned about certain cases and I feel like we are not really working autonomously. I have captured that feeling on one of our last retrospectives by adding a post-it: “Are we ALIGNED, and do we still have AUTONOMY?". This started an interesting conversation which I want to try to capture in this brain dump.

Aligned autonomy is a management approach that empowers individuals or teams to make decisions independently while aligning them with the broader goals and objectives of the organization. Aligned autonomy seeks to strike a balance between granting autonomy to teams or individuals and maintaining alignment with the organization's overall strategy.

In aligned autonomy, teams or individuals are given the freedom to make decisions and take actions within a defined scope, without constant supervision or micromanagement. However, these decisions and actions are aligned with the broader objectives and goals of the organization.

Aligned autonomy can help organizations to foster innovation, creativity, and ownership among teams or individuals while still maintaining a clear line of sight to the organization's objectives. It can also help to improve employee engagement and job satisfaction, as individuals or teams are given more autonomy to make decisions and take ownership of their work.

However, aligned autonomy requires a high degree of trust and communication between the organization and the teams and between the team members aswel. It is important for the organization to provide clear guidelines, goals, and feedback to ensure that the autonomy is used effectively and aligned with the overall objectives of the organization.

. That’s why I want to list up things that I think are key to reach better alignment:

To achieve this level of alignment, effective communication among team members is very important.

. It helps team members to exchange ideas, clarify expectations, and share feedback. When team members communicate effectively, they can build stronger relationships and develop a deeper understanding of each other's strengths and weaknesses. This understanding leads to better collaboration, increased trust, and a greater sense of cohesion.

However, effective communication does not come naturally to everyone. It takes practice, patience, and the willingness to listen and understand other team member’s perspectives. Therefore, it is crucial for organizations to provide opportunities for team members to practice their communication skills regularly.

It is important to foster a culture of open communication and providing proper communication training.

I have noticed that the inability to listen to what others have to say is something that occurs a lot. The devaluation of the other’s opinion while he or she is explaining it, because you value the opinion you have in your mind higher is very destructive for conversations. A proper training technique for this is the ‘Active listening training’. This training focuses on teaching participants how to listen actively, paying attention to both verbal and non-verbal cues, and asking for clarification to ensure that they understand the message well.

A consequence of not being ‘fully present’ in the conversation and valuing your opinion higher than the other’s, is that those conversations often escalate into tense situations and mostly end up in a conflict. A proper technique for this, is something that I often use in practice. Even if I think my opinion or solution is better than the other, I actively suppress that feeling and even devaluate my own opinion. This way I am able to have a clearer view on the solution and remove friction from the conversation. This way the conversation can continue everyone is able to properly explain what they have in mind.

There’s so many aspects in communication that can be helpful, but I feel like that could be a post on itself.

Goals are an essential component of team alignment and cohesion. When teams have clearly defined goals, it helps to create a shared sense of purpose and direction among team members. This shared sense of purpose can help to build trust, improve communication, and increase motivation within the team.

Having well-defined goals also helps team members to understand their individual roles and responsibilities within the team. This clarity can help to prevent confusion and conflicts that can arise when team members are uncertain about their roles.

Goals can also provide a basis for measuring progress and success. When teams have specific, measurable goals, they can track their progress and celebrate their achievements along the way. This sense of progress and accomplishment can help to increase morale and motivation within the team.

They can also help to provide focus and direction for the team. This focus can help to prevent distractions and ensure that the team is working towards a common objective.

Giving feedback is essential for improving team cohesion and team performance. When team members provide feedback to one another, they can identify areas for improvement, celebrate successes, and build trust.

Constructive feedback helps team members learn from mistakes, correct errors, and adjust their behaviors or actions. By receiving feedback, individuals can also better understand their strengths and weaknesses, leading to greater self-awareness and personal growth.

Ultimately, giving and receiving feedback creates a culture of continuous improvement and accountability, leading to better team cohesion and higher performance. By embracing feedback as a tool for growth and development, teams can become more cohesive and achieve their goals more effectively.

While giving and receiving feedback is essential for team cohesion and performance, it can be difficult for some individuals. Many people are hesitant to provide feedback for fear of being perceived as critical or confrontational. Similarly, receiving feedback can be challenging, as it requires individuals to be open and receptive to constructive criticism.

Another reason why people may struggle with giving and receiving feedback is due to the emotional impact it can have. Criticism or negative feedback can be difficult to hear and can sometimes be perceived as a personal attack. As a result, individuals may become defensive or resistant to feedback, hindering the growth and development of the team.

In conclusion, while giving and receiving feedback can be challenging, it's essential for team cohesion and performance. By recognizing the importance of feedback, approaching it with a growth mindset, and providing training and support, individuals and teams can overcome these challenges and create a culture of continuous improvement and accountability.

As I said before, our team operates as a self-steering or self-organizing team, with decisions made collectively rather than by a technical lead. This allows us to achieve consensus on solutions and encourages team members to take ownership of their work. Our organization provides clear guidelines and constraints that set boundaries for our decision-making, which is documented in our 

. This handbook is an open-source document that any team member can contribute to, making it a valuable resource for the entire organization.

Our technical guidance is provided through a 

that outlines tools and technologies that can be used, adopted, and those that are off-limits. Additionally, our security department works to protect us from potential threats to our software company.

However, it's important to note that some of these guidelines are more flexible than others. Over the past year, we've noticed that some of our guidelines have become more restrictive, shrinking the boundaries of our playground.

Aligned? No, I don’t think so. I feel like our individual goals are not really contributing to our team goals. I think our communication skills need some practice and as a result of that, giving (and receiving) feedback is something that needs some polishing.

But can we become more aligned? Certainly, yes! We’ve been doing 360 feedback moments where we practice how to give and receive feedback. We’ve been having very open retrospectives, that sometimes even end up in almost shouting at each other. But that’s good, it’s feedback.

Autonomy? I think less and less. With the shrinking playground we get due to more constraints and less guidelines, I feel like we’ve become less autonomous. But at the same time, I do think the organization is giving us the room to provide feedback and try out new and exciting stuff. It’s just that we as a team, don’t really embrace that opportunity. Maybe because we are not really aligned yet.

Are we aligned and do we have autonomy?

In software development, collaboration and knowledge sharing are crucial for creating high-quality software and building a cohesive team. In this blog post, I'll explain what mob programming is, how we implemented it in our team, and the pros and cons we discovered.

I want to explicitly say that a lot of it is opinionated and mainly based on my own personal experience.

To start off, I want to answer this question with what 

For me, mob programming is a practice that involves a group of developers working together on a single task or project. The idea behind this practice is to bring together the collective knowledge, skills, and experience of the team to achieve a common goal and level.

During mob programming, the team members work together in a collaborative and supportive environment. One person serves as the 

, who is responsible for writing the code, while the other team members contribute by reviewing and providing feedback, mostly called 

 being the driver or navigator(s), and the process continues until the task is completed.

The main benefit of mob programming is that it 

 and communication among team members, leading to 

. It also helps to distribute knowledge and expertise across the team, making it easier to resolve issues and prevent mistakes. Additionally, it can be an 

effective way to onboard new team members

 or bring everyone up to speed on a project.

However, there are also some potential downsides to mob programming. It can be challenging to maintain focus and engagement among team members, particularly for those who may not be as interested in or passionate about the task at hand. There may also be issues with power dynamics, as some team members may feel hesitant to speak up or offer their opinions in the presence of more dominant personalities.

Despite these potential drawbacks, I have found mob programming to be a valuable practice for improving collaboration and productivity. In this blog post, I will explore the benefits and challenges of mob programming in more detail, and offer some practical tips for teams looking to implement this approach.

Three years ago, our team consisted of six developers. Most of the time we were split into two groups to focus on different tasks. The team configuration varied between two and four developers per team. We aimed to avoid any individual developers working on a task alone, although this was not always feasible given the 

 of a development team. Our workload typically consisted of maintenance, bug-fixing, and support for other teams. Aside from feature development.

Through our experiences, we learned that certain tasks were better suited for collaborative work, or "mobbing", as it facilitated knowledge sharing among team members. We found it beneficial to begin each task in a mob, and when necessary, split into smaller groups to work on two tasks asynchronously. Even seemingly easy or tedious tasks were not exempt from mobbing, as we recognized that the process of working together ultimately resulted in much better outcomes than individual work.

To promote (domain) knowledge sharing and ensure that all team members were exposed to a variety of tasks, we rotated developers between tasks whenever possible. Ultimately, by prioritizing collaboration and knowledge sharing, we were able to achieve better outcomes and a more cohesive team.

Over the past two years, a lot has changed within our team. We've had two different product owners and a new scrum master, and the team of developers has undergone a lot of changes as well. Some developers have left, while others have come on board, bringing new ideas and perspectives to the team. However, with these changes, some of the team chemistry that had existed before has been lost. In order for a very collaborative to be successful, the members need to be on the same page or be able to reach consensus when in disagreement. The new team setup has led to more disagreements and longer discussions, resulting in less productivity. Whereas before we were able to build multiple solutions to find the best one, we now just build a solution without a real consensus.

Another major change that has occurred in the past two years is the COVID pandemic. We used to work one day from home every week, but now we only have one office day per week, and the rest of the time we work remotely. 

While remote working has its benefits, I've found that remote meetings can have downsides. In a remote environment, group conversations often result in one person speaking at a time, and side conversations are not able to happen. These side conversations can often lead to better outcomes for the general discussion.

I would say we are still a collaborative team, working together on the same tasks. But, sadly, we’re not really 

 anymore. Often times someone takes the keyboard for hours and hours and the other persons in the call are just there as rubber ducks for the ‘driver’.

 and I still think that what we are doing right now is still better than everyone working on their own and making pull requests and doing code reviews.

I do think there are a few things you should do when you are mob programming:

The time between being the driver of a navigator shouldn't be too long. This keeps everyone in the mob engaged and give you the opportunity to switch between roles often enough. I’ve experienced that the rotation time should be somewhere around 

We’ve experienced with shorter and longer rotation times aswel, but sometimes switching roles takes some time, which results in you being in a certain role for a very short time.

 because people tend to zone out a lot more.

 rotation time for mob programming is on the lower side of this and I would say it’s 

. This grants you enough time in your role and has some buffer for switching between roles.

Often times, there are multiple technical ways to reach a certain goal or task. In a mob there are different people, resulting in different skill sets and opinions. To see if one solution is better than the other suggested solutions, I would recommend you build them all as a mob. It's easier to see what's better when there's code in front of you and it also makes the implementation details visual. This way, the discussion can be more in dept and this will lead to an implemented solution that is carried by the whole team.

When you rotate a lot, sometimes it feels like you're not programming a lot of consistent hours. Though, I've experienced that our mob sessions tend to take a lot longer than when you are programming on your own. Breaks are very necessary to keep focus and energy in the mob, which is very important. Plan your breaks with tools, like I suggest later in this article, so you don't end up being in a very long session.

We've tried multiple setups. With the whole team (6 people) and split up setups. I think the ideal setup to keep everyone engaged is a mobbing group of around 3-5 persons. This will make everyone inside the mob feel engaged.

 for screen sharing. Good quality is necessary in a remote environment for the others to see what the driver is writing. Pop also has the ability to take over the screen which can be useful sometimes. They both have a pencil which allows the users to draw on the screen, which can be useful for designing or clarifying things out.

 makes the rotation process seamlessly. It creates mob branch when the command 

 when his session is over, this commits and pushes his changes as WIP to the created branch. When the session is over, 

 can be used to squash the commits and remove the remote branch created. This has been very helpful to us as we're mostly doing trunk based development.

 has an intuitive UI to set up your mob session and notifies you when to rotate.

 after each session will make you do better in the next session, and isn't that what we all want?

The key takeaways for me with mobbing is to get as little interruption and to maintain focus as much as possible. This something that has to be achieved by the whole team, not only the developers. Clear sprint goals and good refinements can lead to a better performing team. Tools, like described before, can prevent interruption inside of the mobbing process. Mobbing, as well as working in a team in general, required good communication skills. These skill differ on personalities and even on seniority. Mobbing is a very good practice to become better at communicating with other people. 

And the last conclusion, just do it, it's awesome!

Why you should start mobbing

In the fast-moving world of creating software, where each piece of code and every decision matters, there's an unstated pressure to know everything. The worry of seeming less capable often lingers, causing professionals to avoid a simple yet powerful phrase: "I don't know." In my journey as a software developer, I've realized the importance of admitting when I don't have all the answers.

In a work setting, there's an unspoken expectation that experienced individuals have extensive knowledge in their field. Admitting not knowing something can feel like a hit to one's professional image. The fear of seeming inexperienced or less capable often leads individuals to avoid telling the truth.

Thinking back on my own experiences, being honest about what I don't know has been a game-changer. In the early stages of my career, I gave in to the pressure of always having the right answers. However, as I grew in my role, I realized that showing vulnerability is a sign of strength, not weakness.

Saying "I don't know" isn't admitting incompetence; it's recognizing one's current knowledge limits. It's a declaration of authenticity and a commitment to truthfulness. As professionals, we should understand that the quest for knowledge is an ongoing journey, and no one can be an expert in everything. Showing the boundaries of your knowledge is in my opinion essential in your professional career.

In project environments, avoiding admitting uncertainty can have harmful effects. It can lead to misguided decisions, wasted time, and, ironically, a lack of professional growth. By creating a culture that encourages honesty about our limitations, we build an environment where learning is prioritized over pretending to know everything.

Acknowledging what we don't know is a sign of professional maturity. It shows a readiness to learn, adapt, and collaborate. When we accept our vulnerabilities, we open the door to constructive dialogue and create an atmosphere where others feel empowered to do the same.

In the ever-changing world of software development, the pursuit of knowledge should come with a healthy dose of humility. Saying "I don't know" isn't a defeat; it's an invitation for collaboration, learning, and growth. As professionals, let's break free from the idea of always being right and understand that true strength lies in our ability to be honest about our limitations. In doing so, we pave the way for a culture that values authenticity and encourages continuous improvement.

"Je ne sais pas"

The boundaries

Fostering a culture of honesty

Conclusion

I would love some feedback!

More braindumps

Are we aligned and do we have autonomy?

Why you should start mobbing