Role Specialization in Agile Projects

by Jim Highsmith, Director, Agile Product & Project Management Practice

The myth surrounding agile projects goes something like this: a small team of developers who can handle any coding task (database, business logic, user interface, middleware, etc.) works hand-in-hand with the end user who talks with the development team about the details of the work requirements. The small-team-filled-with-generalists model may work for some small projects, but it doesn't scale. The problem has been with confusing two parts of the traditional development problem: collaboration and specialized skills.

Let me say that well-rounded and well-grounded team members, ones who can fill several roles, are an asset. However, the art of agile management is balancing, and this is one of those areas where balance is required: both generalists and specialists are needed in most project teams. For example, the direct user may know a tremendous amount about his or her job specialty but not be able to analyze, generalize, and streamline the workflow of the department he or she works in. What then occurs is automation of the existing business process, not the required future business process. There is a distinct need for good business analysts in this situation, a role the end user may not be able to fulfill.

I once worked with a client whose business analysts were in Europe. They would gather requirements for the next version of the software, create a voluminous requirements document, and ship it off to the development group in the US. Twelve to 15 months later, the revised product would be released -- with very little additional interaction between business analyst and development staff -- with, of course, marginal results. This was not a problem of having the business analyst as a role in the project; this was a case of lack of collaboration between the business analyst and the development staff. This was also a situation of believing that documentation could adequately convey the customer's requirements.

Now, there is always the problem that the business analyst begins making too many assumptions about what the customers want, in effect thinking him or herself the customer, but this too is a collaboration and feedback issue. The business analyst must work closely with the customer, and the customer must see product demos periodically to make sure the business analyst and customer are still in sync.

Similarly, as projects get bigger, specialty roles become more useful and necessary to a project team. While experienced developers may have some database design and implementation experience, database expertise can be very valuable in a large project. The same goes for other specialty areas, such as user interface design and application architecture. I was once talking with an architect who was busily developing and documenting a rather complicated architecture, which was new to the development group. I asked him what types of presentations, meetings, pair-programming sessions, and the like he was planning for knowledge transfer to the development teams.

"Oh," he said, "I don't have time for anything like that. The documentation is very complete." Wrong answer. It's not that his architecture work was bad; it was that he didn't understand that what would convey his work to the development team was collaboration and interaction, not paper.

Having a generalist on a team is a good idea, but it takes time for someone to gain experience across a broad range of technical skills. A generalist can look beyond his or her specialty area and help the team make good, broad-based decisions. Having specialists on a team is also a good idea; they bring deep knowledge that can benefit the product development. But without good interaction and collaboration, neither generalists nor specialists will succeed.

I welcome your comments on this Advisor and encourage you to send your insights to jhighsmith@cutter.com.

-- Jim Highsmith, Director, Agile Product & Project Management Practice