Why failure cultures hate Agile.

We have been discussing failureship for many years. It has helped us understand motivation, and helped us predict the behaviour of individuals and teams in a failure culture. One coach contacted me to confirm one of our prediction. They were helping teams implement a new technology in the organisation. Even though the technology was VERY well established, the way it was implemented in the organisation was unique to the organisation. They shared an exchange with the team:

• Team: “How do we implement this new technology?”
• Coach: “We will work together closely, creating a number of safe to fail experiments to discover the best way to implement it given the constraints imposed by the organisation.”
• Team: “Not acceptable. You need to send us an e:mail detailing exactly how we implement it. We will implement it exactly as you specify. If it fails, it is your fault!”

And this is why failure cultures hate Agile…

Agile processes and practices are NOT solutions, they are the simplest thing to help you find the problem you need to solve in order to succeed.

Over many years, agile practitioners have shared their solutions to problems they have encountered. Over time, the number of potential solutions has grown and expanded. Some problems are frequently found in many contexts and the associated practices are considered core even though they are not necessarily mandatory. A classic example is the definition of done and definition of ready. High performance teams often operate without an explicit definition of done and ready, only formally recording them when a new product owner or senior developer starts working with the team and challenges the status quo. Being aware of the context on where to deploy an establish solution, or experiment with a novel solution requires a great deal of experience. This is why the pre-requisite for a coach is lots of experience and a network of coaches that they can reach out to discuss problems. This huge toolkit of contextually specific solutions within a lightweight framework often gives people the illusion that agile is a solution. In reality, the value of agile is the simple frameworks, or scaffolding, that help teams identify problems they need to solve to be successful:

• Test Driven Development is a scaffold that allows a developer to spot a problem with the solution they have implemented. It does not tell the developer how to fix the problem, only that there is one and its precise location. This is particular useful for developers changing existing software that they are unfamiliar with… like code they wrote a month ago.
• Scrum is a scaffold that forces the team to develop a solution within a regular time box. If they cannot deliver, they become aware of the problem to be solved. e.g. If they cannot deliver because testing takes too long, they need to speed up testing.
• Kanban is a scaffold that uses queues to identify bottlenecks and a mismatch of capacity. Kanban does not tell the team how to fix the bottleneck, only that it exists and where it exists.

In each case, the agile framework shows the team what the problem is, and the team has to figure a way to solve the problem according to their context. This is anathema to a failure culture where they want to be told detailed instructions on exactly how we implement it. They want to implement it exactly as specified. If it fails, it is someone else’s fault!

Scaled Agile requires organisations to solve very context specific problems. The capacity planning framework that we developed at Skype and subsequently implemented at several organisations is an example of an agile framework that shows organisations the problems that they need to solve. It adapted to the organisation and several different solutions emerged. In one case, the problem it revealed could not be solved and the organisation became stuck, having to focus on other lesser problems. Capacity planning is an agile process because it helps the organisation identify the problem but does not tell it the solution. It tells the organisation that it needs to order the backlog but does not tell it how to.

The failureship do not want a framework to reveal problems that they have to fix. Instead, they want a solution that they can blame when it fails to deliver. This is the space that SAFE and LESS occupy:

1. Safe aims to be a solution to the scaled agile problem. It does not help the organisation understand the problems it needs to solve. Instead it provides a prescriptive “there is only one safe” way to do things. Safe provides a number of roles that reassure the existing power structure that they have a place in the new world without having to change their behaviour, your project managers get to becomes Agile Release Train Managers. The good news with SAFE is that tens of thousands of consultants at the big five have sent their consultants on the five day training course. The primary goal of Safe is to allow the failureship to say that they are agile because they have implemented Safe, not because they have improved the organisation.
2. LESS is a solution that only works in certain contexts. In one of the earliest implementation of LESS, it was implemented in two locations in the same department in the same organisation. In one location, there was group of highly motivated developers who were advocates of agile practices and principles. In this location LESS was a huge success and resulted in a 50% increase in productivity. In the other location, the developers had been involved in several rounds of redundency and saw holding onto knowledge as providing job security. LESS succeeded in one but failed in the other because it is a solution that does not adapt to the context. The managers of the department eventually deployed another solution where LESS had failed to deliver the benefits it promised.

Neither SAFE or LESS are agile frameworks because they are solutions rather than a mechanism to identify problems.

The failureship love solutions because they get to blame the solution when they fail. They love LESS and Safe because success means implementing them rather than fixing the problems they need to solve. The failureship hates agile because it reveals problems they often cannot solve, or do not want to solve.