[Flash 9 is required to listen to audio.]
My new sounds:
Scaling a start-up
Feature or component teams?
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 that is (similar to the one mentioned in the
article) is that 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
<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/ <about:blank>
<http://scalingsoftwareagility.wordpress.com/2009/07/22/organizing-agile-
at-scale-feature-teams-versus-component-teams-part-3/>
[4] http://softwaredevelopmenttoday.blogspot.com/2009/07/feature-team-
needs-more-than-cross.html
<http://softwaredevelopmenttoday.blogspot.com/2009/07/feature-team-needs-
more-than-cross.html>
Scrum - Quo Vadis?
Ten years after the Agile Manifesto, Scrum is a mainstream software development approach. However, where has Scrum really proven to be successful? Many implementations are process- driven and neglect the core values of the Agile Manifesto and good software engineering by focusing purely on roles and meetings. Some organizations take the opposite approach and focus purely on XP practices. This article will take a look at what has proven to be successful and will show which approach is the most promising in which environment. Special focus is given on what can be considered as reasonable steps for moving from the current status of software development to something better (as the main intention should be to improve, not necessarily to simply introduce Scrum).
How often have we heard statements like “We do a daily standup and a sprint planning meeting, therefore we are doing Scrum and are Agile”? It should be obvious that this statement is far from true – but how could those misunderstandings happen? One of the core reasons is the way Scrum is (mis)understood and taught by Scrum consultants (who may have little experience in software development).
Developing software is not just a process; it is also about soft- ware engineering practices. Organizations need to invest in both: processes and engineering practices. Anecdotally, it seems that after the introduction of Scrum, some organizations appear to have a better process in place, but their software and its delivery have not improved.
As Scrum is introduced, a lot of money is usually made with certification and training, consultants are present during the first sprints, Product Owner, Scrum Master and team learn what to do and who is allowed to do what. However, will this really produce better software? The answer to this question obviously depends on how the organization developed software before Scrum was introduced. One thing is clear, however: you may be better, but you are far from optimal.
Let’s first look at what should improve through the introduction of Scrum:
- It creates visibility, to the Scrum team itself (where are we exactly, what are our next tasks) and to all stakeholders
- The existence of a prioritized and estimated backlog is very valuable
- Scrum aims for shippable software each sprint. This is a major step forward for typical organizations, where releases are done a few times a year and each release is very painful
- Rightly implemented, Scrum removes the typical barriers between Product Management, R&D and QA
So a lot of good things! Don’t get me wrong, this article is not supposed to bash Scrum. It should rather show what needs to be done after or during the introduction of it. So what is missing, or what are common anti-patterns seen in Scrum implementations?
- Often “Mini Waterfalls” can be observed: the first days of a sprint the team works on the specification, then they imple- ment and during the last days of the Sprint, there is hectic QA activity prior to the Sprint Review meeting.
- In a lot of Scrum implementations the only success criteria is that the Scrum roles exist and all the meetings take place. This has obviously nothing to do with Agile software develop- ment.
- Neither software engineering practices (like TDD or pair pro- gramming) have improved nor the delivery process of the software.
- As Scrum does not include Operations staff in its team, this barrier still exists.
Before discussing this further, let’s have a closer look at the Scrum roles.
The Scrum Roles
There are three major roles in Scrum (descriptions taken from the Scrum Alliance web page):
The Product Owner: Decides what will be built and in which order. Also he accepts or rejects work results.
The Scrum Master: Is a facilitative team leader who ensures that the team adheres to its chosen process and removes blocking issues.
The Team: Well, they are the ones who deliver the actual work.
So, you need a team that does the actual work, you need someone who actually determines what is being built, but do you really need a Scrum Master? Nearly everybody would answer “yes, of course you need one!”. Let’s have a closer look why the Scrum Master is actually there: To compensate for shortcomings of the overall process/team. Scrum should in theory work without the Scrum Master assuming that the team is really self-organizing. That means they don’t need to be dragged to the meetings, and the team (everybody) knows how to remove impediments. So, the evolution of an Agile team should lead to either no Scrum Master or to one with a very reduced role.
Scrum and Continuous Delivery
In Scrum the result of a sprint is “potentially shippable software”. This definition leaves a lot of room for interpretation; let’s just assume that for consumer facing Internet services this means a deployment to production. What happens if a team needs or wants to deploy more often? Doing a big Sprint review meeting at the end of a Sprint is not enough. Essentially, the Product Owner needs to constantly accept functionality, and the need for one big review meeting is gone. And by the way: The need for a retrospective is not gone, and this meeting should be held each Sprint/ Iteration.
Outlook for Scrum?
In my opinion it is time for two things:
1. There has to be something like a “Scrum 2.0”, which should address the current shortcomings, especially that Operations people are not part of the Scrum teams and that Scrum is introduced without software engineering best practices.
2. Companies should be clear that for a lot of them (not all!) the journey does not stop with introducing Scrum. Good soft- ware engineering practices (XP), automation and the ability to deploy to production more often are key.
In my view combining Kanban (limiting work in progress, deploy every feature which is done) and Scrum (Retrospective) elements together with XP practices is the way forward for having a strong software development unit.
Inspired by:
Striking a Balance: Let Scrum Die
http://architects.dzone.com/articles/balancing-software
SCRUM WILL DIE
http://simpleprogrammer.com/2010/02/23/scrum-will-die/
Scrum 3 Stages of Evolution – Explored
http://advancedtopicsinscrum.com/development/scrum-3-stag- es-of-evolution-explored/
Martin Fowler on Avoiding Common Scrum Pitfalls
http://www.infoq.com/news/2008/09/fowler-scrum-interview
Scrum Certification Test
http://www.infoq.com/news/2008/11/scrum-certification-test
and Martin Fowler’s keynote at OOP 2011
