This is one of the hardest habits for organisations to break, and yet one of the most critical, because the core of this problem is people, not organisation structure.
In an Agile environment, an Agile team delivers fully tested and working software. If you're new to Agile, it's worth holding that thought in your mind for a moment and rolling it around a little. It's actually a very big idea. Although it should not need pointing out, a team comprised solely of architects does not deliver working software. Neither does a team of testers or a team of code monkeys.
In fact, it's a very fundamental assumption of Agile that a team contains within it all the skills required to deliver a product increment that works. Maybe you have several teams working on different features of a product - Agile still assumes that each team can do all the work required to deliver it's working software ( this may not be an entirely safe assumption - see my thoughts about Design ).
Note however, that the Agile Principles do not say anything about the internal organisational structure of 'a team', other than to note that 'self organisation' is beneficial. Defining what 'a team' really is and how to coordinate the activities of different teams is a philosophical adventure in it's own right, which I will need to dig into.
But before we go off the edge of the map here and start talking about scaling issues, let's just think about the human dimensions of this.
Many people view specialisation as a route to career success, and will have invested a lot of time and effort developing expertise in a relatively narrow field. They may be reluctant to act outside of this field, either because they are not confident to do so, or because they believe their career prospects may be adversely affected. Perhaps they justify their position on the grounds of productivity i.e. 'I have expertise in X so I can deliver more if I do X'. Perhaps they simply say 'X is what I enjoy doing, why should I force myself to suffer doing Y and Z as well ?'.
Therefore one approach to building an Agile team would certainly be to make sure that it contained experts in all the necessary domains, and within the team their primary contribution would be in the domain covered by their expertise.
However, there is a strong assumption in Agile philosophy that Agile team members will do any work that helps to achieve the goals of the team. From the perspective of a Scrum product owner for example, it doesn't matter who designs what, who codes what, or who tests what. It's the team that does these things, and importantly it's the performance of the team that is visible to the outside world.
In addition to this, maintaining strict domain responsibilities within a team can have the undesirable side effect of linearising the work, meaning that work is done via a sequence of 'internal handoffs' as designers feed coders who feed testers. Agile regards such handoffs as undesirable, since they effectively create mini-waterfalls within each team, and reduce its capacity for work.
The result of all this is that Agile really wants the members of an Agile team to be, or to become, quasi-generalists. These are people with sufficient experience and general smarts to pick up skills from other team members whenever that is useful and to let management know if they require training or specialized support from outside. It doesn't mean they have no domain expertise, but it does mean they will do whatever it takes.
This poses a problem at the business level for many organisations, because pigeonholing people is a major sport for hiring managers and HR people, and Agile changes the rules of the game somewhat. Flexibility and general smarts become as important as specific skills.
New hires are not really the pain point here though - the real problem is that there will be people in the organisation who are not quasi-generalists, don't want to be quasi-generalists, and never will be quasi-generalists. I have no easy answer here. Agile requires adaptability, and people who cannot adapt may have to be left behind.
None of this means that specialists have no place in the Agile world. It's expected that specialists would work with product owners and other planners to help define products for the business, for example.
But they must also be prepared to directly share their knowledge with the people who are actually engaged in creating that product.
Agile is, IMHO, strongly opposed to the 'Ivory tower' pattern, in which specialists simply hand off specifications, often developed independently of any particular product, and move on to the next sexy problem in their world. There is nothing in Agile or Scrum which says that the team can only communicate with the outside world via the Product Owner or Scrum master. If the team needs specialist input, it should be able to just go get it.
© Mark de Roussier 2021, all rights reserved.