People mostly want to perform at their best; they want to be recognised for leading, winning and generally improving. On the flip side, few wish to be perceived as getting worse, failing, or not trying their best. As such, we often hide failure from others.
My experiences in the software industry have taught me that the word “Failure” is rarely welcomed. Many times, I have been advised to use alternate words such as “unscheduled issues”, “unquantifiable bottlenecks” and my personal favourite, “undocumented features”. Regardless of how you define failure, failure is an acceptable outcome in any project. What matters is what you do when you find it.
It takes hard work and an iterative determination to create a product that people want to use. James Dyson, the inventor of the Dual Cyclone bagless vacuum cleaner created over 1,000 versions before going to market. This may seem a lot for a product that already had a foothold in most households; however, Mr Dyson had a vision to make a better, more efficient product that consumers did not recognise they may have wanted. Although, each and every incarnation of the vacuum brought to light another issue; Dyson learnt from the issue and made incremental success with the subsequent products. A similar process should exist in software production, where we have a vision for a product, we plan how it will be built and we make incremental success out of failed builds and tests until we reach a point where the product can go to market. Developing software requires a Product focus with a mind set where failure is accepted as passage to success.
Success, like the phoenix rising from the ashes, often emerges from failure. It would therefore make sense to promote success by making it possible to review failure without repercussions. Enabling teams to openly discuss failure and subsequently plan a way forward will remove pressure and motivate the team to improve without concern for retribution.
But what if things are going well? How often do you comment on how well a project is going, and then announce that sweeping changes are to be made to make it go even better? However, when change is needed to address a failure we often deliberate at length and assess the permutations whilst looking for success, or react quickly and wait for the outcome and, if needed, react again.
So let’s think about failure another way. Failure helps carve the path to success; it is only one of many hurdles that lead to an acceptable target or goal. Charles Dickens said: “Every failure will teach a man something, if he will learn.” So it makes sense to identify failure as early as possible and learn from it, to decide on an alternate path. This is easier than it sounds, especially as you and your team may have spent many hundreds of hours assessing the permutations and identifying the final goal. It is difficult to not only accept that your efforts were not successful but to accept that an alternate idea or practice needs to be developed and hopefully, this time, be successful. Development teams that have embraced the 12 principles of my company, Agile, believe that success can only be achieved when transparency and communication are focused and that the team will be empowered to make decisions for the good of the product.
Success is never guaranteed, but failure can be obtained easily. It is important to stay focused on the good that comes out of failure. Success is hard and harder to repeat. How often I have heard experienced project managers tell me that every project they work on is successful and that this one is no different, as long as we stick to our strategy and use what we learnt from the past. "Hold on," I say! “Strategy!? Past experiences!?” What if something new comes up that no one has seen before? As we all know, technology is not static or self-contained but rather an ever-evolving science. It was the renowned 19th century Prussian Field Marshal Helmuth von Moltke the Elder that said: “No battle plan survives contact with the enemy.” Von Moltke’s battle plans would include thousands of permutations, based on his studies of the enemy, the terrain, and the weaponry available. Yet, all these plans became redundant as soon as his armies came face to face with his enemy. Why? Each soldier had an infinite number of possible actions that they could execute, with each one providing an infinite number of varying reactions. He could not plan the battle, but he was successful because he had access to real time information and made strategic decisions based on this information, GOOD or BAD.
Look at the 1776 revolutionary war between Great Britain and the American colonies. The British generals planned and fought battles as though playing a game of chess. However their enemy, fewer in number and less experienced in battle, continued to overcome the odds. Why? They knew their terrain and reacted to change on the battlefield quickly; they adapted to the environment and looked for small incremental wins that eventually won them their independence. They recognised when they were heading for failure and retreated to re-strategise.
I am not saying that software development is like warfare, although I have been through some pretty difficult battles in the past. However, what these stories do tell us is that the ability to recognise the signs of failure, and react quickly, can lead to success. The key is that in both cases, leaders had to experience failure before knowing how to overcome it. After all, experience is in fact just a collection of solutions for solving problems. In software, we pride ourselves on experience, certifications, awards and projects completed. Maybe we should be priding ourselves on failures overcome, but I doubt we will ever see awards for this.
By now you may be thinking that failure is all around us, influencing everything we do and our decisions from everyday tasks such as: driving, cooking, walking the dog, project planning and developing software. We create mega plans for multi project programs that we are confident will never change and produce success if followed to the letter. However, experience tells me that following a plan to the letter is only successful until the first issue arises; a bottleneck, a concern –a failure. The plan changes.
Change is inevitable, but what are the costs associated with change? I ask that you consider the cost of the plan. Why develop a detailed plan if change will happen? This is why, in Agile, we only plan for the short term. If a change or a failure is encountered, then we only lose a small incremental plan and can reassess the situation, adjust strategy, realign technology or scope, and continue. Publicising success in small stages will bring together team members and the product owners to see success earlier and constantly avoid large failures at the end of a project. If failure is observed, create an environment that enables and encourages it to be assessed openly and quick to address the impact, planning a way forward. Trust your teams to make decisions that affect short term outcomes, because short term success incrementally becomes long term success. Create an environment that welcomes change and encourages the addressing of failure early and promptly.
A good general cannot plan for battle, only prepare. A good software manager with vision can plan to create a Product. By bringing together teams that know how to get tasks done, a good leader will empower them to make good, successful decisions collectively.
I have lived in the world of Agile for many years now. I have seen projects succeed and fail. I have seen one of the world’s largest Agile implementation be born and grow. I have learnt that to be successful, a good leader needs to have great teams around them, and provide them with an environment in which failure is a gateway to success. Empowering good people to be successful will make you successful. Great leaders accept failure as stepping stones to great success. If you remember nothing from this article but a simple statement, then I hope it to be the following:
“We climb to heaven most often on the ruins of our cherished plans, finding our failures were successes.” Amos Bronson Alcott (1845-1875)
Ray Scott has over 25 years’ experience in the IT industry, including 15 years as a project development lead. His newest venture is GT Agile, Grid-Tools’ Agile Consultancy Practice.