One of the technical practices of Agile software development is to support cross-functional teams where members perform multiple activities like requirements, coding and testing. In their book “Being Agile”, Leslie Ekas and Scott Will discusses the difficulties of creating a whole team.
Traditional software development organizational structures have advocated for teams that specialize in technology and are grouped by a common discipline, for example, development, test, user documentation, and so on. The reasoning goes that teams composed of people with similar skills can help each other within their own domains. Furthermore, it is believed that teams that share a common discipline can be “time-sliced” across various projects as needed instead of focusing on one project at a time. This is the epitome of the “job-shop” mentality in which engineers just do their specific job and lose sight of the bigger picture. Unfortunately, optimizing the efficiency of a particular discipline almost always sub-optimizes the organization – a point that is often not well understood. Lean thinking in particular focuses on process throughput optimization to improve efficiency, versus individual throughput.
The whole team approach advocates the idea of team members being “generalizing specialists” who have deep skills in specific disciplines, domains, and technologies but who can also work outside their area of expertise to help achieve the team’s iteration goals. At first, teams shy away from this aspect of the whole team concept because they interpret it to mean that everyone on the team must do everything. In small, high-performing agile teams, this may be the case, but it gets more difficult as projects grow in size and encompass many technology domains. However, teams do not have to achieve the ideal level to become a whole team – but they should at least move in the direction of becoming “generalizing specialists.”
Source: Being Agile: Eleven Breakthrough Techniques to Keep You from “Waterfalling Backward”, Leslie Ekas & Scott Will, IBM Press
It is always difficult when you have to switch from a silo organization that has separate departments for business analysis, programming and testing to a Scrum approach where people have to cooperate strongly to produce meaningful results in short iterations.
As Leslie Ekas and Scott Will wrote it “optimizing the efficiency of a particular discipline almost always sub-optimizes the organization”. In my experience, this also produces communication issues as information is transmitted many times trough multiple people before reaching the point when it is used. However, I think that the main issue is the dilution of responsibilities that happens in this type of situation as we often have a natural tendency to blame other people when there is a problem. If a single person or many team members work together simultaneously on requirements, code and tests, this create a sense of responsibility for the finale result.