Agile is counterintuitive

A good Agile culture for a technology-based company is counterintuitive for most people, as we were educated to use cost accounting and resource efficiency instead of flow efficiency. Neither do we know how to collaborate and work in teams, as well as it being very common to see Engineering as a team to control: as a service provider, instead of as part of the business.

At the organization and team level, at least, the following practices are counterintuitive:

• Increase Focus and reduce the work in progress (WIP).
• Organize people around the work minimizing hands offs (requires generalists and collaboration), instead of in functional silos (need specialists) with central coordination.
• Self-organized autonomous cross-functional product teams that require trust, power, and team responsibility, instead of a culture of Command and Control. 
• The NoEstimates movement to avoid waste.
• A continuous flow of small increments (instead of large batches of work).
• Maximizing the amount of work not done, that can often be confused with laziness, without keeping in mind that this is an excellent strategy to avoid complexity, reduce waste and reduce maintenance costs.
• And related to the previous one, Maximize the outcomes and minimize the outputs.

To reach technical excellence, and with the focus on software development, a lot of practices are initially counterintuitive. For example:

• Test Driven Development (or for some people even automatic testing).
• Pair programming. This practice is a classic one. It's very easy to measure the cost of two developers. But is very difficult to estimate the cost of a bad design, the reduction of the bus factor, the improvement in the knowledge about the code, the system, or about a technical practice. So if we try to analyze from a cost efficiency perspective in a command and control culture that doesn't understand our profession, it is nearly impossible to understand the real benefits of this practice for the product/ the team/ the business.
• Continuous integration (the practice) that encourages trunk based development or working in short-lived branches (less than one day). 
• Continuous Delivery or even Continuous Deployment that requires technical excellence, self-testing code, and proper tooling for recovery in case of failure.
• Introduce operability, security, quality in the process instead of having specific teams and phases to validate these activities.
• Optimize for fast recovery (MTTR) instead of increasing the mean time between failures (MTBF).

As we can see, in general, Agile is counterintuitive... and this is one of the reasons for the vast amount of fake agile cultures that are doing a lot of harm to a lot of companies.

In summary, agile software development is counterintuitive because it requires a culture of respect for people, collaboration and is incompatible with the classic low trust Command and Control organization. The problem is that being adaptable to changes is no longer optional...
Embrace change, Embrace failure, Embrace uncertainty...

It is not necessary to change. Survival is not mandatory. W. Edwards Deming

Resources and related posts:

• Other related posts in this blog
• Agile is not a recipe for success...
• Don't blame the Manifesto for Agile Software Development
• The two pillars of agile software development
• Deadlines and commitments... the fallacy
• Related resources:
• Why Every Company Is A Technology Company
• Developers Should Abandon Agile
• Lean and Agile Adoption with the Laloux Culture Model
• Theory X and Theory Y

Thanks for the feedback and/or for the contributions to:

• The honey Badger team
• Vanesa Tejada
• Unai Roldan 
• Francisco Moreno
• Philippa Skillman