Specializing Generalist
by Scott Sehlhorst, 1 February 2012 | The Agile Blogosphere
This post is from Tyner Blain by Scott Sehlhorst. Click here to see the original post in full.
The ideal agile team is made up of specializing generalists – but what does that really mean? The goal isn’t to prevent functional silos of expertise, it is to allow people to cover for each other.
Great Conversation
Elena Yatzeck (@eyatzeck) posted a comment on an earlier article about agile maturity models.
In terms of refinement, I’m thinking a lot these days about “staffing the engineering team correctly.” I’m not sure I agree in practice that you can or should try to staff all teams with “specializing generalists,” or at least not as taken to an extreme. (If you’ll forgive the self-promotion, I talked more about this here: http://pagilista.blogspot.com/2012/01/no-blender-zone-cross-functional-doesnt.html.)
I’ll not only “forgive” the promotion, I’ll re-promote it. Good stuff.
When re-reading...
read more
Hey Kelly, thanks for the props! Anything you would add to the conversation?
Hi Scott. I didn’t make any comments because I don’t think I have anything to add, other than to say that I completely agree.
When hiring people, we always used to make sure people were prepared to do things that are not in their job spec if it helps the team to achieve their goals.
In particular, developers should be prepared to do their own analysis, and test their colleagues code. Testers should be prepared to assist with analysis, sometimes morphing into a combined analyst/tester role. Project Managers and Business Analysts should be prepared to test.
Generally this level of flexibility means that work can flow through the team and not get stuck in bottlenecks. But obviously we still attempted to optimise our teams so people could generally do what they specialised in, partly because of their higher skill levels but also importantly because that’s what they wanted to be doing.
Kelly.