We were educated to use cost accounting and resource efficiency instead of flow efficiency. We don't know how to collaborate and work in teams. It is also 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 the hands offs (require 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 the waste.
- A continuous flow of small increments (instead of large batches of work).
- Maximizing the amount of work not done, that a lot of times can be confused with laziness, without keeping in mind that this is an excellent strategy to avoid complexity, reduce waste and reduce the maintenance cost.
- And related to the previous one, Maximize the outcomes and minimize the outputs.
For reaching the technical excellence, and with the focus in 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. Is 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 annalize from a cost efficiency perspective in a command and control culture that doesn't understand our profession, is near 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 to increase 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 be adaptable to changes is no longer optional...
Embrace the change, Embrace the failure, Embrace the 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: