When I was following more traditional project management approaches over a decade ago, I was under tremendous stress to get my staff to do the right work and meet the right deadlines. In making the shift to agile approaches and to self-organized teams, I learned to establish goals instead of deadlines. Also, I went from controlling resources (including people) to influencing work environments. This led me to discover approaches to build self-managed teams, both co-located and distributed.
In moving to agile, a major benefit was that I no longer needed to direct people and activities. Instead, I was free to focus on a more strategic level.
Also, the agile self-organized teams came up with a wider variety of options and better solutions than I ever could alone. Moreover, I was far less stressed to come up with all the answers and have my team deliver on time. With distributed teams, they can be even more creative because they have an even more diverse experience (i.e., they don’t sit in the same office together). So, a self-organized distributed team can actually react in more unique ways and achieve solutions more quickly.
Defining the Self-Organized Team
First, a “team” is a collection of people working toward a common goal. A “self-managed team” is a team that manages its own work by breaking down goals given to it into manageable tasks and then having individual team members choose the tasks they will work on. Also, in a self-managed team, team members hold each other accountable for completing these tasks in a timely manner that helps the team achieve its goal. Finally, a “self-organized team” is a self-managed team that also co-defines—with stakeholders—the goals, environment and processes of its work. This can include:
- Setting goals based on business needs weighed against current technical capabilities of the organization and team
- Determining who to add or remove from the team
- Working with other teams to establish the infrastructure for their work;
- Altering work processes to deliver on the goals as quickly as possible within constraints of the work environment and negotiated standards within the organization
The inspect-and-adapt nature of agile principles and practices provides a structure to establish a self-organized team due to the strong emphasis on collaboration at all levels and the frequent feedback loops within and outside the team.
How Can You Set Up A Self-Organized Team?
There are a number of things you can do as an agile manager to help create the work environment for a self-organized team, be it co-located or distributed:
1. Provide a no-delay work environment. A self-organized team needs to share design, code, documentation, status, questions, ideas, feedback and more. The more delays in these different types of sharing, the more difficult it becomes for the team to self-organize.
Does everyone on the team have equal access to—and skills to use—repositories, tools and communication channels? Do these tools allow all team members to receive information equally (i.e., no access issues)? Do they all receive information at the same time (especially when considering time zones)? This last question is more challenging for distributed teams, but with smaller teams in nearby time zones, you can approach a no-delay work environment.
2. Establish collaboration opportunities. Collaboration opportunities can typically be found in various agile meetings:
- Stand-up meetings: Where the team members might ask: “Are we working on the right tasks to reach our iteration goal?”
- Review and planning: Where the team (and stakeholders) might ask: “Are we working on the right features to deliver value needed by customers in a timely manner?”
- Retrospective: Where the team might ask: “Are we working the right way to deliver optimal value with minimal waste and error while maintaining a sustainable pace?”
Where the team does not have experience facilitating, you need to provide this facilitation. If the distributed team doesn’t have experience with the collaboration tools, teach it. However, look for opportunities to hand responsibilities for these meetings back to the team when it is ready. While in these meetings, train members in the skillsets to run the meetings. Make it effortless for them to own the meetings.
3. Establish clear goals over specific, detailed instructions. Self-organized teams need to understand the intended business goals, but be given the freedom to discover the best solutions. Make sure the team understands the goals from iteration to iteration. Allowing it to explore solutions for one iteration, choose a plan to implement the best solution based on stakeholder feedback and then use the remaining iterations in the release to build the solution empowers the team to do its best work.
4. Codify team norms. The norms (or working agreements) define how team members will work together. This is not for you to define as an agile manager, but it is up to you to make sure the team discusses and decides on these norms. Also, ensure they are recorded where all team members can easily be reminded (remember: no-delay). You should also make sure the team revisits its norms from time to time, especially when they don’t seem to define current behavior on the team.
5. Set boundaries and explain why. There are a few different boundaries you might consider defining as soon as possible as you prepare to move to self-organized teams. One of the most empowering involves defining what decisions a team can make. A self-organizing team makes many decisions, but it may not be able to make all decisions that impact it and its work. You should be clear on what decisions it can make without any need to involve you or stakeholders. For decisions you need to make as an agile manager, be clear on why you will make them (due to knowledge of budgets, timelines of other initiatives, etc.) and when you may still seek input (e.g., hiring).
The Power of Invitation and Trust
In prior articles, I mentioned the power of invitation and trust as foundational elements for building distributed agile teams. “Invitation” means asking the self-managed team to gradually take more ownership of the work. By “trust,” I mean allowing the self-organized team the space to explore how it owns its work processes without putting it or the work at severe risk.
Taking on these characteristics as an agile leader allows the team to take on small responsibilities initially, and to take on increasingly larger responsibilities later. Eventually, the team will be able to direct its own work in the manner they see most efficient. For more about invitation and trust go to:
- Invitation: The Secret Tool for Distributed Agile Leaders
- How to Demonstrate Trustworthiness: A Key Success Factor for Distributed Agile Teams
You may not detect much difference in applying these practices to co-located or distributed teams. The principles remain the same in fostering collaboration.
However, the main difference with distributed teams is you have to focus more on providing opportunities for individuals on the team to interact frequently—and often spontaneously. With distributed teams, this means giving them as much control over the work environment as you can and then stepping out of the way to let them self-organize to accomplish their best work.
By setting the no-delay environment, providing collaboration opportunities, setting pragmatic boundaries with team norms and levels of decision making, you can establish a self-managed team. Success comes with inviting the team to take more ownership of how it works—and trusting the team to do the right thing based on the overarching goals set for the project.
A previous version was published on ProjectManagement.com November 1, 2016 by Mark Kilby.