In one of my previous articles I had already mentioned the importance for the managers and leaders to be able to delegate work and trust their teams to find the best ways of getting it done.
In my practice I often encounter an issue where a talented, responsible individual is getting promoted to a managerial role, yet no training or mentorship is being provided by the organization that would help this individual to strive in their new, leadership role.
These new, and sometimes even seasoned managers are falling into a trap of having to stay on top of each subordinate’s output and essentially becoming a micromanager, or even worse – developing a hero mentality and only trusting themselves to do a good job.
An experienced agile coach is usually able to help managers to find a way out of this unfavorable situation. But even in an absence of an experienced coach or mentor, Agile delivery approach itself helps these managers by organizing their subordinates into cross-functional self-organizing teams.
However, how to make a decision on how to structure such teams?
1. Anti-pattern
I often encounter teams that are organized around projects. What makes matters worse, such projects are often internal to the organization and are not long-lasting, often spanning only between 6 to 9 months.
Those of you who took any kind of project management course must’ve heard about the Tuckman’s stages of a high-performing team development.
Source: https://www.outlife.in/blog/team-development-performance-models
The problem with the illustrations like the one above is that they give you only the direction forward, and don’t tell you how easy it is for a team to roll back to previous phases. Any chance to the team composition, whether you add or remove people, are going to affect productivity.
The goal of the leaders is to keep the team in Performing stage as long as possible. Whereas in the example of 6-9 month projects, the team is going to be adjourned soon after achieving performing stage, or even before that.
Tip: look to build long-lived teams
As ProjectManagement.com puts it:
“When a team knows that they will be working together for a long time, and particularly when they are responsible for the entire delivery lifecycle from beginning to end, they are more likely to streamline their work so as to make things better for themselves.”
2. Patterns
They say solution architecture is about knowing patterns. In this sense, team design can be not much different from architecture.
Matthew Skelton and Manuel Pais from TeamTopologies.com oranized their and industry experience into a simple set of patterns that can be applied to any organizations.
Just like with any methods and framework, there are nuances to be taken care of when it comes to implementation. Yet, the 4 patterns identified in their book help with providing the vision, approach and tooling to help designing teams.
Their approach was successfully accepted by the community, and was recently included into the Scaled Agile Framework.
- Stream-aligned team – organized around the flow of work and can deliver value directly to the customer or end user.
- The complicated subsystem team is organized around specific subsystems requiring deep specialist skills and expertise.
- Platform team – organized around developing and supporting platforms that provide services to other teams.
- Enabling team – organized to assist other groups with specialized capabilities and help them become proficient in new technologies.
© Scaled Agile, Inc.
The above summarizes the common 4 types of Agile teams often found in any organizations.
I suggest simplifying this view a bit further: 1. the teams that deliver working features (or other types of value) to the end customer, and 2. the teams that support them in this delivery.
The preference is to have as many stream-aligned teams as possible, as they own the entire delivery pipeline and will find ways to simplify the pipeline within the set operational parameters. However, this is no always the most efficient or risk-averse way. Why? Simply imagine 20 stream-aligned teams making simultaneous changes to a Cobalt-based bank’s mainframe.
This is why various “enabling” teams are inevitable and often provide for better efficiency and stability of the entire delivery system.
3. How to start?
As with almost anything, start with understanding your current setting:
- What are the Operational Value Streams your group is supporting?
- How many customer types or personas are you catering to?
- What are the products and capabilities used by each customer?
- How many functional silos are participating in the development value stream?
- How many people are in each of these silos?
All these questions and many more will help you to inform your team design decision.
Once this is done, identify all the decision-makers and consultants who need to participate in the team-design process. You don’t want to make the decision yourself and then simply inform everyone else 🙂
Once all the participants are gathered, it is time for a team design workshop.
Team design workshop must follow a few rules:
- Each opinion matters
- Collaboration over individual contribution
- Don’t make decisions before understanding context
- All the decisions don’t have to be made in a single session
- Team design is not set in stone and follows the same PDCA cycle as any other agile activity
This set of rules will help you to have a successful workshop.
The Team Design Workshop itself is rather straightforward:
- Use sticky notes and a whiteboard or any online collaboration tool like Miro or Mural. Start with outlining the context: OVS, DVS, customers, silos and all the people in them.
- Discuss if there are any complex subsystems that may require support of a dedicated team(s); or if there is an opportunity to enable stream-aligned teams via a platform development; or if there are any critical capabilities that most of the people in the DVS do not possess.
- Use proposed shapes to start mapping the stream-aligned teams. Are these teams going to be catering to specific customers or should thy focus on products / capabilities? Or maybe each team should be able to deliver any feature from the common product backlog?
- Once stream-aligned teams are drafted, add all the enabling teams to the map. Discuss how they are going to interact with the stream-aligned teams. Are there any knowledge-sharing opportunities? Which stream-aligned teams would have a harder dependency? Which teams’ needs should take priority and how to make quick and accurate decisions on prioritization of the features in the enabling teams’ backlogs?
- Review the mapping with all the participants and make the final decision by a confidence vote. Make sure to address any concerns and don’t stop until everyone at least voted 4/5.
- Establish metrics to measure efficiency and agree on the retrospective cadence to review and make adjustments to the teams composition.
This process may sound complicated and sure it has many nuances, but it is important to remember: you will probably not create a perfect teams layout from the first attempt, but organizing delivery by cross-functional agile teams is already perfect.