Early on in my agile practice, I believed in generalizing specialists. I even wrote Five Tips to Hiring a Generalizing Specialist. However, if a team becomes collaborative, I no longer think we need generalizing specialists. That’s because the team works and learns as a team. If a team is willing to collaborate as pairs, a swarm, or mob, you might not need generalizing specialists at all.
Why Generalizing Specialists
Back in the waterfall world, many people had narrow specialties. They only architected or designed, and only in the platform. Or the middleware. Or the app layer. Or, they were only testers of one variety of another.
The whole idea of generalizing specialists is that people would have multiple capabilities. They could stretch what they do past those quite-narrow boundaries.
However, some people thought they could get developers to be system testers—and vice versa. I have never seen that occur. Or, they could get platform people to design a UI. I’ve never seen that work, either. (I am an old platform-level programmer. You do not want me to design your UI. I still like the command line. Nope, you don’t.)
Consider Empathy for Others, Not Capabilities
Instead of thinking about stretching capabilities or specialties, what if every person on the team had empathy for what the other people needed to do? What if everyone learned and delivered as a team? We wouldn’t need generalizing specialists. We would need collaborative teams.
Here’s how this might work for your agile team.
The Team Discusses the Backlog
Teams take in work in the form of a backlog. Even if your team works in continuous single-piece flow, the team addresses and then takes one piece of work—their backlog. If your team works in iterations, your team might address somewhere between five and ten items.
That “address the work” part is what Scrum teams call either backlog refinement or iteration planning. The team looks at the work and discusses their concerns, ideas, acceptance criteria—you name it. The team comes to agreement on what that work is, and what done means for that work.
In effect, as long as the entire team mobs when they discuss the backlog. They might not mob the way a “real” mob should, handing off the driver/primary navigator roles, but they work together in real-time on that one effort.
Warning: If your entire team does not discuss the backlog together, that’s a trap. You don’t have an agile team because they’re not collaborating on the work.
Team Members Work Together to Select and Complete Work
When team members collaborate, they have at least these options:
Pairing, when two people collaborate on one item of work. The arrows in this image are supposed to note that the people switch off on driving and navigating.
Swarming, where the entire team works on the same item, but they work according to their specialty. The way I see swarms work well is when the team gathers to discuss the one item. Then, they each do their own thing. They regroup every hour to see progress and if anyone has trouble. When one person completes “their” work, they ask, “How can I assist anyone?”
Mobbing, when the entire team works together on one item. The arrows in this image are to show how each person takes turns at the driver/navigator position.
These three practices are the primary ways people collaborate in real-time. Your team might want to work in triads, or something else. I’m not ruling that out. I’m only saying that these are the primary ways. Do what your team needs.
Team-Based Collaboration Leads to Team-Based Learning
When team members work with at least one other person, they learn with and from each other. They don’t need to hire generalizing specialists.
They do need empathy with each other. That empathy might extend to the customers and users.
When people have empathy with each other, they tend to learn how to do those little accommodations that make all the difference:
- An API so testers can write test automation below the GUI
- Hooks for logs and demos
- Anything else that makes development, testing, demo, and release easier
When teams collaborate on the work, they tend to succeed better.
So, I no longer believe in generalizing specialists. I much more believe in (and have positive experience with) a strongly collaborative team. Where people work together on fewer items at a time. My experience is that these people tend to release those items faster.
When the team collaborates as a team, they might not need generalizing specialists.
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Rethinking the Need for Generalizing Specialists Opinions expressed by Java Code Geeks contributors are their own. |
