On Agile teams we often talk about the truck factor:
"The number of people on your team who have to be hit with a truck before the project is in serious trouble".
While being hit by a truck isn't a very pleasant metaphor, you could easily substitute that occurrence by people leaving their jobs, going on vacation or falling sick. The smaller your truck factor, the more risk your project is at. The larger your truck factor, the better you're managing your risk. So if all that needs to happen for your project to fail is for you to leave the company and go, then I argue your project is already at a really high risk and there's something you need to do about it. I've often heard my colleague and ThoughtWorks consultant, Angela Ferguson talk about the importance for consultants to plan their obsolescence. It's an interesting thought - because if you're the 'hero' on your project, you perhaps want to retain that status. Unfortunately, being a hero isn't the best thing for your clients! So in today's post, I want to talk about three simple strategies that can help you plan your obsolescence in your team.
On typical, leader driven, command and control projects, there's only one person who has a vision for how the final product takes shape. They understand the strategy, the release plan and even plan the little bits of work that each member of the team performs. As it turns out, when these people leave, the project is in absolute shambles. Agile teams mitigate this risk by applying the practice of Collective Ownership. The idea is for all members of the team to contribute ideas to every segment of the project. This defies traditional wisdom where a single architect is responsible for unifying the vision for your project. Agile however, is based around real-life experiences with human behaviour, and the one thing we know about people is that they make mistakes! Architects/ Chief Designers/ Project Managers all make mistakes - and they're not wrong to do so. Unless you're dealing with a trivial piece of transactional work, it's impossible for one person to know everything about everything. By ensuring that everyone explicitly understands and contributes to the project's design and planning, you encourage diverse perspectives, and reduce the risk of letting one person's mistakes fail the project.
So the next time you're planning out some fancy solution-ing workshop, include the rest of your team members in it. Try an Agile Card Wall to track and manage your project's progress as against a plan on Microsoft Project, which only you can see. Yes, you'll need an electronic version of your plan and you may have distributed teams as well -- in that case use a collaborative project management tool like Mingle. Remember, you need to move from a point where it's your project plan, to a point where it's the team's shared vision.
The other thing you'll see on Agile teams is the act of Pairing. The idea is to have two heads solve a problem instead of just one, thereby achieving some interesting benefits. Firstly the quality of the work goes up, because while one person is creating the output, another person is checking it. The increased quality always leads to big savings on the project as time goes on.
"Laurie Williams of the University of Utah in Salt Lake City has shown that paired programmers are only 15% slower than two independent individual programmers, but produce 15% fewer bugs. (N.B.: The original study showed that 'error-free' code went from 70% to 85%; it may be more intuitive to call this a 50% decrease of errors, from 30% to 15%.) Since testing and debugging are often many times more costly than initial programming, this is an impressive result." - The Economist
The other, more intangible benefit of pairing is that of knowledge sharing. Constant rotation of pairs ensures that every understands every part of the project almost equally well. This again helps ensure a higher truck factor on the team. So think about this from the perspective of L&D and elearning projects - how about having instructional designers pair with builders and project managers. How about having builders pair with testers and how about having SME's pair with all the different roles? You can build a truly cross-functional team that can deal with the risk of losing a random person.
Last year I read a really interesting article on the Harvard Business Review blog about why the wrong people get laid off at their jobs. From the blog, "Legend has it that Gordius, king of Gordium, tied a knot so intricate that no one could untangle it. There were no visible ends. It lasted for centuries." The article discovered that the people that often got laid off were the people whose work the company understood quite well. It often didn't matter that they were superb workers - the fact was that people understood the risk of doing without them. On the other hand, people who were Gordian Knots - who performed well, but whose work no one understood were the ones that seemed to keep their jobs. While this strategy may seem to help you as an individual, it's more likely to backfire. Firstly, if no one understands your work and you're not as good as you think, you're likely to get fired anyway. More importantly, the mystery around what you do may protect your status but hurts your client, as a consequence hurts your employers and then hurts you. The examples of the AIG and Lehmann collapse, finally triggering the downturn there for us to see.
So if you really care about your clients and your employers, spend some time each day, demystifying what you do. Refine your job description, create standard work that'll help you teach others what you do, coach others to perform your tasks, write a wiki page for each of your individual capabilities. Create a toolkit for a potential replacement. Think as if you were going to roll off the project tomorrow!
While I've put my friend on the spot when writing this article, I realise that despite all the great wisdom out there, I haven't been great at planning my own obsolescence. Which is why you'll see this post when I'm on vacation - I want to see how my pet project performs in my absence. I've done what I can to narrate my work and hopefully the team is fully empowered to make my decisions when I'm not around. Over the next few months, I want to ensure that I detail each piece of work that I do for my employers. If anything, that'll give me the opportunity to try different roles in the organisation - if the opportunity comes by.
What do you think about the idea of planning obsolescence? I can understand the choice of words can be a tad depressing - though I'm keen to know from you if my argument made sense to you. Do let me know what you think - I'll look forward to your comments on this post.