Wednesday, March 9, 2011

What I learned about agile teams from 8/9 year old girls basketball

I am a very fortunate daddy. I am one of the coaches for my eldest daughter's basketball team. The community league she plays in has a rule designed to promote team work that at first glance may seem counter intuitive - "No double teaming". This means that in most circumstances when playing defense each girl must cover her own 'check' and can not help out her teammate. To explain this a little more, I'll give you two examples.

Example 1 - double teaming:

Mary is new to basketball and is tentatively dribbling the ball over half court. Ann is playing defense on Mary and is doing a pretty good job of limiting where Mary can go and who she can pass to. Laura is a very strong player on Ann's team and notices that Mary is struggling and that she has an opportunity to make a play. Laura leaves her own check, runs over to Mary (who is now double teamed), steals the ball and races to her own basket where she scores an easy two points. Her team cheers loudly.

Example 2 - helping:

Amber is an experienced basketball player and is dribbling the ball over half court. Kari is playing defense on Amber but is having trouble limiting where Amber can go and who she can pass to. Deanna is a very strong player on Kari's team, but because she is not allowed to double team, she does not immediately race over to help Kari. Amber makes a quick move that allows her to get past Kari and race towards the basket. At this point, Kari knows she is in trouble and yells 'help'. Deanna races over and gets in front of Amber to slow her down just enough so that Kari can catch up. Once Kari has caught up, Deanna races back to her own check and Kari resumes playing defense on Amber. No baskets are scored and mild applause is heard.

The nature of community led basketball leagues is that there is a combination of inexperienced but willing coaches and inexperienced but willing referees. This means that most times example 1 occurs without the ref or the coach interfering. While our team has been mostly executing as example 2, many of the teams we play against have been executing mostly as example 1.

Over the course of the season, the result has been interesting. Teams that were beating us at the beginning of the season by taking full advantage of the skills of their best player through double teaming are now struggling to even have a chance to score against our girls. The girls on those teams are trying just as hard, but the double teaming strategy that worked so well early in the season is no longer effective.

We have a team of 10 girls who have each improved. Some of the girls are more skilled than others, but each girl has improved noticably from the beginning of the season. The net effect is that our team has also improved noticably from the beginning of the season. Maybe more importantly, this team supports each other, learns from each other, and trusts each other.

Note: It would be easy to credit our brilliant coaching strategy, but that would clearly discount the effort, teamwork, and skill of the girls on our team. They are a wonderful group.

The parallels for agile teams are pretty clear to me. If you expect your team to perform at a high level, you need to let them improve at every role and reinforce team ownership of the project.
  • If you are the PM, don't take sole responsibility of the budget, tasks, project goals etc. Make these visible to your team and help your team own them and make decisions about tasks and priorities together.
  • If you are the DBA, don't get upset when the database design is insufficient, teach the team how to improve their design the first time. Work with them rather than 'fixing' their work later.
  • If you are a tester, don't assume full responsibility for testing, teach your team how to be better testers by testing every day and pair testing with the developers.
  • If you are the UI expert, involve your team when designing the UI. Lead the exercise, but don't steal the design for yourself.

Of course, the converse of all of these is also true:
  • If you are a developer, take responsibility for the budget and priorities
  • If you are a tester, learn how to code a little
  • etc.
There are other lessons to be learned from 8/9 year old girls basketball, like how to ask for help when you need it, but those are for another day.

Occasionally I meet former co-workers who inevitably ask me what I'm doing. When I announce my agile and lean passions and talk even briefly about the differences between traditional teams and agile teams, I often am greeted with a response something like "But someone still has to manage the team and the budget right?" My answer is usually "Yes, but it doesn't need to be you anymore. It should be the whole team."

As the African proverb says, "If you want to go fast, go alone. If you want to go far, go together."