Author’s Note! This article has been imported from my previous website. I wanted to preserve all of the old content as many people have found some value in it. There may be some broken links and or formating issues. If something isn’t right, please let me know and I’ll do my best to make an update.

I just got out of a presentation by Maria Matarelli and Dan Neumann on making collaboration visible with an eye toward breaking down silos on an agile team. Here are some highlights:

Track Work In Progress

Invoking the agile manifesto’s “Working software is the primary measure of progress,” the team explained that by limiting the work in progress (WIP) a team will be more likely to move an individual task to “done-done.” It really doesn’t matter how many stories your team starts, or how many are moved to “verify;” what matters is how many are completed and deployed. They suggested:

• Pick a WIP limit, setting it in a tool such as JIRA GreenHopper or creating post-it note slots on your white board, or a pre-set number of “story in progress” markers that can be attached to story cards.

• Track your WIP and see how it correlates to problems; perhaps one sprint, you had 6 stories in progress and shit hit the fan, only 1 got delivered, but when you had only 3, everything was done and everyone got beers after the retro! Use this to continuously refine your team’s ideal WIP number.

• Make it visible! The WIP tracking and limits should be up on the wall so that it serves as a continuous reminder of your team’s agreement.

Avoid Silos

The presenters encouraged limiting silos so that bottlenecks could be reduced as well as dependencies on specific team members for knowledge. They suggested creating “activity bingo,” plotting team members vs. skill sets and checking off the intersections. Here is a funny example with me and my girlfriend:

The point is that you don’t want diagonals where each person has a particular skill (silo), but rather, some “personal breadth” or “team depth” where either one person can wear many hats, or the team can all take on a particular need, respectively. Having overlap prevents “someone being out” from causing delays or blockers.

It is also important to remember that this “bingo” game is just for team purposes to get on the same page, and not for outsiders to look in and judge the team. Don’t let it be used for performance evaluation.

Collaborative Design

One of my favorite topics was on collaborative design as a way to encourage more interactive, get-out-of-the-chair-and-do-something planning sessions. The suggestion was that during the process of breaking down stories into tasks, that you (I assume the evangelist/scrum master) would “model the behavior” by getting up and starting to draw during the discussion. They showed a cool example of a process flow with post-its for classes interacting on the white board.

It really resonated that by defining classes as post-its, you could move them around a lot, draw flows and get everyone on the same page on how the feature is going to work.

Pirate Maps

The final item they discussed regarding “making collaboration visible” was the transformation of a boring box+arrow interaction diagram into a pirate map. YEAH, a pirate map! The exercise adds a lot more texture to a simple diagram and humor helps convey a greater meaning. Some suggestions:

• Teams are treasure islands.

• High bandwidth communications are radio towers.

• Low bandwidth communications are little ships.

• Organic flows are like currents.

• Architects are like angels or hobos.

• Pirates / Raiders represent people that raid your project.

• And there was also a dragon, which I guess represented something bad.

Here is a funny example:

More to come! This is a great conference.