When I first started in software development, it wasn’t so common to have a dedicated systems or business analyst (well in the smaller firms anyway). For the first 10 years or so, my job title was something like Software Analyst/Developer. I did everything including analysis, design, development, testing/debugging, and even training.

From that I learned that software analysis and design can be a difficult task. Trying to juggle the goal of the software with supporting processes, or driving changes in the processes, and any constraints can be challenging.

What often happened was that people tended to focus more on certain aspects, like achieving the goals, without considering others. This caused failures.

In Agile we have a Definition of Success which will include Working software. I like to include usage as a success measure, as it doesn’t matter how good a piece of software is, if it’s not used, then it’s a failure.

This is where I had my biggest failure in software development, and where I learnt maybe my biggest lesson.

Many years ago I was on a project as the analyst/developer, to create a piece of software for managing groups of volunteers and their events. In this project I meet with management and senior staff solely to analyze and define a solution.

The result was a design that they were pleased with and a build they were very happy with. The problem came not from the design team, but rather came when I went out to the distributed offices to train the staff.

I’ll never forget the statement they used while I was showing them the brand new piece of software that I had spent months working on. One said ‘That is not how we work!‘ Ouch!

After the project was delivered, I monitored the usage of the software for a year or so. The part of the software for managing groups was being used, but the whole part for events (the more time consuming part) was largely left untouched. Staff did not use it and management didn’t enforce it, no change request was ever made. It was just not used.

Over the years I have seen a few other projects fail because of the same problem – they don’t work that way.

From those failures I learnt this lesson…

‘Don’t take the narrative you’ve been given as gospel, always look for those exceptions.’

It is possible that the people that are telling you the story were elected or volunteered, and are not necessarily the most knowledgeable about how things work, or they might just have their own ideas.

To find the exceptions, go out of the design team, try and find ‘that person’, you know the one, that person who always disagrees with everyone else. You never know, they just might have that bit of information that could save your project.

A quote that has helped me in my journey for truth (in work as well as life) is…

‘The first argument always seems right until put to question.’

Paraphrased from Proverbs 18:17

Analysts know to keep asking questions, with the Five Why’s, and such tools. But this is slightly different. This is going out of your way to find or think of, the potential problems with what you’re being told.

Now as a developer in Agile I’m a step removed from being able to do that, but I do ask questions to hopefully draw out such truths. Questions like…

• Why?
• Why do that, when we could do this?
• What about that?
• Wouldn’t that mean this?
• Won’t they just not use it?

The majority of the time they are just dumb questions with easy answers, and that’s ok. But every now and again they aren’t so dumb, they prompt a rethink, a change, and stop a potential failure.