top of page
  • Writer's pictureValentina Zanetti

How to Brew Self-Organizing Teams

Self-organization is the foundation of any great agile team! Find your magic potion for a great a self-organizing team!


Magic potion for self-organizing teams

In this week's blog post, I'll discuss my views on how to foster self-organizing agile teams. Self-organization is the foundation and the backbone of any and every high-performing agile team and a precondition to creating amazing digital products. When we allow and foster self-organization, we set the ground for creativity and constantly emerging new ideas. New ideas bring new opportunities and have the potential to make immeasurably impactful changes. Below you can find my views and some tips and tricks on how to foster self-organization and set the right tone for your team right from the start!


Establish Working Agreements for Self-Organizing Teams


Self-organization doesn't mean no organization. It means allowing your team agency and including them into the decision-making process on how the team is going to work together. And Work Agreements can serve as a set of guidelines that define how your team wants to work together, what they want in the working environment, and from each other to feel safe and free to learn, explore and discover.


Some of the benefits of working agreements are:

🔸Involvement and agency from the team on how they work

🔸A clear set of boundaries and guidelines to adhere to in their daily work

🔸Better alignment from the team

🔸Fewer conflicts and their easier resolution

🔸A standard of excellence set by the team for them to strive towards


As you set out into the planning and development phase of your efforts, your team will start to transition - and rather rapidly - from the forming to the storming phase of their team's lifecycle, so before you go any further, help your team set some ground rules of engagement for their collaboration later on.


Some tips on how to create a good base for your team's work agreements:

🔹Keep the list short for the first version and agree on the most important things for your team, and grow the list as the team develops

🔹Keep the document structured and rather than keeping a long list of agreements with no structure, try grouping them instead

🔹Make sure they include behavioral rules such as 'we commit to always be on time for meetings', 'we commit to being honest and transparent', 'we commit to being understanding and helpful to our team members', ...

🔹Make sure they're easily accessible and highly visible to the whole team

🔹Revise them regularly and build upon them, and include the discussions into your retrospectives or other meetings meant for improvements

🔹Automate as many of the agreements as you can into your processes (like workflows, tests, acceptance gates...)

🔹Remind your team of the agreements regularly and to try to keep to them yourself as much as possible

🔹Accept that the agreements will be broken, especially during your team's storming phase, so don't use them as a basis for beratement, simply remind your team that an agreements exists about this and ask if it should be re-examined for any reason


Once you've engaged your team to create their own working agreements, you've gained more investment from them on how they're going to work together, and you've increased the likelihood of them actually sticking to these agreements - because they've created them.


Establish and clarify the team roles and domains of expertise


Once you've cleared up the basic working agreements for your team, make sure everyone knows why they're on the team and what is their role.


Every team members should be well aware of what their purpose and their team members' purpose is on the team and how they will be contributing. Also, encourage sharing gaps in knowledge where the rest of the team may need to help out. Demonstrating weakness will foster trust and show everyone that team members depend on each other.


However, our advice is to tread carefully when establishing roles and accountability, so not to fall into some of these traps:

🔻Creating a hierarchy of responsibility or authority

🔻Creating a cadence where one role precedes the other with hand-offs

🔻Creating mini silos in your team that corrode team-work

🔻Creating an end-all authority in a domain that hinders brainstorming


Everyone on the team should know that each team member is on the team because of their domain of expertise and will be the go-to person for advice, insight and sometimes even decisions in that particular domain. But the whole team should collaborate, share ideas and insights to generate experiments and solutions that can best achieve business value.


For a self-organizing team, make sure everyone understands that shared responsibility is crucial, that all decisions are made together, and that there is no one go-to person, there is no one end-all authority. There is only the team.


Agree on and Adopt an Agile Framework


This is a bit of a controversial notion in the business world, still. But I believe it's one of the most empowering decisions you can bestow on your team - how they organize and streamline their work. This would, however, require substantial effort from the Agile Coach of the organization to explain the different approaches, their benefits and their use-case scenarios.


But imagine allowing your team to choose their own framework. Consider the following:

🔸Scrum, Kanban, XP and other team-based frameworks are just that - team based frameworks

🔸The complexity of work and VUCA environments are most assuredly not the same for each of your company's teams

🔸Your team knows their own work and their own shortcomings best and should be allowed agency in how they organize their work


