Specialisation without Silos

10 Mar 2010

I'm watching Michael Nygard's talk in the devops track at QCon.  This is my first taste of the devops movement and it's certainly something I like the look of.  I'm really struck by his assertion that we don't need a division between development and operations, but crucially he isn't saying that everyone needs the same skills - we will still have specialists.

I'm struck that this idea of bringing people together into a single team, while still maintaining specialisation, comes up a lot in the software world.  Some examples:

  • We always try to have a single User Story implemented by a single team.  There may be different specialist skills required to implement a single feature, but all those skills should be in the same team and the people should work together; we don't want a "back end" team and a "front end" team.
  • I'm frequently explaining to clients the value of having QA specialists integrated within a development team.
  • More recently, with Pat Kua, I've been arguing for the integration of performance testing into the development team.

Having a single team has all sorts of implications.  I'm particularly keen on having a single backlog of work, even if not everybody has the skills to pull from that backlog.  Most importantly, a single team stands a better chance of having a single goal than do multiple teams.

Why are specialist teams so common in software?  My intuition is that it's a social phenomenon that people with similar skills and interests tend to congregate, and like working together.  Finding an effective mechanism to counteract this force, while still maintaining high-skill and specialisation, seems like a Social Technology (in Malcolm Gladwell's terminology) that organisations will need to acquire to be successful.