There are two types of teams, Functional Teams and Cross-Functional Teams. A Functional Team, sometimes referred to as a Component or Specialty Team, is comprised of people with the same skill set. Cross-Functional teams on the other hand are centered around delivering the same business value and consist of people with different primary skill sets.
The Functional Team benefits from frequently sharing and bettering their specific skill set knowledge across the team. It is easier establishing and enforcing standards. Communication and collaboration within their specific skill set is very efficient, since they are all on the same team.
A Cross-Functional Team on the other hand benefits from having people with different primary skill sets so it can deliver the requested business value without or with minimal dependencies on other teams.
When looking at the two different team types, there are a couple of important questions we must ask ourselves to decide team structure.
Question 1: Do we currently have enough people with that skill set so we can place a person on each Cross-Functional Team that has a need for that primary skill set?
We don’t want someone being a member of four different teams. In fact, many Agilists believe that a person should only be a member of one team. I believe there may be exceptions, but there should be a good reason for it and once you split a person across more than two teams it should certainly raise a red flag.
Question 2: What will be the most important and most frequently needed communication and collaboration? Is it with others with the same skill set or is it with people delivering on a common business initiative?
Communications with and dependencies outside of the team are responsible for most of the delay in software development. If we can keep the need for cross-communications to a minimum, then we can minimize this delay.
I learned a valuable lesson a few years ago when I took an existing group of integration specialists and divided them up across cross-functional product teams. On the surface this appeared to make perfect sense. I thought the cross-functional teams would benefit greatly by requiring less hand-offs, better design decisions, simplified planning and improved speed of delivery. What I didn’t realize was the integrations people needed to communicate more with each other. The integrations code was legacy code. It wasn’t very loosely coupled at all and every time you changed something you had to coordinate with the rest of the team. Obviously, this technical debt needed to be addressed, but until that time it made more sense for the integrations people to be on one team.
The main point is to determine where the communication needs are and base your team structure on those findings. After I learned this important lesson through failure, I also found a book, “Management 3.0” by Jurgen Appelo, which addressed the topic in “Chapter 13: How to Grow Structure”. I highly recommend this book for this subject and other great information and insight.
Happy Team Growing!
nice story on the “integrations team” Phil .. good example of “it depends”. I find you not only have to consider communications but also where an organization needs to grow learning. If you need to grow depth of knowledge, the functional team may be a better solution. If you need to grow across (e.g., empathize with other roles and disciplines), cross functional may be a better choice.
I think there are factors we can list as to why people would need more communication functionally or cross-functionally. My example of legacy code in the blog is one. Recognizing that you need to grow depth of knowledge on a skill set in your example is another. I find that all these factors ultimately all roll up to communications need. Most of the time there is more than one factor, so in my opinion you need to consider all the factors and analyze them and then they roll up and determine your most needed communication channel. Ultimately at the highest level I believe it’s about the greatest communication channel need though. Your comment has made me think though, that there may be benefit for people in identifying those more prevalent factors. Thanks for your comment Mark – I always appreciate your experienced feedback and insight.
Good one Phil… In some large enterprise I am working with its been difficult to have cross functional team, however depends on how much decoupled the components are. If the components are highly decoupled and can be treated as product/platform and can be released independently then component team might work. However then comes how these each component team can work together across the teams and reduce dependency.
Thanks Sushil – appreciate the feedback and example.