This article was originally published here on LinkedIn
The Scrum guide states that it “recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person”. I have read a number of posts and articles recently that seem to have taken a very narrow reading of this statement and imply (or even claim quite strongly) that specialisation within an agile team is a bad thing. Interestingly, it is often certain specific specialisations that these people seem to dismiss. These include business analysis (or service design), UX design, and sometimes technical architect. It’s notable that I’ve never seen anyone describe software development as being a valueless specialisation. Some of these articles I seem to imply that a goal of the agile coach should be to ensure that every member of the agile team acquires all of the necessary skills to deliver the product. In this agile nirvana they would have not just technical skills but also the soft ones such as eliciting requirements and understanding underlying business drivers.
The authors of these articles overlook that fact that the Scrum guide does go on to say, “Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.” I believe that the authors of the guide are emphasising team responsibility and are making the point that hand-offs within the team are the responsibility of the team and no-one else.
I’ve become increasingly uncomfortable with this stance and, as is my wont, I turned to DuckDuckGo (google for the paranoid) to see if anyone else out there shared my concerns.
Luckily I found a couple of really good posts, meaning that I can make this article shorter than it would otherwise be.
My first objection is that our modern world is built on increasingly narrow specialisation. 500 years ago it was possible for an educated person to know all available scientific knowledge. Now it’s not possible for one person to know all of one branch of a subject in science. By advocating a team that consists solely of generalists that possess or can acquire all of the necessary skills to deliver the product, the writers are rowing against the tide of history.
Here’s an article that puts specialisation in a historical context:
My second objection is that it would be very difficult for most organisations to find enough people with the breadth of skills required to fill a single team, never mind covering all of their product development needs. When I started work, it was back in the early days of the IBM pc. I was an “analyst-programmer” as were many of my colleagues at the time. Over the years I have done pretty much every job there is to do in IT, from analysis, development, testing, through to on-site support (though I’m still a pretty rubbish UI designer). As time goes on I find fewer and fewer people with my sort of background (most of them turned to management long ago). Theoretically then, I could be one of those generalists that can do anything in a team. However, in the 15 years or so since I stopped committing code on a regular basis, the whole thing has got more complex. There are more languages and bucketloads more frameworks and apis to learn. Sure, I could pick up angular.js if I had to, but it would take me a while…
There is so much breadth and complexity even in niche areas of programming that it is not surprising that programmers choose to spend their time keeping abreast of developments in their own specialism rather than learning a skill which will place them way outside of their comfort zones.
As an example of extreme specialisation, I once worked with specialists in java persistence frameworks (for non-techie readers, a persistence framework is a thing that programmers use to make sure that the stuff that you type in to an app doesn’t get lost). There are at least 44 different persistence frameworks for java so you can see that even this tiny part of the programmers’ art contains a lot of knowledge.
Here’s an article that explains the organisational side of things pretty well and for good measures throws in some rational reason why specialists might not want to become generalists
So, given that specialisation isn’t going anywhere, what is the agile leader to do? Well, the first thing is to ensure that your team as a whole has the right mix of skills needed to develop and sustain your products. Note that I am talking about skills, not experience here. A skilled software developer that knows java can easily learn .net. Equally, a business analyst that knows the publishing industry can easily learn about financial services. In fact, in the case of business analysis, I would argue that it is often an advantage for people to come in to a business domain fresh, as their minds are not polluted by “the way things have always been done”. However, it is a very different thing to ask a software developer to learn analysis skills or an analyst to learn coding skills. Individuals may have the capacity and the desire to learn both (I did) but many don’t and they should not be expected to just to fill a skills gap.
How to tell if you have the right skills mix? Well that’s where Kanban comes into its own. Kanban will show you very quickly where are the bottlenecks that are caused by skills shortages. In Scrum, taking a snapshot of the board at the end of the sprint, coupled with feedback from the retrospectives should tell you where to look.