Guest post: Building and scaling a startup - Feature or component teams?
There are some really cool startups in Berlin. Last week I met Alexander Grosse (@klangberater) from SoundCloud at ALE2011. Alexander is their VP of engineering and he had been thinking and writing about Feature teams. After reading his article I thought it would be a good and balanced view at that topic that could generate a good (and balanced) discussion on the blog. Alexander kindly agreed to let me publish it, so here it is!
The first team in a startup is a feature team by default. But as the company grows and you hire more developers, a common question pops up: How do you structure your engineering department when you have more than one team? Two common approaches are teams per component/service/layer or feature teams. This article describes the pros and cons of each approach based on experience.
So you have a startup. Let’s assume for the sake of simplicity it is a consumer facing website done in Ruby on Rails with an underlying database (but this article applies to other kind of startups too). You have around 10-15 employees, of which 6-10 are developers. These developers are one team, some of them concentrate on front-end work, some on the back-end, the mysql database is maintained by a handful of the developers. The team feels like it has reached the natural size limit and is considering splitting into smaller teams. Before discussing team structure let’s first talk about some important goals while scaling up the company.These goals should determine what you do:
Overall there should as much common knowledge as possible but specialists where needed. Let’s first discuss the terms “Feature Team” and “Component Team”, especially in a startup context. The usual definition of a Feature Team is: Feature teams are supposed to be cross-functional groups that focus the software development process in valuable-chunks of work, which normally cross the whole system (vertical slices of the system).[1]
While this sounds good you usually reach pretty fast the team size limit when trying to compose teams which can touch every part of the system. At SoundCloud we currently have 35 engineers working on topics like Android, iOS, Search, Anti Spam, MySQL, Operations, Web Front-end, Back-end and so on. So you can see very easily that if you define seven as an ideal team size, we have difficulties forming teams which can touch every part of the system.
A lot of consultants say that engineers should be able to work on any part of the system, but in reality and especially if you operate under scale, where for example every single SQL query can impact the site, this just does not work. Component Teams are usually defined as horizontal slices of a system, so for example front-end, presentation layer, business logic, database and operations. But I haven’t seen a startup which organizes it’s teams exactly that way. This is usually a team structure big companies choose. But what I’ve seen at a lot of startups is the separation between front-end, backend and operations. There are lot of obvious disadvantages associated with component teams:
So, we now have two approaches which on the surface both are not applicable for startups either at all or from a certain size on. Reading the post from Vasco Duarte ([4]) clarifies the situation in a very good way. Feature teams are not necessarily defined by their structure, but the most important thing is that a feature team can deliver value to the customer without dependencies on other teams. The reason for that is to reduce handover between teams which usually produces what “waste” is in terms of lean. Citing Vasco: A feature team is not defined by it's structure (being cross-functional), it's defined by it's output! (delivering shippable pieces of the system)[4]
A common anti pattern for the implementation of Feature Teams is (similar to the one mentioned in the article): design is not integrated into front-end teams. This often causes blocked user stories (waste) when design specs are either unclear or during implementation a necessary change in design has been discovered. In reality there is no such thing like having absolutely no dependencies on other teams. So we defined teams, which can work on the vast majority (at least 90%) of the stories in their backlog without needing other teams. How those teams are formed changes over time.
We at SoundCloud did not always have a stable API. So in the beginning front-end and back-end developers were one team until we were able to extract a well defined API, which offered the necessary functionality for all front-end clients (mobile and web). At that point we separated the joint web team as the front-end teams were now enabled to work on the majority of features without involvement of the back-end. Looking back at the start of the article where we defined that we want to have developers as much overall knowledge of the system as possible it seems like the chosen setup at SoundCloud violates that. To achieve a compromise, we encourage developers to rotate through teams. Some developers want to stay in their comfort zone (these are often the specialists mentioned above), some are interested in all parts of the system. As long as half of the developers in a team are aware of what other teams are doing, that team will be fine.
Combine both approaches The question is not so much which formal definition of team to follow. The importance is for teams to deliver the majority of stories in their backlog without depending on other teams. And team composition ought to change over time as the overall software stack matures. Analyze your teams if they can deliver value without depending on other teams (for at least 90% of the features). Do this regularly and team composition changes over time just as architecture does!
Inspired by:
[1] Scaling Lean and Agile Development, Larman, Vodde: Feature team definition on page 153
[2] http://blog.mountaingoatsoftware.com/the-benefits-of-feature-teams
[3] http://scalingsoftwareagility.wordpress.com/2009/07/15/organizing-agile-at-scale-feature-teams-versus-component-teams-part-1/
[4] http://softwaredevelopmenttoday.blogspot.com/2009/07/feature-team-needs-more-than-cross.html
Building and Scaling a startup - the Feature vs Component teams debate
Guest post by: Alexander Grosse from SoundCloud
The first team in a startup is a feature team by default. But as the company grows and you hire more developers, a common question pops up: How do you structure your engineering department when you have more than one team? Two common approaches are teams per component/service/layer or feature teams. This article describes the pros and cons of each approach based on experience.
So you have a startup. Let’s assume for the sake of simplicity it is a consumer facing website done in Ruby on Rails with an underlying database (but this article applies to other kind of startups too). You have around 10-15 employees, of which 6-10 are developers. These developers are one team, some of them concentrate on front-end work, some on the back-end, the mysql database is maintained by a handful of the developers. The team feels like it has reached the natural size limit and is considering splitting into smaller teams. Before discussing team structure let’s first talk about some important goals while scaling up the company.These goals should determine what you do:
- Developers should have as much knowledge of the system as possible, so that there is no single point of failure and technical decisions are made with an understanding of the overall system.
- There should be common approaches to most technologies like CSS and for some technologies, like databases, specialists are needed.
- Communication overhead should be avoided where possible as well as handovers between teams.
Overall there should as much common knowledge as possible but specialists where needed. Let’s first discuss the terms “Feature Team” and “Component Team”, especially in a startup context. The usual definition of a Feature Team is: Feature teams are supposed to be cross-functional groups that focus the software development process in valuable-chunks of work, which normally cross the whole system (vertical slices of the system).[1]
While this sounds good you usually reach pretty fast the team size limit when trying to compose teams which can touch every part of the system. At SoundCloud we currently have 35 engineers working on topics like Android, iOS, Search, Anti Spam, MySQL, Operations, Web Front-end, Back-end and so on. So you can see very easily that if you define seven as an ideal team size, we have difficulties forming teams which can touch every part of the system.
A lot of consultants say that engineers should be able to work on any part of the system, but in reality and especially if you operate under scale, where for example every single SQL query can impact the site, this just does not work. Component Teams are usually defined as horizontal slices of a system, so for example front-end, presentation layer, business logic, database and operations. But I haven’t seen a startup which organizes it’s teams exactly that way. This is usually a team structure big companies choose. But what I’ve seen at a lot of startups is the separation between front-end, backend and operations. There are lot of obvious disadvantages associated with component teams:
- Features often touch several teams, this leads to costly handovers
- Teams often act as silos and lose sight of the coherency and goals of the product But especially in large organisations component teams also have some advantages, like having dedicated teams for components - like databases - under scale. (please look at [3] for details)
So, we now have two approaches which on the surface both are not applicable for startups either at all or from a certain size on. Reading the post from Vasco Duarte ([4]) clarifies the situation in a very good way. Feature teams are not necessarily defined by their structure, but the most important thing is that a feature team can deliver value to the customer without dependencies on other teams. The reason for that is to reduce handover between teams which usually produces what “waste” is in terms of lean. Citing Vasco: A feature team is not defined by it's structure (being cross-functional), it's defined by it's output! (delivering shippable pieces of the system)[4]
A common anti pattern for the implementation of Feature Teams is (similar to the one mentioned in the article): design is not integrated into front-end teams. This often causes blocked user stories (waste) when design specs are either unclear or during implementation a necessary change in design has been discovered. In reality there is no such thing like having absolutely no dependencies on other teams. So we defined teams, which can work on the vast majority (at least 90%) of the stories in their backlog without needing other teams. How those teams are formed changes over time.
We at SoundCloud did not always have a stable API. So in the beginning front-end and back-end developers were one team until we were able to extract a well defined API, which offered the necessary functionality for all front-end clients (mobile and web). At that point we separated the joint web team as the front-end teams were now enabled to work on the majority of features without involvement of the back-end. Looking back at the start of the article where we defined that we want to have developers as much overall knowledge of the system as possible it seems like the chosen setup at SoundCloud violates that. To achieve a compromise, we encourage developers to rotate through teams. Some developers want to stay in their comfort zone (these are often the specialists mentioned above), some are interested in all parts of the system. As long as half of the developers in a team are aware of what other teams are doing, that team will be fine.
Combine both approaches The question is not so much which formal definition of team to follow. The importance is for teams to deliver the majority of stories in their backlog without depending on other teams. And team composition ought to change over time as the overall software stack matures. Analyze your teams if they can deliver value without depending on other teams (for at least 90% of the features). Do this regularly and team composition changes over time just as architecture does!
Inspired by:
[1] Scaling Lean and Agile Development, Larman, Vodde: Feature team definition on page 153
[2] http://blog.mountaingoatsoftware.com/the-benefits-of-feature-teams
[3] http://scalingsoftwareagility.wordpress.com/2009/07/15/organizing-agile-at-scale-feature-teams-versus-component-teams-part-1/
[4] http://softwaredevelopmenttoday.blogspot.com/2009/07/feature-team-needs-more-than-cross.html
You can find out more about SoundCloud at the Goto conference in Århus. Eric Wahlforss from SoundCloud will be speaking there.
RSS link
5 Comments:
So how do you avoid the waste caused by the discontinuity (i.e. by disrupting a "norming/ performing" team?)
By
@NickClare1, at September 13, 2011 3:47 PM
I guess I was thinking more in terms of having a scenario where only half the team were embedded and the rest were attached temporarily on an as-need basis to other teams. Perhaps it's only something you would do at (or soon after) start-up? To have a large number of people moving teams on a constant basis would seem to me to be a cause of potential waste (through discontinuity)
By
@NickClare1, at September 13, 2011 5:30 PM
@NickClare1
The concept you mention (have some members join the team on a need basis) was actually referred to by @snowded in his keynote at ALE2011 in Berlin.
His concept was that of a "crew" which in practice is a high-performing team that is assembled to purpose.
I have to look more into it, but understanding the behavior of teams may help us to adapt faster to business needs by assembling "crews" as needed.
By
Unknown, at September 13, 2011 6:52 PM
Good article. I'm, just wondering, whether you can treat component teams as feature teams, at some rate. It might sounds weird, but I think of the situation, that the customer for a component team is another team in the company, and in this way the component team could act as an "internal feature team".
I have a question about rotating team members: what is the affect of this rotation to the velocity of the teams? Is it still constant, or predictable? Actually this could be disturbed by frequent changes of the team structure? What options do you have to compensate this, or is it not relevant at all?
By
Tom, at September 29, 2011 2:59 PM
@Tom
About your question 1. In this and my previous article the emphasis was that a Feature Team is defined by their output as much as by their composition. It is not enough to have a cross-functional team with multiple skills, we must also have "complete and tested" output that can readily be released (where to is another question). So, yes the case you describe could fit the definition. However, I do want to caution against "hiding the holistic view", what I mean is that you should evaluate what is valuable for the end-customer (the one paying for it) and define your Feature teams around their needs, not around the internal process needs only.
Question 2: Velocity will always be disturbed by any changes to the team. So, rotating team members will definitely also disturb the team's velocity. However we must consider the reasons for that rotation. Sometimes rotating the team members is needed because that's what the business demands (like rotation for maintenance), independently of the effect on the team's velocity. Without a concrete case to analyse it is very hard to understand what you are asking about. Can you give me a concrete example?
By
Unknown, at October 18, 2011 4:41 PM
Post a Comment
<< Home