The Perfect Size For An Agile Team – 1 Person – It’s Crazy!

Whenever several people get together to form a team, issues always arise, that’s a fact. Developers are just not a very homogenous bunch (or is that humans), everyone has an opinion, everyone thinks their way of achieving the goal (whatever it happens to be) is best, it is a recipe for confrontation. Of course we all learn to work together eventually, teams gel or at the very least learn to function, it takes a while but we live with it, after all it is just the forming, norming, storming before we get to the chunky goodness that is performing. However, just because there is no obvious dysfunction doesn’t mean the team is a well oiled machine. We find a common framework, but our opinions and values are still the same and potentially different from those of our team members; and so the tension simmers.

As agilists we know the importance of getting along with everyone, of putting people first and being pragmatic – does that mean we’re immune? Have you ever worked on an agile team, it’s all hat tipping and tea parties, isn’t it?

“After you George.”
“No, no I couldn’t possibly, after you Bill.”

Sound familiar? I didn’t think so. If anything we argue and debate even more than non-agile teams, we’re pragmatic, we know it’s not personal so why not get everything out in the open for a better outcome. Our ‘problem’, is that we take too much interest in the project we work on, we invest ourselves in our work and so feel even more strongly about making it the best it can be, according to our values, knowledge and experience (sort of like the Army but we try to tone down the killing). At least this is better than not taking any interest in the work you’re doing, but no matter how good the final outcome all this back-and-forth does waste time and energy. It is a necessary waste, the final product is improved as a result, but what if we could make this waste unnecessary.


Then walk with me.

Lets suppose we could create a team with a full-on agile mindset minus the inevitable tension, conflict and argument that cuts into our precious productivity. It’s possible, we just need to make sure there is noone to argue with, if our team only has one person, we’re golden!

“Hahaha Skorks, you’re such a kidder! Everyone knows you can’t have a team …”

Why not though (I really gotta work on the whole interrupting thing, when you start doing it to yourself, while writing, you know it’s an issue), we’ve all read those studies that say the best programmers are 10 times more productive than the average ones and we all know a guy who worked with a guy who was an absolute gun. I mean, I personally have never worked with anyone who was 10 times more productive than me. Hang on that must mean … oh my god … can I truly not be aware of the extent of my awesomeness.

“Hahaha Skorks, you really are a kidder!”

Seriously though, I sure as hell am not 10 times more productive than the people I work with, which means those super-developers are either ultra rare or mythical. When I brought this point up with @mat_kelcey and @markmansour they assured me the super-devs exist since they’ve worked with some previously, so I will take their word for it and keep rolling. So let us say we obtain this ultra rare (take it back waiter, I prefer my stake well-done) dev, he is ten times more productive than your average bear and has a suitably agile mindset. Lets make him our team, we have our 5-7 obligatory developers with 3-5 spare. Just think of the awesomeness, the need for stand-up and retro is gone the guy will just adjust as he goes along. No need to justify his decisions to anyone, just start coding at line 10 and keep going until evening. All refactorings will be consistent, test coverage – perfect, no mish-mash ideas as far as code style, how and when to stub/mock etc. Pairing will be an issue for obvious reasons, but we’re agile, we adapt. The amount and quality of documentation, up-front design, estimation will be completely dependant on the conscientiousness of this person, but he’s got the can-do mindset and attitude, all these artefacts will be of just the right size with just enough information – sweet! Just think, this one person is doing the job of 5-7 people with less overhead and higher quality overall, if you’re any kind of manager you should be seeing big dollar signs in front of your eyes at this point.

Before we initiate the breeding program for our race of super-developers who will take the human race on a journey into a software nirvana, lets consider the risks. There are risks, the obvious and the not-so-obvious. First the obvious. No matter how good our guy is, he is still a single point of failure and a knowledge silo and a lack of succession planning – well not personally, but you know what I mean. What if this guy gets hit by a bus, or gets sick or quits or decides to go to Russia for 6 months cause he’s not getting any younger and there is more to life than code or so I am told? It will be a minor disaster, not a good situation which can easily be avoided if only he had some team members to start with … I feel like I am back at the beginning of this post.

“Damn you – space-time continuum!”

What about the not-so-obvious? You see, I am a bit of a student of human nature…

“I’ll have the 1937 Pinot-Noir my good man, it’s a fine vintage with a particularly pungent bouquet, har, har, har”

No seriously, I am not trying to be pretentious. The thing I’ve observed about developers/people is that we need others to push us to be better than we are by ourselves, this is true in absolutely everything. This means that no matter how agile a mindset we have individually, we will be taking shortcuts before we know it, unless there are others there to keep us honest. How many times have you taken shortcuts on personal projects, no tests, no source control, no need to refactor that class – only I will ever see it. We tell ourselves it is because we’re only working on personal stuff, it doesn’t matter, plus we don’t really have the time anyway, but those are all excuses. In reality we just can’t be bothered since there is noone there to guilt us into it, it is simply human nature. Our one-man-team super-developer will begin to fail as an agilists on day 2 if you’re lucky, if not – towards the end of day 1.