Now, of course, this isn't always possible, due to the organizational structure of the company or the agile maturity of the team itself. Most companies have a uniformed framework that they automatically apply to all teams, whether as a dogmatic approach ('we use Scrum/Kanban/XP/...) or a part of a larger scaling framework (SAFe, Less, Nexus...).


Either way, agreeing with the team to adopt the framework is necessary. If the environment doesn't allow the team to choose a framework themselves, at least explain why the framework in question is chosen. Address their concerns and make sure they know the 'why' behind the framework decision, and allow your team the agency to commit.


In any case, be sure to discuss the following with your team, in your first planning session or maybe a separate agile coaching/training session:

🔹Reiterate the cyclic nature of agile frameworks and the importance of the inspect/adapt loop

🔹Explain/reaffirm the purpose of the frameworks to the team

🔹Advise the team about the environments in which a particular framework is most useful

🔹Educate your team on the purpose of every event/artifact in all the frameworks

🔹Advise on how frameworks interact with each other or can become hybrids


Also, keep the discussion about frameworks open. You might want to bring it up in retrospectives when you see an opportunity to implement, for example, pair programming or TDD into your team's workflow to optimize their effectiveness and increase business value.


Agree on a Rhythm for Self-Organizing Teams


Another big part of self-organization is to acknowledge the differences between individual team members. Your team members will have different habits, different ways of communicating, different boundaries and different needs. Some team members are more 'chatty' in the mornings, some in the afternoons, some need more focused work, some are more productive in a highly interactive environment. Your team will need to create a rhythm for themselves with which everyone can bring their best self.


Here's a hack: establish a rhythm that will address not only the meetings, but also the following:

🔸Focus days (or times of day), when each team member can dedicate time to their own work

🔸Collab days (or times of day), when the team can collaborate together, pair or mob program

🔸Availability days (or times of day), when each team member should have an opening in their calendar during which they're available for ad-hoc consultations, calls, short meetings and discussions

🔸Learning days (or times of day), where each team member can dedicate time to their own self-improvement, learning or research


Let each team member define their own needs about the above listed (all of it needs to be addressed, nobody can have 100% focus or learning time, or 0% availability time) and let them map out when they'd be most productive at a given item. After that, see how your team breathes and then set the rhythm of meetings, such as dailies, grooming sessions, planning meetings, reviews and retrospectives, in alignment with the team's needs and personal preferences as much as possible.


Your team will be appreciative that you're giving them the option to organize themselves better, and also to foster self-organization on a team level. And you'll get much better results when working together!


Before you dive in, make sure everyone is ready!


To wrap up, before you start getting into the work itself, here are some hacks make the transition to actual work planning stage as smooth as possible:

🔸Make sure everyone has everything they need regarding the work material and documentation, and that they've had time to review it

🔸Ask about the team's availability to do the work during the next sprint (personal time, vacation, doctor's appointments, other work responsibilities)

🔸Ask about any immediate impediments the team might have noticed (access issues, decisions needed, lack of infrastructure...) and remember to address them first

🔸Ask the team which issue everyone thinks the team should tackle first, remind them about the eat-the-frog principle

🔸Share excitement about starting work with this wonderful group of people you've assembled, and share your belief that you'll achieve exceptional things together!


This is also when teams grow from Forming to the Storming phase of team development and when things tend to get sticky and messy. This is normal, but to better prepare, keep your Work Agreements, your team roles, your commitment to the framework, and your team's individual needs and boundaries close to heart and visible, so you can revisit them and remind your team about them when conflicts arise. And trust that your team will take care of the rest!


Conclusion


As I mentioned in the introduction, self-organization is vital for a successful agile team, but not all teams or team members are used to working in a self-organizing setting. They'll adopt it quickly, from my personal experience, but the ground-work needs to be set. You want self-organizing teams, but what you don't want is your teams thinking you've abandoned them and left them out to dry. Providing guidelines, training, teaching and facilitating their initial discussions about working agreements, roles and frameworks will go a long way to help them get started.


I appreciate any comments, thoughts and discussions, so if you'd like more information or you have different opinions and experiences, I'd love to hear from you! Feel free to reach out!


In next week's blog post I'll be discussing Scrum (as the most popular framework) events, their purposes and how to make them successful! Stay tuned and subscribe!

74 views0 comments

Comments


bottom of page