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.
Intrigued?
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`