Teamwork and Flavors of Agile

May 29, 2009

We have three Agile teams in our company, with each team managing a different product and each with its own distinct “flavor” of Agile. The general process that the teams follow is identical, but each team definitely has its own look and feel.

Some of the differences were expressed during an exercise we conducted to define what a high-performing team should look like. Each Agile team and the management team went through the exercise in the spirit of continual self-assessment and improvement.

We found that there was general agreement in what everyone thought a high-performing team should look like, although some things were expressed in different ways. In general, everyone had the following categories addressed in their list:
  • Commitment
  • Transparency
  • Accountability
  • Respect
  • Trust
  • Self-Determining
  • Collaboration
  • Communication
As I discuss the details, there is an important factor to keep in mind: Each team not only handles different products, but each team is handling products that are in very different stages of the product life cycle. To set the stage for you:
  • Team A handles our proven/in-production (numerous implementations), stable, full-featured, legacy product.

  • Team B handles a much newer product (few implementations in production) just entering the market.

  • Team C is designing and developing an early-stage product that has high-level objectives, but is wide open in terms of the specifics needed to meet those objectives.
This led to some interesting differences in the actual specifics put forth by each team in some areas. I’ve noted the a few key categories and the comments related to each made by the management team and the Agile teams in the tables below.



Individual and team commitments are met.

All team members are contributing, including taking the lead on one or more tasks.

Team A

Meets daily commitments.

Team B

Attitude, dedication.

Team C

Individuals are highly motivated.




Each team has a working agreement and lives up to that agreement.

Push back to stakeholders on issues with resources (being pulled off) and estimates.

All team members are self-directed.

Team A

Reviewing working agreement regularly.

Individual initiative.

Team B

Minimal outside influence, not micromanaged.

Input into product direction.

Team C

Involved in all aspects of the product (development, QA, marketing, demos, etc.).

Team feels like they own the product.




Teammates assist one another, even if it means operating outside their respective area of expertise.

Team A

Assists team members with road blocks.

Team B

Work together well, creatively, and with a common goal.

Pitching in when & where needed, no “not my job” attitudes.

Team C

High level of collaboration.

Flexibility – no defined roles.

Are the differences a result of the personalities involved with each team, or are the differences the result of the product life cycle driving the perceived needs of team?

I say both. The personalities of Team C are those of people who need to define and shape a product, requiring a high level of technical competence along with the ability and desire to deal with ambiguity; this in turn requires a high degree of interaction and collaboration. And I hope that based on the comments that I’ve provided, you can determine that they have a strong sense of ownership, due to the fact that the product is the direct result of their input and efforts.

Would these same people succeed with the more structured care and feeding of our legacy product? Yes. Would they enjoy it? No. Would I retain them for long? I doubt it.

It may be difficult to discern from the comments that I’ve provided, but Team A does have a sense of ownership as well, but not in the same way as Team C. Our legacy product is the result of years of effort by a lot a people, many of whom are no longer with the company. There is a historical sense of ownership and Team A takes pride in their work, but the product is well-defined at this point. The needs of Team A’s product are very different from that of Team C.

Team B is clearly in that middle ground. The product that they are responsible for has demands for new features, although far less in terms of volume when it was our new product in design and development. Team B wants input into product direction, but they didn’t articulate the desire to be “involved in all aspects of the product” like Team C did. Team B’s sense of ownership is grounded to the relative life cycle stage of the product.

The management team – having embraced Agile development – wants to see teams be accountable and successful. The focus is on the teams and results, and as you can see from one comment, “All team members are contributing, including taking the lead on one or more tasks,” the management perspective is derived from experience that includes the notion that in order for certain things to be accomplished, someone has to be responsible for it, to own it. And teams and individuals should own their tasks.

The management team also recognized that teams need to push back when appropriate – particularly if the agreed-upon deadlines are impacted due to resources being pulled (something we strive to avoid). We also expect candid conversations around our target dates, particularly seeking to avoid the all too common scheduling technique of “Here’s the date we have in mind, now work backwards when creating your project plan.”

My takeaway here is that the needs of one project or product will attract certain personalities that are suited for the needs of that project/product. The team dynamics and working norms will vary, in part because of the people involved, and in part due to the nature of the work involved. Even though we have a defined process and approach to development, we do have distinct flavors. As long as we’re achieving results, I certainly can embrace the differences.