In my last blog post, I wrote an introduction to triads. The popular question I got by e-mail from a few readers was: “Nice idea, but how do I apply this in real life?”  As part of my continuing series of articles to support my Tribal Agility talk, I will write about building triads in agile teams this week.  Are you working in an Agile environment with a stage two tribe?  Would you like to use triads to break through collaboration barriers?  To learn more, I invite you to read on.

Agile teams and Tribal Leadership are very compatible with each other.  Lately, I spoke with people in various companies that adopted agile practices and asked them the benefits they were looking for out of agile.  Aside from the usual points of increasing return on investment, speeding up time to market and increasing collaboration, another common sought after benefit was increasing employee engagement on their projects.

You want your Agile teams to be self-organizing and take full ownership of their projects but this can be difficult to achieve.  Speaking with these people in pre-engagement conversations, they mention the need for people taking more ownership of their projects and shortly after, they express how far they feel they are from that goal.  The question I usually ask them at that point is: “Have you made this clear to them this is what you want?”  After hearing their answer, my follow-up question usually is: “and how do you react when they make mistakes?”.

Triads can help you move more rapidly towards achieving the goal of building a self-organizing team and it all begins with how you act as a leader.  As an agile leader, you need to be able to delegate some of your authority to your teams and empower them to make certain decisions.  You can use delegation poker and delegation boards (from Management 3.0 by Jurgen Apello) to help clarify what you are delegating and who you are delegating the authority to.

Agile teams typically have between five and nine team members which present an opportunity to form multiple triads on a team.  To help you better understand how to build triads, let me tell you a story about Joe, a Scrum Master working with an agile team.

Joe is a Scrum Master and he wants his team to take more ownership of the project.  On his team, he has people from different departments (development, quality assurance and information development) that need to collaborate to deliver features to their customers.  Most team members being relatively new to the company, they are not yet comfortable with the existing systems.

After two sprints, he begins to notice the developers rarely speak to the people from the other departments.  He also notices everyone is sitting in their separate cubicles, in different areas of the same floor which he feels is not helping their collaboration issues.

In the following retrospective, he asks the team what are their most painful challenges.  After a long discussion, the team comes up with the following issues:

  • Lack of expertise to tackle incoming support issues
  • Lack of communication between people working on the project
  • Lack of a common understanding of the project vision

Having just come out of the Tribal Leadership Intensive class, Joe begins to wonder if using triads could help overcome some of these challenges on his team.  He decides to suggest some new ideas to his team.

Figure 1 - Support Triad Benefits

Figure 1 – Support Triads Benefits

Carrie, the rock star developer, is the person with the most knowledge of the internal systems.  When big problems occur, she is typically the one that will fix the issues no one else wants to get close to.  Joe suggested pairing her with another developer and one of the testers the next time a major support issue comes in.  The two developers could resolve the coding issue together and the tester would confirm the fix.  Figure 1 shows the benefits this triad would provide.

The team decided to try this solution for a few sprints.  Joe asked the team what they wanted to do about the two other issues.  A team member sought more details about the lack of communication in the team.  Jennifer, of the testers, mentioned she did not know what to build her test cases around because the design of the feature kept evolving throughout the sprint.  Seemingly, the developers regularly deliver something different from what she understood in the sprint planning meeting.  This causes her test cases to be wrong which force her to rewrite them and start her testing late which is why she is rarely able to finish her testing in the same sprint.

A team member suggested that Jennifer go visit the developers more often during the sprint but she answered this was sometimes difficult because some of them do not like when she interrupts their work.  She also said she did not always know who owned the feature she was currently testing.  Joe saw the opening he was looking for and asked who felt any ownership over what they were doing on the project.

Some people answered yes while some glanced back at Joe with blank stares.  Joe asked the team what it would take to allow them to feel more ownership of their features.  The team talked about all the features they were working on and how spread thin this made them feel.

Figure 2 - Development Triad Benefits

Figure 2 – Development Triad Benefits

The team decided they could be more efficient if they created sub teams that would have ownership of specific features in the sprint.  The team had four developers, two testers, one technical writer, the Product Owner and the Scrum Master.

Joe suggested they try using the three people format they used for the support challenge.  He asked the team how to best spread the talent to allow each team to do the widest variety of work.  The team decided the best solution to start would be teams of two developers and one tester.  Figure 2 shows the benefits these development triads would provide to the team.

Figure 3 - Cross-team triad benefits

Figure 3 – Cross-team triad benefits

They were unsure on which team to put the technical writer.  Joe suggested that one member of each team meet with Len, the technical writer, a couple of times a week for one hour.  During these meetings, they should share thoughts and provide updates on the design changes made during the sprint.  Figure 3 shows the benefits this cross-team triad would provide the to the team.

To increase the communication, Joe also suggested all team members move closer to one another.  He took actions with the management team to create a new more open temporary work environment where everyone could sit with their triads.

At the end of the retrospective, Joe was happy because he started the meeting eager to find ways to set some up on his team and at the end of the meeting, he had four new triads on his team.

The next sprint planning meeting kicked off with excited team members looking forward to working with their new sub teams.  Joe reminded they put triads in place to create a three-person support system where everyone had each others back.  Each triad shared accountability for delivering the right solution and they were also responsible for supporting one another to make that happen.

During the sprint planning meeting, the first part of the meeting with the Product Owner explaining the sprint objectives happened in the same way it always did with all teams members taking part in the discussions.  When the team members were ready to break down the tasks, they agreed on the pieces they wanted to work on, split up in their triads and began identifying the tasks they needed to complete to deliver their feature.

Forming triads to work on the deliverables gave the team a stronger sense of ownership on their work.  They kept the same triads for multiple sprints as they learned how to work together in this way.  Later in the project, the team decided to experiment further by reshuffling the team members and building new triads.

All the communication and collaboration generated by the triadic structure also allowed the team members to more regularly talk about and take ownership the product vision with their Product Owner.  Shared common objectives and goals were driving the team and they began to achieve much more than before.

Conclusion

The above story does not show the growing pains triads go through but the goal was to provide some initial ideas on how you can create some on your teams.  Working with a Stage Two tribe or with Stage Two team members can seriously hinder the progress of creating triads on teams.  Once team members get over the learning curve of supporting one another and working as a team, they will start progressing faster more rapidly.

In an organization, triads are an excellent way to get people from different teams to collaborate on initiatives that interest all members.  For example, if an organization wanted to bring in some best practices like automated testing or continuous integration creating triads around these initiatives allows more people to take ownership and work with like-minded people to achieve a common goal.

The key to making triads work in any organization is the existing organizational culture. Triads will thrive in organizational cultures where collaboration and cultivation rule.  Organizational cultures driven by command and competence will foster a Stage Three environment which will require different kinds of projects to allow triads to thrive.