I know, a one man team is not really an option, still wouldn’t it be an interesting experiment to try? Can we prove conclusively that one person really can successfully do the work of a whole team?

Alright, what’s my point, or am I just rambling mindlessly? The point is, our whole industry is constantly stuck in a funk, once in a while something comes along to shake things up a little, but the majority of the time we’re in a deep rut. Why? Because everyone is constantly managing risk and trying to be responsible, we’re limiting ourselves with popular belief and best practice:

“Thou shalt have 5-7 developers in thy agile team,
Chaos will be sown in their passage,
So sayeth the wise Aloundo”

There is nothing wrong with managing risk and being responsible it makes things more predictable, but it also keeps you in that rut I talked about. The way to achieve the impossible is to be completely ignorant of the fact that it is impossible, but another way is to actively try to achieve the impossible while knowing full well what you’re doing. Like, for example, creating an agile software team with only one brilliant developer and seeing what they can produce :). You will likely fail again and again and again, but when you do succeed … oh baby – it will be all kinds of awesome.

Well I must say, this post has been a bit of a journey (it even freaks ME out sometimes – the way my mind works), which is not a bad thing – probably, but I do hope you enjoyed it. If not here is a tip for the future. If you ever find yourself sitting on top a rampaging buffalo, don’t try to fight it or steer or jump off – you’ll only hurt yourself. My advice is to get comfortable and enjoy the beautiful scenery, the place you end up may not be better than where you started but you’re bound to learn something along the way, such as how to ride a rampaging buffalo. Bring on your thoughts, ideas, rebuttals, comments. Peace.

Image by dedde`

  • Greg Sieranski

    I know a guy who knows a guy who knew a guy that could do the work of 50 men! Very thought provoking article. I really believe the one man agile team would work if only there was a way to prevent the whole bus or leaving the country thing.

    • Without doubt, that one is by far the biggest sticking point and most business are not willing to bear the risk (which is fair enough).

  • Korny

    So, this one-person team – does it include a business representative? :)
    Agile is all about communication – and it’s awfully hard to find opportunities to communicate, when there’s only one of you. Some people may be able to stop, look at their own work (and ways of working), say “but is this really working?”, and embrace continuing change – but most people tend to do this much better when there is someone else to bounce ideas off.
    I do think a one-person team can be awesomely productive and powerful – I’ve been on such teams :) but I doubt they will be agile, and they’ll miss out on a lot of the benefits of agility.
    An agile team is greater than the sum of it’s parts, a 1 person team is exactly equal to the sum of it’s parts!

    • Yeah I do see where you’re coming from, I am always of two minds regarding the whole business representative thing. Is the business representative to be considered a fully fledged member of the team or is s/he the main stakeholder instead, there are points to be made either way and it is different from project to project. For this reason I neatly avoid that issue by not mentioning it :). And you’re quite correct people tend to need other people to truly be agile which is one of the points I make in the post (in my own roundabout way :)).

  • Korny

    Oh, and with regard to being “10 times more productive than the average” – I think you’ve never been exposed to average developers. We have some mediocre folks, but there is a vast rump of terrible developers that bring the average way, way down. And even the mediocre folks tend to get pulled up to an acceptable standard by pairing.
    The average developer gets things wrong, all the time. They don’t write decent (or any!) tests. They misunderstand requirements. They write overly-complex code, and then spend days trying to diagnose what is going wrong with the wrong tools, or just by trial-and-error. It’s not hard to be 10 times as productive as someone like that.

    • I have met the occasional developer who was quite bad, but I have tended to think of those as the exception rather than the rule (an outlier if you like). But you do make a very valid point by bringing pairing into the equation, it is hard to talk about individual productivity in a pairing environment.

  • Aaron

    I have to agree with Korny in some parts.

    I’ve worked on a single developer team and had most of the benefits you mentioned, however it was very hard to get all the goodness of agile into the team. It was me (dev) and business rep and a tester. Things like velocity and retros were not rewarding enough so we canned them. It might sound drastic in the agile terms, but for such a small team it was more overhead than anything.

    And of course in the end I had to do the mammoth handover to an unlucky developer, a guy who hadn’t seen any of the code before and wouldn’t be able to ask me any questions because I wasn’t around anymore. Had we multiplied the number of devs by 2 for a while it would have worked out much better in the long run for the product owners.

    A drawback of a single developer I guess, that developer isn’t around for the life of the software anyway…