Search

Wednesday, July 30, 2008

Hyper-productive Teams

A hyper-productive team is a phrase often used in Scrum literature to identify teams that have achieved a state of ownership, commitment and collaboration that allows them to be far more productive in creating “product value” on a regular basis.

I view hyper-productive teams as independent of Scrum. There are many examples of teams that have been hyper-productive independently of the process they’ve used. I’ve been on several in my career from the defense industry to the games industry. They are the highlights of my career. I never worked harder and never had more fun than when I was on those teams.

The first was the YF-23 avionics integration team that I worked on for 10 months in 1990 at the McDonnell Douglas plant in Saint Louis. We were led by a retired F-14 Tomcat squadron commander. We actually had 10-15 minute stand-up meetings every morning to go over the issues and daily goals. He called it the huddle. We were a team under siege in a hostile environment as contractors working the midnight shift.

Another hyper-productive team was the Midtown Madness One team. Most of the team (including me, the product director) had never worked on a game before. However, we were given almost complete autonomy by Angel Studios (and largely by even Microsoft) to build the game we wanted. I recall all of us stopping work to play the game at 6 PM every night and then stopping at 9 PM to drink beers in the conference room and discuss ways of improving the game. I would arrive some mornings to find that members of the team had reworked the rendering engine or vehicle dashboard models overnight to greatly improve a weak part of the game. We didn’t use Scrum either, but we had some TDD like practices and even posted burndown charts which visibly tracked key statistics such as polygon budgets for the level, etc.

Hyper-productive teams are hard to define. To paraphrase a common quote: “it’s like porn…you can’t define it, but you know it when you see it”. In addition to talent, hyper-productive teams are the greatest contributors to the creation of a hit game.

I try to define conditions that support, or are common to, hyper-productive teams. In addition to educating teams on how to use Scrum, a main goal of mine is to facilitate teams on becoming hyper-productive.

So what are the conditions that allow a hyper-productive team? I’ll identify a few I feel are important:
  • Independence and a sense of ownership - The team needs to feel that they can contribute creatively and have some control over the game. This isn’t necessarily total ownership, but some.
  • Leadership - There needs to be one leader on the team who can communicate a vision between the team and the customers and keep the team focused.
  • A core competency - Not everyone on the team needs to be an expert, but on the hyper-productive teams I have seen there have been at least one core expert. This isn’t a lead position defined by a role, but by actions. This person supports the vision with brilliance that the team can be confident in and rally around.
  • Team collaboration - Teams grow into great teams organically. There are countless articles and books written about how this happens (here is one of my favorites). This is where facilitation can help a team transform itself.
As mentioned, these teams form independent of process. However, Scrum can support and nourish hyper-productive teams based on its practices and principles. Team self-organization, Sprint goal ownership and commitment and a daily dose of visibility can support and grow hyper-productive teams.

3 comments:

Michael Dubakov said...

Some insights on hyper productive teams
(Edge of Chaos and Hyper Productive Software Development Teams)

http://www.targetprocess.com/blog/2008/12/edge-of-chaos-and-hyper-productive.html

Jeff Sutherland said...

The teams you describe are what Takeuchi and Nonaka saw and they described it as Scrum Project Management in their Harvard Business Review paper "The New New Product Development Game" so this is exactly Scrum as Takeuchi and Nonaka see it. The Scrum process for software that I developed with Ken Schwaber derives directly from Takeuchi and Nonaka and formalizes the process so the average team can implement a Scrum. You may not have been following the Scrum Guide on these teams but you were definitely doing a Takeuchi and Nonaka Scrum.

Clinton Keith said...

Hi Jeff,

Great point. Yes, I agree that what we were doing would have better aligned with Takeuchi and Nonaka's view of the "rugby approach" over that of a "relay race approach". That was the brilliance of their article: to distill a common set of patterns and values for successful teams.

Thanks,
Clint