Agile working means, among other things, promoting “feature-driven” or “cross-functional” teams in an organisation or a project and to avoid a silo mentality – no matter where. Cross-functionality means in a team to combine all the skills it needs in order to develop and finalise a feature that is in itself complete – instead of distributing it among several teams, as is often the case in practice. IT, for example, is often organised, controlled and performed in so-called component teams.
Component teams are teams that are responsible for the development of a part of the entire product development cycle, i.e. for a component. Component teams can be divided, for example, into a team in software development, a team for database management, a team that implements caching mechanisms, and a GUI team that builds the visual interface for the user. Simply put, with component teams there is always a separation between the components in backend and the frontend.
This separation becomes logical when looked at from an IT perspective. Finally, there are specialists who are trained precisely for the development of one component and are also employed to do so.
However, the component structure involves a number of significant disadvantages, of which every organisation should be well aware and should possibly scrutinise and reconsider their respective project structure.
Consequences of organising in component teamsOne of the main consequences is that the teams are less able to see the ‘whole’. In other words, the team is not able to understand the product development from beginning as well, and they do not feel responsible for the success or failure of product development that goes beyond the team boundaries. Therefore, they would be also less committed to measuring the product development cycle, identifying bottlenecks, and taking joint initiative in making improvements. Another negative aspect is the loss of identification with the end product, which occurs sooner or later.
The other important consequence is that organising in component teams creates strong dependencies among the teams, because the components must be sequentially developed: Team C can only begin development once the result of Team B is available. And Team B can only start once Team A has made its development available. These dependencies lead to
A feature is therefore only done once all teams have made their contribution. This means that a feature must pass through the entire sequence of the product development cycle in order to be delivered to the customers. The component teams often do not work as effectively hand in hand, which results in significant delays in the delivery of a feature.
Further examples of component teams include
Especially when an organisation or project operates in a complex environment, it will eventually become sluggish. Examples of why this occurs include that there are many and frequently changing requirements of many different stakeholders and customers, no experience with specific technologies, or the project operates in a scaled development environment with several parallel teams. In order to once again restore the ability to make quick decisions, more reliable planning and delivery, employee identification with the product and more responsibility among the employees for the entire product development cycle, one of the agile concepts proves to be the ultimate lever: ‘encourage cross-functionality wherever possible, that means, the view and responsibility of project organisation in its entirety – end-to-end’.
Would you like to learn about agile concepts and working methods? In November, we will offer a seminar incl. web-based training on ‘Agile Project Management’.
Frankfurt School gGmbH
Adickesallee 32-34
60322 Frankfurt am Main
