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.


Msoong said...

Often time the difference between DB Engineer and UI engineer can be as great as between a musician and a artist. To say a UI engineer can QA DB Code is pretty naive...

Mark A Hart said...

Agree. The team environment is dynamic and some contributors should transition in and out. Certain other contributors are comparatively permanent and they can ensure that the vision for the project is evolved appropriately. Such issues are internal. They are subsumed by the larger issues such as:
- Return on investment to the sponsors
- Awesomeness-rating assigned by customers
- Professional growth / happiness of the individual contributors to the development effort

The game development environment should be crafted to facilitate collaboration. The efforts of the musician can shape other components of the game (graphics, animation, code,...) and elements of the game (story, graphics, animation,...) shape the music.

No matter how motivated a non-musician is, it would be a better investment for the other members of the team to enlist a musician with 5, 10, 20 or 30 years of deliberate practice that is a master of their craft. The results will be better and they will be obtained faster.

BTW. I established my skills as a musician (performing, composing, arranging, and recording) long before I began coding. I had to engage in a signifiant amount of deliberate practice to improve my Dreyfus level (see for both domains.

Clinton Keith said...

I said it because I've done it. Have you ever pair programmed in a TDD environment?

I've also written DB applications AND their UI interface.

There is no way that the difference between a DB and UI engineer is as great as an artist and musician.

Clinton Keith said...


Agreed. Someone else pointed out in Gladwell's book Outliers, where he writes that "mastering any skill takes around 10,000 hours of practice".

Using the example above, it would take 10,000 separate hours for a musician to master animation or modeling. It certainly wouldn't take that long for a DB coder to master UI coding.

Tom Gaulton said...

Sure, a DB engineer can learn to code up a UI. However the vast majority of DB engineers will make a functional, but really bad UI. A good UI engineer will also be a good UI designer, nd that's a long way from database engineering.

I feel that to enable people to function well in a team they need to know just enough about each other's specialisms to be able to understand the systems and make tweaks themselves.

Clinton Keith said...

Ok, I used the DB/UI example because I've done both. Point taken.

The issue is that there are soft specializations with more overlap than others and that we shouldn't pursue complete homogenization.

I completely agree with what you say about "knowing enough about each others specialisms"

Unknown said...

But its not that easy to do it all. Once i was trying to get into XNA Game Studio. I learned much of programming and i was alone in this field in my community. When it came to developing models and assets for the game it becomes necessary to have a separate team member who specializes in respective fields. Having specialist is good but specialist should know a "little"* of all the related fields as well.

* Bigger the "little" greater the product.