Skip to the essays
All essays

The three main trends in long agile adoption processes

I was having a discussion with fellow agile adopters yesterday and a bunch of interesting patterns emerged from the discussion: We are getting to agile/process improvement fatigue The management of software development is changing, but agile adoption processes do not have a mandate to change the management approach We don’t have a process to learn …

I was having a discussion with fellow agile adopters yesterday and a bunch of interesting patterns emerged from the discussion:

  • We are getting to agile/process improvement fatigue
  • The management of software development is changing, but agile adoption processes do not have a mandate to change the management approach
  • We don’t have a process to learn at the organizational level

Here are some ideas I brought with me from yesterday.

We are getting to agile/process improvement fatigue

This is certainly a familiar sentiment among those of us that have been involved in agile adoptions for several years. One trend/common sentiment I felt yesterday is that agile and lean are seen as just another trend that will pass. Many are trying to look for “better” approaches in meta-approaches (like Lean over agile, or Toyota-driven ideas over Lean, etc.)
This meta-approach is seen as solving the problems with the previous approach.

There’s certainly some truth to that. One cannot really improve without going deeper in the process of understanding, and that naturally leads to more abstract approaches. Something the Alistair Cockburn readers will recognize as passing from the Shu-level to the Ha-level.

I don’t see this as a problem, I see that as a natural learning process. Agile in general and Scrum in particular have been around for long enough for people to recgnize it’s shortcomings and to look for “better” ways. It’s the learning process. The problem is when people don’t really look for the theory behind the patterns they are trying to apply and just change patterns (say from Scrum to Kanban) without understanding why.

As long as we fail to recognize the theory behind what we are applying, we are doomed to make the same mistakes, over and over again.

The management of software development is changing, but agile adoption processes do not have a mandate to change the management approach

This was one trend that I raised in the discussion. Here’s my argument summarized.
Agile is the result of a fundamentally different approach to management (analytical management vs. complexity-aware management). However, the management that is driving/leading the adoption of Agile software development is versed and informed by a completely different way of thinking. They live and bread a different paradigm of management. Until that changes it is impossible to make agile adoptions sustainable.

Symptoms of this problem are quite common and likely familiar to you. Managers set targets for agile adoption, but don’t change the way they manage the organization (a requirement to meet those targets). Managers say they want agile adoption but at the same time try to micro-manage the teams, don’t respect their need for self-organization and set all kinds of policies that go against teams taking responsibility over their work. And the list goes on.

Main point: there’s a basic conflict between the analytical management mind-set and agile adoption. Until we solve that the best we can do (and it’s a lot already!) is to get our teams to be agile, but not the structure that directly affects and limits their performance.

We don’t have a process to learn at the organizational level

The point that follows from the previous is that in order to be able to get out of the analytical management paradigm we need to build a way for the organization to learn, to experiment and then adapt.

The lack of this method of learning, a meta-management method if you will, is what dooms us to be stuck in the previous paradigm. There is plenty of information around that can help managers learn and improve their work the same way we ask teams to do. But that learning is not happening in the vast majority of companies adopting agile. Until that happens agile is firmly stuck in the realm of the team developing software. It’s like buying F1 tyres for a family car and expecting it to win a rally race.

Conclusion

What encourages me is to see that fellow colleagues in the agile journey also understand these issues and are (some of them at least) directly addressing these.

I hope they succeed and share their knowledge with the rest of us…

Photo credit: Denis Collette @ flickr

Keep the conversation going

The essays work best in company. Join the community to keep the questions coming.

The #NoEstimates book and its companion volumes

Chapter 1 · Free PDF

What if better planning started with a different question?

The first chapter of #NoEstimates argues that the “deliver on time” challenge is answered by a different question. Read it, and see whether it changes how you plan the next piece of work.

Free PDF of chapter 1. No purchase, no library access. How we handle your details