Continued from Part-1…

1. T-Shaped nature of the team? (1)

Perhaps the best way to think of T-shaped-ness is the flexibility of everyone on the team to the overall work. Do people focus only on a narrow/deep skill area (I-shaped) or do they try and occasionally flex to help in areas where they’re less skilled, but willing to learn, pitch in, and help (T-shaped)? One of the easiest ways I’ve found to determine this is measuring the times you hear: “that’s not my job, or I’m waiting for Blarg to finish their part” within the team.

2. Visualization of work and tooling (1 and 3-)

How well does the team visualize their work? This includes the word itself (product backlogs, sprint backlogs) and artifacts around the work (DoD, charters, roles & responsibilities, etc.). I’ve always thought that the higher the maturity and performance of the team, the less they rely on tools and the more they rely on visualization and collaboration around the visuals. Related to this is the notion that the visuals are kept up-to-date in real-time or always reflect the current reality.

3. Style of work (1)

Somewhat related to #1, is how the team attacks their work. It starts with WIP limits and working more individually or serially OR working in smaller groups (pairs) swarming around getting a smaller set of things…done. Mobbing is an extreme (positive) example of how the team approaches their work. A part of this also relates to whether the team asks for permission to work in a specific style or whether they simply take responsibility and ownership of their own style—independent of external leadership approval and/or support.

4. Type of work or workstreams (2)

My favorite example of workstreams affecting teamwork is pulling an IT operations “team” together but asking each individual to provide support to ~5 unique applications each. In this case, there is no integrated workstream. Instead, the various workstreams owned by the “team”, forces individualized work without the possibility of swarming, pairing, or T-shaped collaboration of any sort.

5. How well was the team created (3+)

I often help teams who are struggling a bit and find that the root cause of that struggle is that they didn’t form up or charter the team very well. Instead, they just dove in and began to work. I’m a firm believer that higher-performing teams were initially started well. They took the time for establishing norms, guidelines, and getting to know each other well.

Another term I often use for chartering is Liftoff, which is inspired by a great book with that name. I’d highly recommend it.

6. Prescription vs. Invitation for the overall agile transformation (2)

Most transformations in my experience begin by “management” telling their teams that they’ll be using/going “agile”. There is no collaboration around the idea, which would allow team members some input into the process and allow them to opt-in. As Dan Mezick has pointed out many times, this is a very fragile way to begin as it doesn’t empower the team. A strategy of invitation-based transformation is much more effective.

7. Asynchronous vs. Synchronous ways of working (1)

As we were talking in the Herd the notion of asynchronous versus synchronous work came up. And, I hadn’t heard that term before. Asynchronous ways of working, which allows the team to not be working at the same time, seem to be more effective. That is allowing for a more asynchronous time within the team by how work is scheduled, the tooling used, the architectures leveraged, and the

8. Adaptability in the face of complexity (Cynefin) (1)

I bring up Cynefin here as a modeling tool for reacting to different situations for each team. That is, independent of the model, higher-performing teams sense the landscape of their work, challenges, and goals and apply different sensing approaches to figure out which way to go. In other words, they’re not a one-sized strategy for everything team. This habit builds their adaptability and resilience muscles.

9. Learning organization mindset

While this is part of the overall culture (see part-1, #5), I wanted to call it out specifically. Under this banner, things like mentoring, communities of practice, slack time, and honoring employee growth and development all work to create a learning organization. And this then can permeate into the team where their mindset of one of personal growth and team learning & growth. As in #8, building resilience.

10. Can they do the Haka? (1)

Of course, any Scrum or otherwise (Kanban, agile) team worth their salt needs to be able to execute the Haka effectively. With joy, enthusiasm, focus, and intent. You’re simply not agile if you can’t. So, practice, practice, practice…

Wrapping Up

At the end of my exercise, I realized that there was far more to team dynamics than I had originally imagined. And I feel that I’ve only scratched the surface here.

Cory Bryan was the Herd attendee who brought the original question up. And after our discussion, he mentioned that he would be recording a podcast on the topic. I also mentioned that I’d be writing this post. So, we discussed who might deliver first?

Well, he went and did it. Cory “beat me” with a teaming podcast on DeliverIt. I can’t believe he did that. You can listen to it here – https://deliveritcast.com/125-rethinking-teams

I hope that both Cory and I have extended your thinking about the dynamics surrounding higher-performance agile teams.

Stay agile my friends,

Bob.