Failure Cultures Reward failure.

For over twenty years I have been reciting the mantra:

“In agile, we fail fast to win early. Traditional teams are afraid to fail!”

For many years I have been observing agile teams and non agile teams, and their attitude towards failure. Once I started to observe them using the lens of “risk averse” and “risk managed” culture I realised that the agile mantra about failure was wrong.

In agile teams, practitioners do not fail fast to win early, or fail fast to learn. In agile teams, they act with self discipline as a single team to deliver value in small increments. At regular increments, the team and/or team of teams come together in a retrospective to identify what is going well and what should be improved. Agile teams do not focus on failure, they focus on value delivery and continual improvement. When failure occurs, agile teams acknowledge the failure so that they can learn from it and improve.

It is not the goal or focus of an agile team to fail or learn, it is the focus of an agile team to deliver value.

In addition, traditional team are NOT afraid to fail!

Teams in “Failure Cultures” know that their managers in the failureship are even more scared of failure than they are. As a result, their managers will never acknowledge failure. The result of this is that the failureship will REWARD failure to prevent anyone knowing that a failure has occurred. The bigger the failure, the bigger the reward. This inability to acknowledge failure and the subsequent rewarding of failure is why I call this “Failure Culture”.

Career progression in a failure culture is based on avoiding failure rather than being successful. If your portfolio of interest contains a large strategic project, it has to be hailed as a success regardless of whether it is a failure or a success. If you have a large strategic project in your portfolio and the key individual(s) are not rewarded for their contribution, people may question why they have not been rewarded. So if you are in a failure culture, the easiest way to get promoted is to join a large strategic project in a key role. Once you are established in the role, your promotion is guaranteed regardless of whether you are a success or failure. In fact, the bigger the failure, the bigger the chance of promotion.

I worked on a project that was meant to be an Agile Flagship. As an Agile Coach I gave it my full attention. The business users and product team adopted the agile approach with gusto, even reorganizing to sit together in the same space within earshot of each other. The technology team was a different matter. The technology lead refused to engage and turned a blind eye to his lead developer’s misogynistic and bullying behaviour. Eventually the team refused to even listen to suggestions about how they could improve the way they worked. “The developers are working sixteen hours a day, seven days a week. They do not have time to work in new ways”. The senior executives were informed of the situation and responded by saying “That’s not Agile, Its not even Waterfall, Its a death march project!”. The first production delivery on the Agile Flagship project took over a year. It failed to be useful because the the business users had built an interim shadow tech solution which better met their needs. The technology leadership blamed the business users for not being engaged enough. The same executives who declared the project a “death march” promoted the technology lead who was the main cause of the failure.

Another project started with a decent plan. The introduction of a new pervasive technology would begin with a three month pilot period with teams scattered across the organisation. Even though the technology was well established in the market, the internal implementation at scale needed to be debugged. After the three month pilot, the plan was to roll out the new tool to the entire organisation. I am a huge fan of the work of Chris McDermott and Marc Burgauer with Social Practice Theory. Introducing a new tool is normally a way for getting the organisation to adopt a new practice. Building organisational muscle memory in a new practice takes time and should ideally occur before the tooling. Those engaged in the pilot were the best of the best in the new practice and easily adopted the tool. Hundreds of teams adopted the new tooling. At the end of the three month pilot not one single team had successfully migrated. Just before go live, we summarised the status as a “shit show!”. The executive explained that it was a game of chicken. “Who will blink first, the central team or the teams implementing the new tooling. No one wants to call it a failure.” The mass migration of the entire organisation went ahead over Christmas. Some highlights from the project:

• A lot of teams discovered that the migration had failed for them and were unable to work.
• The central team had not considered that thousands of developers in India do not take vacation over the Christmas period.
• The entire central coordination team went on vacation the day before the week long migration started. No one knew who to contact for help.
• The central team did not even think about creating a help desk or support team until weeks after the migration by which time teams were in chaos.
• The definition of done for the migration was cut back, and cut back, and cut back as the end date for the migration moved out quarter by quarter. As a result, cost savings were not realised as licenses needed to be extended.
• There was a lot of disruption for teams, with many millions of dollars worth of lost productivity across the organisation.

I think you know what happened next. The migration was declared a huge success by the Group CIO, and a few weeks later the Group CIO was rewarded with a promotion to the Board of the Group.

In a “Risk Managed Culture”, stage gates based upon success criteria rather than arbitrary dates would have determined progression, and retrospectives would be held on a regular basis to learn and improve. There would be proper transparency rather than a game of “Chicken”. The retrospectives would seek to ensure that similar failure would not occur in the future for the same reasons.

In a “failure culture”, the failureship do not want genuine transparency. They do not want to know that there are problems. They just want to make sure that they can contain and hide it. They promote the people who cause failure so that they do not need to acknowledge it.

Failureship doesn’t avoid failure… Failureship REWARDS failure.