Function team vs. feature team – a definition

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

I got the question “explain the difference between a feature team and a function team”. When I answered, I realized that many people uses the term without attaching an explaining what they mean. So here is how I define it.

Dynamic Feature team

Team is organized around features. Teams are dynamically created allocating necessary skills when feature arrives, disabandened after feature is done. Works end to end.

Fixed Feature team

Teams are organized such they can work end to end. Kept stable over time. Work is not adapted to fit the team skills, rather the team is asked to gain any skill necessary to solve the problem. Works end to end.

Function team

Team is organized around a product part with link to business responsibility. Stable over time. Works end to end. Example: Musik player team, Reports team, Payment team.

Component team

Team is organized around a component in the system, often related to a certain technology. No direct business responsibility. Stable over time, does not work end to end (requires handover and collaboration with others to turn work into runnable software).  Example: Core team, DBA team.

Teams can be described using two dimensions – a professional role dimension (analyst, ux, developer, tester) and a functional / subsystem dimension. It is recommended that teams as far as possible contain a cross section of skills in the professional role dimension, so they can produce running software.

So, when should you use what?

A good view is to take the product life cycle perspective.  In the early phases when the business case is unclear a feature team is valuable. It can quickly iterate the solution space without a predetermined view of what technology to deploy. But if the business case has been proven (you have some customers) and your focus is to expand or cross sell, Function teams are a good pick. They build on top of existing solutions (you don’t need to reinvent the wheel every time) and they keep maintenance cost low.They do this with a business understanding keeping the transaction cost of relaying the business problem to a minimum.

Generally Feature teams carries the drawback of generating fat design (you end up with several similar technical solutions, like MVC frameworks if you have several teams).  Their upside is less “lock in” in the solution space. Function teams keeps costs low and are (often) faster, since they don’t need to reinvent the full solution every time.

A component team is useful when the solution becomes more complex. The value it provides is to simplify the problem that a feature/function team needs solved. Component teams should be used with caution. If you have one, it has to obey the golden rule: never be a blocker.

In all cases: focus the teams to work end-to-end.

Leave a Reply

Your email address will not be published. Required fields are marked *