Code is just the beginning. Welcome to the rest of your journey.

Don't Blame the Tools

I'd like to introduce three very imaginatively named and fictional projects:

• Project A - The people have spoken. Fed up with the inefficiencies in their company the developers have risen up and make their needs clear - they want Agile, and they want it now. The company needs developers, so the concession is made.

• Project W - Run by an in-house team who've been doing their thing for 15 years. They know what they want, they have a spec and by heck they're going to follow it because they've always done it that way. Slow and steady wins the race.

• Project a - Top of the line consultancy firm ThinkShirts has been called in to deliver this key project. To them agile is a set of ideals to strive for but rarely achieved. They are pragmatic and use only the techniques that they find useful.

Three different projects, three different teams, but at the end of six months all three projects have failed. Projects fail all the time, but in this article I'd like to explore the potential causes for failure in these three specific cases.

Why do projects fail?

One thing's for sure, ask the members of the teams themselves and they'll say it wasn't anything to do with them. It's not the management either - they've all been involved with projects that met with great success as well as other failures in which they learned hard lessons that they'll go to great lengths to point out.

"The fact that society already has a proverb to this effect should be our first clue, yet we are still so quick to blame tools for our problems. It's a really easy conclusion to arrive at."

If the intertubes are to believed of late then the problem might be AGILE. This shouldn't be confused with Agile, agile or even AgIlE. Not satisfied with the capacity of the English language to be obtuse and convey hidden meanings, we've begun to experiment with casing. It's the next best thing in human language to significant whitespace... like a best of both natural and computer language. But either way, surely agile can't be to blame here because not all of our example teams are using agile.

Everyone knows™ that waterfall is a flawed methodology. Some say that agile is the new waterfall, so it could be reasoned that both methodologies are flawed and this in turn has lead to the failure. In other words, the problem lies with the chosen tools.

A bad workman...

With regards to agile, I don't buy all this big 'a' little 'A' stuff that's popular of late. Case in point (pun intended) - it made my earlier bullets look a bit ridiculous, and almost certainly caused many readers to do a double-take. This is because it's a rather daft way of trying to make a distinction... and that in itself is a smell that suggests the underlying point is barely holding together. Agile is agile, just as Waterfall is waterfall, and a tool is a just that.

The fact that society already has a proverb to this effect should be our first clue, yet we are still so quick to blame tools for our problems - the process we follow, the charts we view and the way we analyse project data. It's a really easy conclusion to arrive at, especially as a casual observer. Get a team member alone and they are sure to have personal gripes but again, it's never our fault.

The interesting thing about a team though is what happens when you take away the people - you can't. The people are the team. You need people to wield the tools and ultimately we have another proverb for this situation: to err is human. It's not tools but PEOPLE that are the problem, and I use case here merely for emphasis.

There is one particular group of people who are much maligned in this space - the consultants. These are the people who get paid to give advice on a particular topic, despite being somewhat detached from the experiences of their customers. They are the coaches that supposedly make money from a given methodology by offering their opinions passed off as fact. For these reasons it's easy to arrive at the conclusion that the consultants are to blame for our failures, although given what we know about human nature it's inherently plausible.

But I don't buy this either. There are certainly some people out there who will do anything to get ahead, anything to promote their interests and increase their earning potential. But the vast majority of people just want to help. They have had some experiences and learned some things that might possibly benefit others. But the intent is never to have this advice taken literally, it's to give people enough confidence to start moving in a positive direction, most importantly so they can begin making their own mistakes and learning for themselves.

"The agile 'toolkit' is a great place to start, these are the rote exercises by which we learn our manoeuvres. It's only after we can operate in this basic manner that we really start learning how to deliver effectively."

Of course confusion can still occur even when people are well meaning, and not all advice is good advice. In our industry the cost of failure simply isn't that high... if a project is using an inefficient or flawed process there are unlikely to be any safety concerns arising. Contrast that with a team constructing a bridge, or a driving instructor where there are serious ramifications if instruction is given or taken lightly.

The driving force

Learning to drive is a very interesting process. Instruction is metered out gradually and carefully; time is taken to built up the learners confidence and assertiveness because these 'non-functional' skills are equally if not more important than the mechanical ones. Manoeuvres we learn through rote exercises... look over your right shoulder... watch until the kerb appears... turn the wheel 180 degrees right. We don't actually so much learn to drive, we learn to operate a vehicle in manner which is safe to both ourselves and those around us. It's not until we pass our test and get out on our own that the process of learning to drive really starts.

Our initial attempts at going solo will inevitably result in delays and imperfect results, and we'll likely end up in tricky situations that we don't yet know how to get out of. We must weather the course, make mistakes and learn from them in order to truly master the skill. If we don't do apply patience we fail and get frustrated. If we aim too high, or if we are overconfident then accidents can occur. We may even reach a point in our learning that we never get past... everyone knows someone who's a really terrible driver.

"Our initial attempts will inevitably result in delays and imperfect results, and we'll likely end up in tricky situations that we don't yet know how to get out of. We must weather the course, make mistakes and learn from them in order to truly master the skill."

Many drivers are perfectly safe, but few of us are perfect (unlike me). We bend the rules occasionally, and choose the techniques that produce the best results and help us to arrive at our destination on time. Being a perfect driver is something to aim for, but rarely if ever achieved. If you're wondering what this has to do with our three failed projects, go back and read those last few paragraphs and substitute learning to drive with learning how to deliver software.

So, what's the solution?

The solution to the problem is really what it's always been: find the combination of tools and processes that works for your team; don't just take the ones that work for someone elses team. Identify the tools and aspects of methodologies that produce results, and do this by measuring and seeing what works. It's best not to impose rules from the top down, instead let the team make these decisions together. Try to make sure you have conversations and iterate on your process as well as your product.

The agile toolkit is a great place to start, but we should see these tools for what they are - the rote exercises by which we learn our manoeuvres. Just like learning to drive, it's only after we can operate in this manner that we really start learning how to deliver effectively. It's people, not tools that were the common factor in the failure of our three fictional projects. Most of all, we shouldn't just do something a particular way because we read about someone else doing it. And if something goes wrong, perhaps we shouldn't be so quick to blame the tools.

This is nothing new but I feel somehow we've lost sight of it recently - use everything in moderation, and don't be dogmatic. In a way I think it's a damn shame that this way of working doesn't have a fancy name because that means it doesn't catch on, and doesn't get spread around and talked about in the same way that 'agile' or 'microservices' does.

But at the end of the day I'm ok with that - because if we get to the point where we need a buzzword for 'common sense' then that's a step too far, and probably the day where I finally pack it all in for a quiet life as a fishmonger.