Facilitating the spread of knowledge and innovation in professional software development



Choose your language

InfoQ Homepage News Experts advise growing Agile projects with feature teams

Experts advise growing Agile projects with feature teams


 Agile practices have worked well with small teams comprising of five to nine people. But what if the customer wants more software and is prepared to spend more money to get it. How can you increase productivity by safely ramping up an Agile team?

Martin Fowler warns against a premature ramp up of an Agile team as it can lead to a break down of communication and can also break down the cohesion of code base itself.

This break down occurs because the new people don't understand how the code base currently works, so they do something at odds with it, like adding a competing framework. If there are too many new people around, the team leadership can't keep track of it all and the code base sprouts problems. These problems then reinforce each other because nobody can find a consistent way to do things

Martin suggests starting with a small team and ramping up slowly.

One of the firmest bits of advice I've heard from people who do large projects (anything over 50 people) is that the project should start small, maybe with just a dozen or so developers. They should figure out the key design elements and interactions of the system by building early parts of it. Only once that design has settled down should you think of increasing the team size to its full size.

Esther Derby talks about practices beyond Scrum of Scrums that can be useful for scaling a team.

  • Organize teams around context boundaries rather than component boundaries wherever possible (Context could be a feature group like “Order entry” in a sales system).
  • Make communication across context boundaries explicit. Use integrating teams to agree how to handle the interface and integration between systems. Integrating teams should write acceptance tests that confirm integration across boundaries.
  • Add “Component Shepherds” who work towards maintaining integrity of components or shared services by reviewing code and coaching teams.
  • “Tech Councils” (made up of integrating team members, component shepherds, and test experts) should attend to the integrity of the whole system.

James Shore suggests creating high performance work cells which are based on the Lean principle of “one-piece flow”.

The Lean work cell maps almost perfectly to the Agile idea of the cross-functional, co-located team using simultaneous phases. Rather than using the phase-based approach of handing off responsibility from group to group (requirements, then design, then coding, then test), an Agile team takes responsibility for one or two features at a time and works on them as a whole until they're done.

Siddharta Govindaraj offers a similar method called Feature Teams and provides a practical example on structuring the same.

Consider a new story that is not yet started. Team members from the main team will decide who wants to be a part of the feature team for that story. In the simplest case, you may have one or two developers and a tester volunteer to be a part of the feature team. This decision can be made either at the start of the sprint, or just in time later on. Once the feature team is formed, it is their responsibility to work together and deliver the story. Once delivered, the feature team breaks up and each team member signs on for a new story, joining a part of a new feature team.

What practices have you benefitted from when ramping up an Agile team?

We need your feedback

How might we improve InfoQ for you

Thank you for being an InfoQ reader.

Each year, we seek feedback from our readers to help us improve InfoQ. Would you mind spending 2 minutes to share your feedback in our short survey? Your feedback will directly help us continually evolve how we support you.

Take the Survey

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Sounds like Feature Driven Development revisited

    by Dean Schulze,

  • Re: Sounds like Feature Driven Development revisited

    by Mark Levison,

    • Sounds like Feature Driven Development revisited

      by Dean Schulze,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      Your concept of Feature Teams sounds like a case of reinventing the wheel. David Anderson wrote a book on Feature Driven Development that goes into much more detail about developing a project based on features.

      I laughed when Martin Fowler said that starting small meant a team of a dozen developers. Most teams I've been on have been less than a dozen developers. A dozen senior developers working efficiently can create a very large project quickly.

    • Re: Sounds like Feature Driven Development revisited

      by Mark Levison,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      @Dean - FDD and Feature Teams are two different things. Feature teams are described in detail in Bas and Craig's first book: Scaling Lean & Agile Development, see the key chapter on InfoQ:

      The key point of a feature is to have everyone you need to work on a feature (i.e Front end to back end, all technologies) on one team. This is a real issue in large organizations (think 500+ developers) where today they may have component teams 5-10 layers deep. In this approach the people on the back end have never seen a customer nor do they have a deep understanding of their needs. The feature team approach would create parallel teams vs. the stacked approach of tradition.

      Feature Driven Development (working from memory here) isn't talking about the same scale of problems. I also suspect that David would use a different approach today than he did back then.

      Mark Levison
      Certified Scrum Trainer | Agile Pain Relief Consulting

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p


Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.