pizza-team).
Such a team is made of enough people to achieve the project. Therefore, it must be given the necessary autonomy to take decisions according to the company's strategy, and the responsibility to reach its objectives (which of course must be reachable).
We can schematize a cross-functional agile team and other actors with whom the team interacts closely this way:
A few interesting questions arise here:
-> Is the company ready to create small collocated teams mixing business and IT (developers, testers, even operators) for them to work together every day? -> Are the members of these teams motivated by this gathering and the direct communication it enables? Depending on the company's culture, setting up such team structure may not be easy, especially when it comes to communication. Where it used to be ruled by documentation, it becomes more direct. Issues and their argued solutions become the responsibility of the team. Its members have to review their whole working habits.
Another issue also emerges: how to share knowledge between people of a same trade (for instance, front-end developers) who are now scattered into different teams. A possible solution is the creation of communities of practice enabling periodic meet-ups for these people to share their expertise and good practices.
At last comes the sensitive topic for any transformation: the (re)definition of roles within teams, including the new place for middle management who used to ease transit of information… To address these important matters, we recommend to test this kind of organization with 2 cross-functional teams comprising several people eager to experiment this organization. The try-out should last several months (at least 6 months). At the end of this pilot stage, the members will have apprehended and adapted the roles for a better match of the context, and will be able to provide a feedback on the experiment.
To loosen coupling between cross-functional teams, some organizations specifically dedicate them to the development and support of a clearly defined functional scope. These are feature oriented teams, or Feature teams.
Here is an example by Henrik Kniberg of Feature teams as seen at Spotify:
-> Can the company identify within its activity independent features that could be handled by loosely coupled teams? -> Is the software architecture compliant with such organization?
It is worth stressing that feature teams need to be as independent as possible from each other, on both organizational and product architecture levels. A feature team must be able to deliver a new version of its scope without impacting other teams, fostering an optimal TTM.
"Component-oriented" teams:
Dean Leffingwell (author of the SAFe framework) presents here this difference between Feature and Component teams:
-> Are there any "component-oriented" teams within the company that are likely to stay organized this way?
Component and Feature teams are not incompatible. However a Component team may face a few limitations:
To limit these issues as well as the global TTM of an organization, one should keep the number of Component teams lower than the number of Feature teams. We believe the proper proportions to be Feature team [70-80%] vs Component team [20-30%].
An organization with specialized cross-functional teams solves many issues encountered in a company organized in silos.
You can find many examples and resources regarding this topic on the web (starting with this article about Feature teams by Craig Larman, or this video dealing with agile at Spotify). Nonetheless, beyond the chosen theoretical organization, the true challenge is actually implementing this new communication model between the key players. An experimenting phase between employees motivated by change is a great way to initiate this kind of transformation.
What about you? What team organization do you implement?