Ah the familiar embrace of being wrong, almost daily it visits to remind us that we aren’t half as clever as we think we are. Despite this, how often have you found yourself in an environment where a team have to pretend something was right or in some way aren’t allowed to openly acknowledge the elephant of wrongness in the room? See if any of these sound familiar:

“The Senior Architect designed that during inception so we have to go along with it”

“The Product Owner designed those screens without any user testing and we’re too scared / tired to argue”

And perhaps the worst of all, the one we inflict on ourselves.

“I choose this rubbish library for the project so now I need to defend it so I don’t look bad”

Why you are wrong

Not everything that is wrong is a mistake, sometimes there are very valid reasons for why something was done or decided the way it was so it is important to understand the different reasons behind something being wrong before you can start fixing it

New facts

Possibly the most common reason but often the hardest to admit. We work in an industry which is still slowly moving away from defining all requirements and design up front and part of that transition is becoming more comfortable with changing landscapes, both technical and business. Mindsets which have been built up over years seem to result in a reluctance to admit that the thing you thought you needed 6 months ago actually isn’t what you need and as a result any decisions you made based on those old assumptions are now potentially invalid.

Part of the problem here is the assumption (and in the worst cases, the impression given from above) that if we didn’t get the decision right the first time then we are not doing our job right. Of course the reality is if we are doing our jobs right and finding out more about the domain as we go along, it’s to be expected that we will invalidate previous decisions.

Mistakes

Plain and simple, sometimes we just get things wrong. The important thing here is to make sure we get some sort of learning from it and this needs to start with being honest with ourselves about our mistake (as opposed to trying to lay the blame elsewhere or tell ourselves it was fine and move on) and then take a look back at why we made the decision and what made us realise it was a mistake. From here we can then start to plan how we would avoid this type of mistake in the future, for example learning something more about the specific problem so we are better aware of options next time (that library we picked was terrible but what alternatives exist and why hadn’t we considered them before) or simply making sure we get someone else’s opinion on similar matters in the future.

Learning a better way

We hope that as time goes on we learn more about our areas of expertise and so should often be faced with the scenario were we have learned some new technique etc. for dealing with situations we have faced in the past. I think the important thing to consider here is balancing up the benefits of implementing the new way (be it a new way to approach web services, or gather requirements for user stories) across a team against just doing it the same way. In many cases it ends up that the transition cost is greater than the benefits provided and so it becomes one for next time.

One problem that often crops up is selling new techniques to people who are stuck in their ways. Often we will come across someone who, for example, wrote web services in the 90s and they then design everything like it is still the best way. This can turn into a very serious problem as the worse technique / method then spreads and becomes more widely accepted as still fine. To avoid being that person it is useful to consider how often people (especially those below us in whatever hierarchy we operate) propose alternatives to our ideas and, just as importantly, how often we listen to and go with their approach. If it never happens or when it does that we always end up going with our original idea then perhaps it’s time to have an honest look at how receptive we are to other’s opinions where they contradict our own.

Retrospectives

Retrospectives are super important. If you have learned nothing else from this ramble then take note of this, retrospectives are super important. Given that they naturally happen after something, and after something is usually when the next big something is happening, retrospectives can end up getting ‘delayed’ a lot. Where delayed of course means cancelled. Without them we can expect to just keep making the same mistakes because we never learn from them and address any underlying problems. This is where you should be able to discuss with your team things which have went wrong then identify why then decide what you can do to prevent the situation in the future. If it’s because new facts have emerged, is there any way you could have gotten that information earlier? If it’s because you feel you can’t contradict the opinion of a superior, is there someone the team can get involved to help? An open and honest restrospective is one of the most effective tools to make sure that as individuals and teams we are constantly learning and improving.

Make decisions, identify the wrong ones, acknowledge them, learn from them, adjust, repeat.