The concept of placing people into independent, autonomous teams is at the core of agility, and finally, I talk about the Dedicated Team Member as the last article on my series about Team Collaboration Patterns.
As discussed previously, I use these various patterns as a means to represent the different ways people can engage and interact with each other. The fact that there are numerous different patterns does not take away from how important the cross functional dedicated team member is. Its the core organizing element that makes all this agile style stuff work.
Dedicated Team Member
Summary
You are a full time member of a cross-functional, stable, market facing team (ie Classic Agile Team)
Problem
You are trying to create value in an environment of uncertainty, complexity, and constant change. A mix of skills and capabilities is required to successfully deliver that value. The need for your particular set of skills is significant and it is also stable over time. A high degree of collaboration is required between you and the rest of the team in order to deliver on this value. The actions required to deliver value can be described as being complex. The work is emergent, and requires continuous learning to be performed effectively.
Solution
Collaborate as a Dedicated Team Member of a classically defined agile team. While there is little value in coming up with a standard definitions for an agile team, there are some characteristics that are fairly common. Typically, agile teams are relatively small, with no more than 6 - 8 people. As the team size grows, team cohesion can start to become an issue, cadences participation starts to suffer, and self-organization can break down.
You and your team members together posses enough cross functional capability to deliver on a market outcome. You will tend to work together by using a variety of agile practices such as working on a small number of small things at a time.
When you choose to be a Dedicated Team Member, you are committing to the fact that you will be spending the majority of your working day with that team in order to achieve the goals of that team.
Discussion
Where possible we want most of our Edge teams to be comprised of people who are choosing to be Dedicated Team Members. As mentioned previously we want most of our people in the organization to be part of Edge teams. This implies that most people in our organization are Dedicated Team Members of Edge Teams. This won't always be possible depending on context, but it is a goal to strive for when trying to maximize agility.
In general, we also want Dedicated Team members to be part of a team that takes responsibility for end-to-end delivery of value, but this is not always possible given how far the organization is along their agile journey. Organizations that are just starting to use dedicated agile teams may start out with teams that are focused on a particular part / phase of value delivery such as shaping /discovery, delivery, or operations.
Options
The typical 6 - 8 team size is a general guideline. I have seen teams that are smaller and I have seen teams that are a good size larger. While many may balk at teams that get much bigger than 8 (and for good reason), members of larger social groupings can form into smaller groups to work on discrete items in their backlog. The larger team can elect to temporarily splinter into smaller team fragments. These team fragments can focus on a subset of the team's backlog, hold dedicated cadences, etc in order to collaborate with a tighter group.
Feature Cells
Feature Cells are a grouping of 2-3 team members who form to work on one discrete increment of value, for example a feature, or a thin slice of stories. Team members can choose to form into feature cells as a part of the team's planning cadence. The feature cell works closely together to deliver the feature / thin slice, taking the work through discovery, delivery, and if possible, straight to production. During the next planning cadence, team members collectively look at the backlog of work and determine if feature cells should stay the same or if people should move into different feature cell. A feature cell will often consist of team members who understand product functionality, engineering, and testing/quality, knows as the 3-amigos concept.
Dynamic Feature Teams
Some organizations evolve to foregoing stable teams, for the most part. Instead, members of a larger Agile Ecosystem (Mission/Tribe/Portfolio) dynamically form into team configurations to best achieve a constantly evolving backlog of outcomes. This team formation is typically done during some type of higher level planning session. Often this planning event is held at a cadence, perhaps monthly or bi-weekly. This style of planning is also aided by a visual backlog of outcomes that are shaped into increments of releasable value.
When organizations start to experiment with dynamic teams, the planning cadence often starts as a leadership led exercise. Having leaders decide what teams other people should belong to is not sustainable if we want dynamic teaming to be a healthy endeavor. If we want professionals to effectively self-motivate to accomplishing a goal, then planning requires participation from every member of the ecosystem. The purpose of Dynamic Feature Teams is to empower people to not only self- organize once in a team, but to self - organize into the teams they feel are best to deliver on their outcomes!
Dynamic Feature Teams may have some members of the team who are considered stable, they are fixed members of a team based on a particular initiative, business domain, or platform, while the remaining membership changes dynamically on a more frequent basis.
In the case of both Feature Cells and Dynamic Feature Teams, visual management systems. ie Kanban can be used to help inform people on how to dynamically form into groups dedicated to an increment of value.
