As the need for software products and services increases organizations look for ways to increase their capacity. Often organizations decide to scale up by adding more people. Some question this approach and suggest alternative ways to be able to deliver more software without adding people.
Robert Martin wrote the blog post hordes of novices in which proposes to develop software with small teams of professionals:
Do we need more hordes of novices? Do you really get software built faster and better by throwing ever more barely competent bodies at it? Is the software problem really a raw manpower problem? Is coding the same as bricklaying? More bricklayers means more bricks and more coders mean more code; but is more code what we want? Or do we want less code? Less code that does more. Much less code, written much better, doing much, much more?
Robert describes how he is taking lessons to fly an airplane. After a first free lesson where the instructor handed him the yoke to fly for a moment he has been studying books, attending ground school lessons and doing homework. His instructor has to be always with him when he is near an airplane. He explains to him how to handle an airplane, watches how he does things and signs his log. Robert questions why we don’t use a similar approach for software developers and suggest that we should put more emphasis on training and mentoring them:
Is our industry doing the equivalent of offering free rides to hopeful software developers, calling them pilots, and throwing them by the thousands into airplanes just to watch them crash and burn? The evidence is pretty compelling. There's a lot of crashing and burning out there. Is that because nobody is signing the log? Is that because we haven't really been training them to be pilots.
In the blog post unscaling agile Pawel Brodzinski states that we rarely question a scaling up strategy:
(…) it seems to be some sort of unquestionable paradigm and when you decide to go against that everyone looks at you as you were an alien. I sometimes feel like rolling out a huge program to introduce Agile or Lean in the whole organization was the only thing there was for big companies.
He suggest some approaches that we can use to unscale agile and work with small teams:
One is skunk works. The basic idea is to create a group within a company that operates pretty independently on the rest of the organization. This creates an opportunity to try out a lot of stuff that would be hard to implement in a broader context. At the same it creates an environment of much smaller scale.
Applying Lean Startup within a big organization goes along the same lines. On the top of a product development strategy we create a context of work that is autonomous and that operates in small scale.
Quite a different approach is when an organization decides to find a partner to outsource some of their work to. With such a situation one thing that is easily done is scaling the context down. A difficult part is to find a partner that would live be the right values and employ the right practices. But then again, it may be used as a viable unscaling strategy too.
Janet Choi wrote a blog post about the science behind why small teams work more productively. She explains that adding people to a team has some drawbacks:
More people means more of everything — more good to great, and more bad and ugly — in rallying a group of human beings to get something done. Even if more people provide a greater pool of resources, they also require greater amounts of coordination and management, to the point where size becomes an impediment.
She also mentions relational loss as a reason why individuals’ efficiency decreases in larger teams:
Relational loss is when you feel as if you are receiving less and less support as teams get larger. This includes emotional support, assistance in performing work and overcoming setbacks, and informational support to help solve problems. Think about your worst workdays — and how much harder it is without a shoulder to lean on or someone to help you out of a jam.
Janet provides ways to deal with size related problems which can help bigger teams to operate as small teams. Some of her ideas are:
Make teams feel smaller: Get chummy with your coworkers and get to know each other better. That holiday party or happy hour may seem like some silly work event, but outings and work trips allow you to build a rapport and have some fun.
Become radically transparent: Transparency helps prevent behavior such as social loafing and free-riding, which rely on the fact that there’s somewhere easy to hide, and power plays, which rely on hoarding knowledge like an information miser.
Give frequent feedback to each other: Don’t isolate feedback to some twice-a-year supervisory formality. Get the conversation flowing among everyone in your group to help strengthen the connections between individual effort and performance, which get swallowed up in the crowd through motivational loss.
In the blog post scaling down agile: the perfect agile setup Erwin van der Koogh describes his “ideal team situation” and provides suggestion on how you can work with small teams:
Give people a problem, not a task (…) you will instantly unleash their creativity in solving the problem. This autonomy to solve a problem also happens to be the best way to motivate people and get them engaged.
Make sure all required talents are on the team (…) People who can really understand the problem, communicate with users and stakeholders, interpret data, and design a customer experience are just the tip of the iceberg.
Give the team the resources they need
Let the team experiment (…) A low-risk option to do that is by talking to stakeholders, users and customers.
2 week iterations are a crutch (…) All the tools are out there, most even free, to allow you to release daily, or even faster.