Continuing on from my last article, now we’ll examine the challenge of working with small or large teams. Which is better, more effective, and gets more done?

Fourth Story – Chrysler C3

The original Extreme Programming project was the inspiration behind the Extreme Programming agile approach. I wasn’t part of the project, but my understanding is that it was a typical, large-scale, Waterfall project that failed. There were perhaps 50+ folks who were working on the effort for over a year.

When the project was initially cancelled, it had been a dismal failure. The story goes that Kent Beck made a case for a much smaller team to use a different approach to try and “recover” the project. The team was about 20% of the original team size.

And as you can guess, the team recovered the project and delivered a workable HR system. But the project never met the overall goals and .

This was the project where Kent, Ron Jeffries, and several other famous agilists earned their chops. It also inspired XP as a popular methodology and initiated the movement, as it exists today.

The majority of software projects today make use of XP practices even if they’re not “agile”.  Those early XP “experiments” in things like pair-programming, refactoring, and continuous integration have proven to be incredibly sound ways to iteratively build software.

The lesson: a small group of focused technical folks can do big things IF they apply the principles and practices of the agile manifesto. Bigger isn’t necessarily better.

Fifth Story – iContact vs. MailChimp

I worked at from 2009 – 2012. iContact provided a SaaS email marketing application that competed primarily with and . At the time we mostly focused on MailChimp because of their phenomenal customer growth.

Beyond their being a direct competitor, we were both agile shops. And I was at the time and still am enamored with the nimbleness of MailChimp.

In 2012 iContact had nearly 400 employees. Around the same time, MailChimp was reported to have approximately 80 employees. So they were 20% of our size.  I just did a LinkedIn search for MailChimp and it showed 106 employees. So they are still relatively small and nimble.

What’s my point?

Well, to put it bluntly MailChimp cleaned our clock! They kicked our butt when it came to head-to-head comparative measures of our SMB email marketing applications. They were quicker to deliver features. They were quicker to change and pivot directions. They were more creative, bringing out a freemium offering that drove tremendous growth A strategy that we tried to copy and failed.

I’m currently a MailChimp customer and I’m amazed how insightful they are into the needs of their customers and how frequently they bring out new and, more importantly, useful features.

If you extrapolate from the numbers, we had about 100 people in technology. Mailchimp would have had 20-30 of the same folks developing, deploying and supporting their products.

I was at the time and still am envious of them. They were truly agile in spirit and action. They had an incredibly small team that built and evolved a robust email platform that simply rocked in its market space.

The Lesson: We all seem to have a tendency to bring more people to bear on problems, under the impression that we’ll achieve our goals faster. However, that often doesn’t happen. Instead focusing a small, agile team on thoughtful, high-impact client goals seems to be a winning strategy.

BTW: there are numerous other companies that are quite small, but that do incredible things. One historical example is the makers of . Another is who focuses on application development.

Final Story – ChannelAdvisor

Here is one final story just to finish whetting your appetite around my article themes.

This comes from my own personal experience. During 2007 – 2009 I worked as an agile coach and leader at a company called here in Raleigh, North Carolina. As with iContact, ChannelAdvisor was an agile shop (Scrum) and they built a SaaS application suite for eCommerce customers.

We had a large Scrum team that was focused on developing web search application extensions for our platform. The company was growing and we were of the habit to grow our Scrum teams rather large before we would split them into two smaller teams. Our search team was approximately 12 in size.

A business priority change happened that caused us to split the search team in two – essentially making two Scrum teams of six members each. One continued to develop the search application and the other was redirected to another component area.

What’s interesting about the story is that the search teams’ velocity didn’t change after we split them. They were averaging 25 points per sprint before the split and 24 points per sprint after the split.

I know what you’re thinking…that’s impossible. Well, no, this really happened. So what was going on here?

Simply put, the smaller team was more efficient in delivering software. There were fewer communications channels, less hand-offs, more collaboration, and a better focus on their goals. To the point that they were

The Lesson: Try to solve your problems with as small a team as possible. Let them form and mature and achieve a steady velocity. Then “feed them” a prioritized backlog. You may just be surprised at how much they can get done IF you get out of their way.

Wrapping Up

I think that all of the scaling hoopla is just that. I don’t believe we have a distributed team problem or a scaling problem in today’s small or large-scale agile contexts. And huge applications don’t need to be built by 10-50 Scrum teams.

We have an un-scaling problem.  We have a boiling the ocean problem. We have a trying to throw too many people at it problem. We have a love of size and scope problem.

We’re looking at problems and creating the most complex solutions we can come up with. We are enamored with:

• Distributed teams and / or large groups of teams
• Way too complex architectures and designs
• Solving problems with project management thinking
• Management” solving problems with “old thinking”
• Building bloated software with features nobody uses
• Not truly understanding our clients
• Allowing business-facing folks to “ask for everything”
• Scattershot vision hoping that we eventually hit the target

I can’t tell you how often I hear someone explain why his or her systems are complex. They reference the complexity as a badge of honor and a must have.

I would argue that there is no need for 100’s of developers to build systems. Small teams can do great things. That is if we allow them to do it.

That was the essence of agility in the beginning and it still is. I hope this article has inspired you to reduce your teams, break up your products, and take a new look at how you build your software and what you build.

Remember – a handful of agile teams can do great things. And a handful of product visionaries can guide them towards just enough, lean, and wonderful software.

Stay agile my friends,

Bob.