Search

Saturday, October 22, 2011

Scrum prohibits all specializations?

A recent conversation about a team staying together long-term, etc prompted me to ask: "what if the team no longer needs a musician?"  The responses stunned me.  Some insisted that the role "musician" is not part of Scrum and that they are not part of the team.  Everyone should learn to make music, write code, create art, etc.

Now, I understand that Scrum has been applied mainly to software products and that the elimination of "specialties" means that the database programmer, UI programmer and QA engineer should, ideally[*], be able to perform each other's roles equally.  This is valid.  But the idea that that this extends to separate functions such as music, programming and drawing makes no sense.

In "The New New Product Development Game", the landmark 1986 Harvard Business Review article that first coined the word "Scrum" for product development,  authors Takeuchi and Nonaka observed the benefit of cross-fertilization and multifunctional learning across specializations.  These principles directly apply to mixed teams of artists, musicians, designers and engineers working together to create better solutions than using a "relay race" of handoffs.  E.g. If I share a sprint goal with a musician, I become aware of their workflow and needs.  I can help them solve a technical problem with the audio code and they can make the game sound great.

You can be sure that in my book and courses, I don't teach that functions should homogenize on a team.  There is a role for a musician on a "Scrum team".  It's called a "team member".

[*] I've added the term "ideally" after posting this the first time.  The reason for this "ideal" overlap of specialization is to promote multi-learning across all specialties.  The goal is to have a shared understanding of each other's roles so that the team can continually improve how they work together but not to homogenize all specialization.