How to Fail Without Really Trying

July 28, 2009


Having been working on software projects now for more than a few years I feel as though I have explored many of the most common (and a few of the not-so-common) ways of failing on a project. The good news is that you can do it with any project. It really doesn’t matter which methodology you choose to use: waterfall, scrum, XP, Kanban – you can fail spectacularly with them all. It’s deceptively easy to do and in fact, in my experience teams do it all the time. According to the people who measure these things, like in the 2004 Standish CHAOS report, we seem to be getting better at failing projects over time. I like to think that somehow, in my own small way, I’ve helped to contribute to those statistics. The good news is that you too can contribute to our long and not-so-distinguished history of software project failures. For those who are just starting out at failing software projects I have a few tips to help you along.

First things first, you have to pick or become part of a project that you really don’t have much passion or interest in. Nothing beats raw, unadulterated apathy to guarantee the failure of a project. There are all sorts of clever ways to justify our presence on projects that we really don’t care much about:

  1. It’s a down economy and I’ll do whatever it takes to keep a job. No, really – anything.
  2. It’s too hard to do the work required to find something we’re really passionate about that pays the bills
  3. Let someone else make the decisions about what we work on. This has the added benefit of enabling us to point the finger of blame for our situation at someone else!
  4. Adopt a strategy of learned helplessness. This isn’t as easy as it sounds – it takes literally years of really hard work to completely stifle a person’s initiative and will to fight. But hang in there, I’m here to tell you it can be done. Persistence matters.
  5. Join a team of people you really don’t particularly like or admire. If you have trouble with this, try taking on a superior attitude. That way they won’t like you even if you don’t find them particularly offensive.

If you are unfortunate enough to come across a project that perhaps your team does have some interest in, don’t despair – there are some things you can do to fix it so that nobody will want to be a part of the project in short order. First, you need to cultivate a very selfish attitude. Try the following:

  1. Just go through the motions. Show up at the daily team meeting and avoid sharing anything of any use to others on the team. Make it all about you. Just like show and tell in first grade. As far as I can tell, this seems to be the natural state of affairs for most standup meetings, so it should be easy to manage.
  2. Avoid the elephant in the room. Elephant dodging is truly an art form. I’ve witnessed teams go through contortions similar to dancing the “Limbo dance” in order to avoid tangling with the team pachyderm.
  3. When in meetings, be sure that you attend without making any significant contribution or preparation. I find sitting quietly with my arms crossed and occasionally nodding off during a meeting tends to discourage people from inviting me to more meetings – and that’s generally a good thing – for me.
  4. If someone solicits your input, give it grudgingly if at all. If people have a hard time getting your contribution, they’ll see it as a rare commodity and value it more highly.
  5. Whatever you do, don’t make the classic mistake of getting frustrated and asking more of others – otherwise they’ll start to do it too, and then eventually they might do it to you!
  6. Be very quiet. Don’t speak up unless asked, and when that happens, be sure to answer using monosyllables. “No” is always a good start. Even better – just shake your head.
  7. Don’t *ever* rock the boat.

Oh, one more thing: I know people are going to need help with some of this, so I want to offer my services as a consultant. If you really want to fail the easy way, give me a call – my services are available for a very high price. In fact the steep price alone may be enough to guarantee project failure. Of course as far as I can tell the competition is pretty fierce these days. There are a lot of people out there who will cheerfully escort you down the well trodden path to failure while taking your money and spouting meaningless managerial advice.

Continuous Improvement & Risk

July 1, 2009

I witnessed an interesting pattern today while running Boris Gloger’s “The Ball Game” exercise with a team. The basic idea is to iterate a team activity, stopping to make improvements each iteration. The idea is to practice and measure the impact of continuous improvement on team performance of a task. In general, the team did as you might expect: the first iteration things were pretty rough and their performance wasn’t very good. In subsequent iterations, their performance continued to steadily improve until they were nearly perfect at peforming the task.

Here is what I think I saw happening: with each iteration the group became more stable. They eliminated variation until they reached a plateau in their performance. They found stability, but they also reached a plateau where they were not making significant additional gains with each iteration. It felt very much like they were playing it safe. They didn’t want to do anyting to risk their “score” each iteration of the game.

Now I knew something that they didn’t – as facilitator I knew about other rather creative ways of configuring the group that would have given them a quantum leap in performance. There was an opportunity to take a chance and rethink the problem and make some stunning gains in performance – but at a very real risk to their short term performance. What I saw was a group that was tweaking the small stuff and missing the opportunity to change the big things that would make dramatic differences performance. It felt like there were competing pressures that were impeding the teams ability to see opportunities for performance improvements. Now of course this was just an exercise, so there really was no risk if they didn’t perform well – so any pressure they were putting on themselves was basically self imposed. And that may have been enough to blind them from seeing the opportunity for greater change.

How often do we do this on our own teams? We make improvements that fine tune the status-quo until it feels reasonably stable – and then we stop. I know it happens to me. Add a little pressure from management, and I very quickly can’t discern the forest from the trees any longer. There may be opportunities for change that offer dramatic improvements, but I will very likely not even consider them if it means potentially risking my team’s established performance.

I think this is all the more reason to focus on making the team feel “safe”. As managers we sometimes need to protect our teams external pressures so that they can keep relaxed and flexible – open minded enough to see all the possible alternatives.

Or I could be nuts. You decide.