Ideally, agile software development teams should be multidisciplinary, that is, possess all the skills needed to deliver the business solution. This is documented in the eXtreme Programming rule called ‘Move people Around’. “A team is much more flexible if everyone knows enough about every part of the system to work on it.”
It sounds good in principle but it’s not always easy or cost-effective to assemble and cross-train such a team. There are many skills needed to deliver high-quality software within an enterprise environment. Let’s assume you’re forming a new software team and you want it to be self-sufficient.
What skill sets should be on the team?
Obviously, the team needs people who can write code in whatever language(s) is/are being used. They’ll also need one or more people who can write automated tests and perform independent evaluations of code quality. Is that enough?
If the software system is small and relatively isolated, add a team leader or Scrum Master and a Product Owner and you’re good to go. The team will need to have a variety of skills (be composed of generalists) to accomplish everything needed but that’s manageable.
But, what if the software system is large, complex and part of an enterprise ecosystem? Can the same team composition take on this project? Here’s a sampling of the skills such a team might need.
- UX Designer (e.g. usability)
- Graphic Designer (e.g. user interface elements)
- Front-end developer (e.g. browser or desktop application)
- Middleware Developer (e.g. application server)
- Back-end developer (e.g. database access)
- Middleware developer (e.g. system integration)
- Database administrator (e.g. database design)
- Security Specialist (e.g. access privileges and data encryption)
- Business process analyst (e.g. workflow rules)
- Data Analyst (e.g. reporting)
- Software tester (e.g. automated regression tests)
- Technical writer (e.g. user guide, training materials)
While it’s certainly possible for a small development team to possess all of these skills, that’s unlikely to be the case. It’s also unlikely that the team’s skills would be as strong as they could be if the team members were specialists rather than generalists.
Can they still get the job done?
Assigning dedicated experts to the team is just not practical. Does the team need a full-time graphic designer or database administrator? Probably not, but they need a support structure. They need access to experts as needed.
In a small company, third-party services firms can help. In a large company with many ongoing projects, it makes sense to hire experts and have them shared across projects. But, an additional challenge is introduced.
The use of shared experts has be monitored closely. If demands on the experts’ time exceed their ability to deliver services, the teams will have to wait and deadlines will be missed.
Multidisciplinary teams are an agile development holy grail but they’re just not practical when building complex systems. Overloading the team members with required skills will create an Achilles’ Heel and reduce their effectiveness.
I believe the problem can be managed using Centers of Excellence. I’ve advocated the Centers of Excellence approach to sharing expertise in large enterprises before. It’s cultural shift that really works. You can read more about it in this post.