The thing about really well-formed cunning mistakes is that they keep being made over and over again. We are all familiar with the character in the horror film who time and time again ignores the obvious warning signs and edges closer towards greater danger. Why don't they run away! I have a few personal recurring mistakes, such as always thinking that there is plenty of time left to do the Christmas shopping, and forgetting to turn the thermostat down when toasting tea cakes!
Software delivery also has its howlers that just won’t go away. When Steve McConnell published his seminal Rapid Development - Taming Wild Software Schedules, in 1996, I bet he didn't think that the 36 classic mistakes would still be prevalent more than twenty years later!
When I recently reviewed a client’s Agile delivery process I could find little to improve. It was actually pretty good. The project was well set up and had a talented team of developers who worked hard and cared about their work. So why was their backlog out of control? Why were so many key areas of functionality shelved and so little progress being made to close the functional gaps and fix the operational defects that kept appearing? It really came down to poor decisions and classic mistakes.
Over-estimating savings from new tools and methods. (Mistake no. 34)
When initiating the project, the team chose a relatively obscure language for development. It had favourable scalability characteristics and flexibility. It was claimed that it would make it easy to adapt to the technical challenges that were perceived to lie ahead. Unfortunately, due to its obscurity, skilled resources were expensive and hard to find; development was slow going; budgets were put under pressure right from the outset. Developers who were switching languages took longer to come up to speed than expected. Not only that, the most skilled resources ended up developing most of the code. These resources then became a bottleneck for defect fixes and investigations further down the line – or even worse, they left the organisation. This is a common problem that I’ve seen many times. It is easier to visualise the problems and challenges you have with something that you know. The prospect of being able to overcome these challenges with a new tool or method is very appealing. You only then learn about the issues (which can be quite unexpected) with painful experience. And believe me, I've had some painful experiences!
Abandonment of planning under pressure (Mistake no. 18)
Up until the point of go-live, the team had been reporting plans and progress diligently and regularly to a project board. The board had had to make some big calls around scope in order to preserve the go-live date. But after the big launch, all the governance controls went out of the window as the team scrambled to respond to live issues an defects. This had a big impact. The pressure to go-live meant that no planning had been done for the post-live world. This gap in controls and the resulting devolved governance meant that senior management lost visibility. Developers were able to pick and choose what they worked on. Business confidence ebbed away. After a lot of pain and anguish things have been recovered, but the lack of follow-through after go-live was a salutary lesson.
Silver bullet syndrome (Mistake no. 33)
This is an old favourite of mine that I first experienced back in the eighties when Microsoft Windows was getting under way. There seemed to be so many occasions when my colleagues were saying “there’s a new feature in the next version that will fix that”. This always seemed to me like putting off ‘til tomorrow what you could sort out today (if you could be bothered). Relying on the advertised benefits of a new product or tool is always risky. For a start, product sellers are always going to exaggerate benefit claims. But for me, the most damaging affect is the deferment of any creative thinking or problem solving on current issues. In this case study, the team put their faith in a new cloud hosting service to solve their throughput problems by enabling a faster release cycle. There were clearly benefits from the approach. However, critical resources were swept up in getting the new environments to work. Security reviews needed to be organised, tests had to be run. Stakeholders needed to be convinced. Meanwhile the live issues were still being reported, the backlog was overflowing, the problems dragged along further. My advice: think hard before putting your faith in new technology to solve existing problems. Solve your problems and use new technology to create new opportunities.
So, if anyone finds a toaster that can recognise when you put currant buns in it, let me know. Meanwhile, I have come up with an interim solution, which is to keep the thermostat at a default low setting and toast my bread twice!
If you have experienced, or are experiencing any of the above classic mistakes please let us know. Remember, a problem shared is a problem halved!