Experts advise growing Agile projects with feature teams

Posted by Anand Vishwanath on Jan 11, 2012

Sections

Process & Practices

Topics

Scaling Agile ,

Agile Techniques ,

Agile

Share |

RELATED Research

 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?

RelatedVendorContent

Five Key Practices to Agile ALM

Agile Practices to Improve Project Management Organization (PMO) Effectiveness

Agile Maturity Model Applied to Building and Releasing Software

Agile assessments for your team

Agile workshops and training

Related Sponsor

Maximize your business-responsiveness with Mingle. Provide your global development team a shared space that adapts to the way they work.

1. Back to top

   Sounds like Feature Driven Development revisited

   by Dean Schulze

   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.

   Reply

2. Back to top

   Re: Sounds like Feature Driven Development revisited

   by Mark Levison

   @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: www.infoq.com/articles/scaling-lean-agile-featu...
   
   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.
   
   Cheers
   Mark Levison
   Certified Scrum Trainer | Agile Pain Relief Consulting
   agilepainrelief.com/

   Reply