Breaking agile team expertise boundaries

This post is about getting agile teams to effectively talk to one another.

Agile is about the team, the many of available resources talk about ways to allow the team to self organize and as a consequence to perform in the most efficient way. The advice is usually focused on a singular team, rather than on multiple teams.

One particular area that is under-served is cross-team expertise and knowledge sharing. I see a lot of material on improving knowledge flow within a single Agile team. Once it comes to multiple, the suggestions seem to include online knowledge bases (wiki) and rotating people between teams. While doable, these are either not specifically “Agile” or do not correlate with approaches used to share knowledge within a single agile team.

The basic problem statement is – how do I generate useful information flow between the teams without breaking Agile principles?

Recently one of my Agile-SCRUM teams decided that it grew too big in numbers and needed to split into two. The decision was necessary but painful. The group, even while being too large, worked really well together. The primary concern was – now that we will be two, the same level of knowledge sharing will stop.

As we split, we decided to run an experiment of a concept we called “The Visitor”. The Visitor is a role that rotates between all members of participating teams. It comes with a very simple responsibility: The Visitor attends and fully participates in other team’s Refinement and Planning. There is one Visitor per sprint for both teams.

We had plenty of concerns when we first discussed “The Visitor”. – [lessons learned in brackets]

  • How much time would be required and can it be accounted for?  – [we were able keep the meetings consistent in length, did not become an issue]
  • Which of the scrum ceremonies need to be attended, will picking just Refinement and Planning be a good idea? – [its a balance with the first point, these two meetings is when most of the discussion happens, so far it worked]
  • Would the visitor be able to vote if the point scale is different between the teams? – [we were lucky since the two teams started with the same scale, so far we were able to keep it the same, in part through continuous sharing]

Now that we have been doing this for a few months it appears that the experiment was a success. There was clear benefit from being able to bring another knowledgeable person to refinement and planning discussions. On the flip side this person was able to take what she learned and expose her team to it.

So far we only tried it in scope of 2 teams. Clearly, if you expand this to have all teams visiting each other in all permutations, visiting is the only action you will be able to accomplish.

This said, I believe a less onerous multi-team (>2) rotation will work. It will imply that every two teams might not interact every sprint, the information exchange will happen but at a slower pace. I will update this article once we try it.

On a final note, with “The Visitor” we now added two new roles to our scrum process – “The Visitor” and  “The Bouncer”.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s