Software Engineering, Project Management, and Effectiveness
When you build teams, one of the issues that comes up is whether to build a team of generalists or specialists.
On the Microsoft patterns & practices team, because I was doing project-based work, I was effectively building new project teams roughly every six months (it varied – in the earlier days it was more like every 18 months and in the later years, it was more like every 3 – 6 months. The bottom line is, I got to see a lot of patterns and practices for building effective teams, both on my own teams and across Microsoft patterns & practices.
In my experience, the teams that had a healthy composition of generalists with relevant specialist skills, performed the best.
They performed the best in terms of speed, flexibility, and quality. Why? Because there was less scheduling complexity depending on availability of specialists for the day to day work, while we would broker in deep expertise as needed.
So, we did use specialists, but we optimized around generalists with relevant specialist skills.
Having generalists with specialist skills also helped broker in additional experts, as well as keep things very pragmatic, rather than dive off the deep end. It also helped us bridge the knowledge and speak the language of the specialists, by having folks on the team that knew enough to be dangerous, and that were well aware of there limits … but most importantly, knew when to reach out, and who to reach out to.
Having a team of generalists with relevant specialist skills for the day to day work helped us better load balance the work, and to avoid significant bottlenecks either due to dependencies or simply by getting stuck. It’s easy to get stuck when you are doing knowledge work if you don’t have a team of capabilities you can rely on to keep the ball moving forward, and to sanity check the path.
With that in mind, in the book, Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results, David J. Anderson shares some great insights on the great debate between Generalists vs. Specialists. (Keep in mind, I’m a fan of the AND approach.)
Jone’s says specialists should outperform generalists. Agilists say, generalists will do better. Perhaps both are right. Anderson writes:
“Therefore, there is a plausible explanation to the conflict between Capers Jone's observation that specialists should outperform generalists and the Agile methodologists' contention that generalist developers will be better. Jones is clearly measuring organizations that employed specialists who were motivated and controlled by processes that led to good quality at every stage in the process. The Agile methodologists are clearly reacting to their environment. They are assuming that it is impossible to fix the systemic issues with analysts and both quality and performance can be improved by eliminating them.
Perhaps the final conclusion is that an Agile team of generalists will outperform a badly organized, badly incentivized, poorly skilled team of specialists following a traditional method. However, a good team of specialists, measured by properly set governing rules and focused on quality should outperform the team of Agile generalists. Hence, the Agilists and Capers Jones are not in conflict, the Agilists are basing their beliefs on differing assumptions.”
Maybe the generalist specialist is the answer? Anderson writes:
“Scott Ambler has suggested the ultimate solution to this problem . He calls them generalist specialists. These are software engineers with specialist in-depth skills in a few areas but adequate skills across a breadth of other areas. The generalist specialist is probably the ideal member for an Agile team. Such a team of generalist experts using an Agile method would probably perform even better.”
When you depend on specialists, the big issue, of course, is availability. Anderson writes:
“Specialist roles that will generally not be resource constraints tend to be horizontal and consultative in nature. These roles include language gurus who advice developers on esoteric or obscure elements in development languages, mentors and coaches, trainers, IT support staff, help desk personnel, program managers, project managers, development managers, and executives.
General developers or testers will generally not be constraints -- rather, in circumstances where they are in short supply, they would be classified as insufficiently buffered resources.
If the schedule is to be3 protected from delays, the additional resource constraints must be scheduled. The schedule must be designed to allow the resource constraint, for example, the user interface designer, to move freely from one task to the next without delaying the start of any specific large grained component. The feeding chains were planned with feeding buffers based on the notion that the start date is the latest possible date that the feeding chain components can be started without endangering the Critical Path. If a feeding chain was delayed because a resource was unavailable, the project would be in jeopardy.”
At the end of the day, specialists can be bottlenecks you need to account for when you plan. Anderson writes:
“Hence, the specialist resources must be scheduled across the PERT chart. Uncertainty surrounding the availability of a specialist resource must be anticipated in the planning. In the user interface designer example, it must be recognized that some sections of the project may require more design or be more difficult to design than others. Uncertainty generated by the complexity of the design challenge for certain elements of the project must be buffered appropriately. The schedule must reflect this.
This section should raise awareness that is it not a good thing to have too many specialist resources. Specialists are potential bottlenecks and must be schedule on the PERT chart as CCRs. They must be buffered and protected. Too many of them would produce a scheduling nightmare, and all the protecting buffers would result in increased Lead Time (LT), increased Operating Expense (OE), and reduced Throughout (T).”
Can you eliminate the need for specialists? Probably not, but you can limit and reduce your dependency on them, and use specialists more effectively. Anderson writes:
“XP eliminates specialists. There are no analysts in XP, no designers, no UI designers, or architects. XP encourages the virtue of the highly talented, highly skilled, highly educated generalist. By eliminating specialists, XP eliminates a large number of potential bottleneck points or constraints. However, this is a double-edge sword. Capers Jones has metrics to suggest that teams of specialists outperform generalists [Yourdon 2002]. Constantine has suggested that XP is bad for usability [Constantine 2001a]. Would the customer, for example, want a programmer to design the UI or would they prefer a skilled interaction designer and usability engineer?
However, eliminating specialists does eliminate constraints. There are no specialists to be schedule on the PERT chart and no specialists to be protected with buffers. There is no need for Critical Chain in XP.
In many cases, XP seeks to deny the Theory of Constraints whilst accepting that traditional software development is constrained. XP simply eliminates the constraints and moves on, for example, version control lock and technical specialists are eliminated through collective ownership and developers as generalists. This may, in fact, be appropriate on small-scale projects with highly talented people. It may be possible to ignore constraints because the people take care of everything and don't get into trouble. However, as projects get larger and the talent level of the team begins to vary, it may be necessary to look at other methods that seek to accept constraints for what they are. Rather than ignore constraints, they will identify, exploit, subordinate to, and ultimately elevate them. Denying constraints exist and denying the need for specialists in a large-scale system of software production may hold back the adoption of XP in larger enterprises.
Another approach to the denial of constraints could be to declare them paradigm constraints. XP could be viewed as a paradigm shift in software engineering. Hence, in a new paradigm, why should existing constraints be considered? Specialists are merely part of the old paradigm. Version control lock is equally part of a paradigm. By changing the working practices of development to a Lean interaction perhaps version write lock dies with the old mass production, specialist paradigm.”
In closing, I want to point out three key things to keep in mind when you think about generalists vs. specialists:
Happy team building.
How do you determine which of these you are ?
If you have been in the industry for almost 20 years do you naturally become a Generalist Specialist ?
@ Dragan -- Great questions.
1. Your past jobs and experiences should be good insight if you are a one-trick pony
2. Experience is overrated. According to Covey: "Some people say they have twenty years, when in reality, they only have one year’s experience, repeated twenty times."
A good place to start is to review some of the articles on "T-shaped people". It will provide some quick insight into breadth vs. depth.
I think the two most important ideas about breadth are:
1. Broad experiences -- you've used your depth in a variety of verticals or different scenarios
2. Broad competencies -- the department of labor has a map of personal effectiveness capabilities
In my experience, an individual gets more from there depth skill, when they learn:
- Business skills - what is the business of the business you are in
- Communication skills - can you play well with others and communicate impact
- Leadership / influence / persuasion skills - can you tell/sell your ideas
- Project Management / Execution skills - can you deliver or drive results
Thanks for taking the time to respond J.D Meier. You expanded on your answer to me further in your blog post "E-Shaped People, Not T-Shaped" which is awesome !