In a previous post Sreerupa Sen wrote about run teams and feature teams and how they are helping to make our continuous delivery successful. I want to expand on that in this post and talk a bit about the culture that enables such fluid organizational constructs to work successfully.

In the Collaborative Lifecycle Management (CLM) project our team of approximately four hundred is divided into many sub-teams. The most common and obvious sub-teams are those that group people by discipline such as development, function test, system test, release engineering, release management, infrastructure, documentation, and support. Within these sub-teams there are sometimes smaller sub-teams. For example, within development we have application teams that are responsible for a group of similar or related capabilities. The Change and Configuration Management (CCM) application team delivers capabilities such as Source Control, Work Items and Planning and Build, and there are smaller capability or component teams responsible for each of those capabilities. These teams are typically longstanding and people often remain in such teams for many years.

Virtual teams
However, many people in the CLM project are also members of many other teams and those teams are much more virtual and dynamic in nature. Virtual teams are formed for a specific purpose and then disband after they have achieved their goals. Feature teams are an example of virtual teams. They are formed for the purpose of developing a specific feature and once that feature has been delivered and the code has become part of the main stream, the team’s job is done and the team can disband. Large cross-cutting features may affect many capabilities. When we worked on the clustering feature in 2012, it required changes, or at least analysis of possible changes, and testing, in almost every component in every application. The feature team had many participants and the effort took almost two years including initial exploratory work that was required.

Some features may only affect a single component and nowadays, especially with our quarterly delivery cycles, feature teams may only live for a few months. In a previous blog post about feature teams Michael Valenta from the Jazz Source Control Management (SCM) team wrote about his experiences as the lead of the feature team that was responsible for improving gap handling in SCM. That team lived for about a year, beginning investigation into the feature in late 2012 and then finally delivering the feature in Rational Team Concert (RTC) 4.0.5 at the end of 2013.

Dynamic teams

In a previous post about run teams Sandeep Somavarapu wrote about his experiences in the run team for the Tracking and Planning (TAP) team that is responsible for the daily execution and customer-facing work associated with the work items and planning capabilities in RTC. Unlike feature teams, run teams are long-lived teams but they are more dynamic than traditional teams because their membership tends to be a lot more fluid. In our project this happens simply because we rotate people through the run teams.

Teams and teaming

Whether it’s feature teams or run teams, people working on the CLM project must be flexible enough to move in and out of teams and to work in multiple teams simultaneously. It’s not so much the teams themselves that matter but rather our ability to team with others. Harvard Business School professor, Amy Edmondson, promotes five behaviors that facilitate teaming:

1. Speak up
2. Listening intensely
3. Integrate different facts and points of view
4. Experiment iteratively
5. Reflect on your ideas and actions

You can watch a video of Edmonson speaking about these behaviors here or read a more detailed paper (registration required) she wrote for Harvard Business Review. The first two of these behaviors are encapsulated in the shared awareness I wrote about in my previous blog post. Shared awareness is built from open communication and intense observation outside our personal spheres. I think of the third behavior as continuous integration. We usually think of continuous integration of software with multiple individuals each delivering code contributions which are then integrated into a build. However this same behavior happens outside of software, in group discussions, whether verbal or electronic. Put ten people in a room for a discussion and in addition to contributing individually they are also each integrating everything they hear into their own personal workspace. There is usually also some shared integration such as one that is maintained on a whiteboard for all to see. The fourth of Edmondon’s behaviors is well-known to agile advocates. Continuous prototyping and experimenting have been at the heart of the agile movement since its inception. The last of the five behaviors, reflection, is akin to the concept of retrospectives that I wrote about late last year.

Leading and following

In addition to the important behaviors Edmondson promotes, I believe that the most successful people in an environment of constant teaming are those that are equally as good at following as they are at leading. Furthermore they must be able to easily move in and out of these roles and play both roles simultaneously. Jazz musicians are constantly doing this. While a jazz musician might be the leader of his own group one afternoon, later that night he might perform in a group led by someone else, possibly someone who followed their own lead earlier that day. Even in the course of a single concert, the role of leader in a jazz band constantly changes. One musician might suggest a tune to play and another might count off the tempo and then as the group explores and improvises, others may take the lead by initiating creative explorations. What makes such explorations successful is the willingness of others in the team to follow, to reinforce and support, and then to initiate, to lead, at the next turn. This is leadership on demand but it’s also following on demand. People who are good at this are those willing to lead when leadership is required but also willing to follow to avoid unnecessary conflict or confusion, or to play important supportive roles that the team depends on. In the music of jazz, the decision to step up and lead, or to step back and follow, must often be made in the blink of an eye. Failure to make such a decision might result in a missed opportunity to reinforce a creative inspiration suggested by one musician, or worse it might result in instability and an eventual “train wreck” as one or more musicians go one way and others go elsewhere. While this real-time teaming is not so necessary in software development, there is still a need for timely decisions of leading and following especially when the team is in pursuit of ever-increasing velocity and shorter delivery cycles.

In business, people are always talking about leaders, leadership and teamwork. In an agile environment the needs are more complex. Want to enable teaming? Look for people who can:

1. Lead on demand, taking initiative when it is required.
2. Follow as well as they can lead, helping to reinforce the initiatives of others and lend support when it’s needed.
3. Move quickly between leading and following and even play different roles in different teams simultaneously.

One final note: It’s very important to be mindful of the cost of working in multiple teams. Participation in any team, whether it’s static, virtual, or dynamic takes time and that’s time that is not available to do something else. There’s a cost to participation in any team and people and that should always be considered.

Good luck with your teaming!