This blog has moved. Go to SoftwareDevelopmentToday.com for the latest posts.

Wednesday, August 18, 2010

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 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

Labels: , , , , , ,

at 19:14 | 2 comments links to this post
RSS link

Bookmark and Share

Wednesday, August 11, 2010

Stop fighting reality, take the red pill! A tale about managers


Today I'm on a mood for a rant. Be warned! :)

I constantly get gob-smacked (to borrow a term from a friend) about the lack of simple understanding of reality.

Let me explain. One particularly common symptom in management is that they tend to "believe" (that's the word) that they can affect what happens in a large/complex software development team. They believe that if they ask for more, pressure the teams that the teams will actually do what they ask them. That's almost never the case, and when it is you don't want to live with the result of that (quality problems, missed cases, etc.).

The more they push the teams to work on more things, the less they get. I call this the "reality is a bitch" problem. No matter what you think will happen you will always be surprised and there's nothing you can do about it... until you realize that you are not managing teams, you are managing the system in which they work!

Here's an example. A set of teams go away to plan the next iteration, they come back with their plans. Plans they believe in (i.e. a sprint backlog that is prioritized and estimated). During the Sprint all kinds of surprises happen (reality...) and then they deliver anywhere between 0% and usually 80-90% of what they had planned (it's less often that they deliver everything they planned and that's ok because the Sprint backlog was prioritized anyway).

After this manager scream bloody murder and pushes the teams to be more accurate! To plan more. Guess what happens? Yes, they do indeed plan more, (and in some cases, rare as they may be) plan better, but ultimately deliver between 0% and 80-90% of what they planned.

And here's where the manager's face hits the proverbial wall. The typical manager will try to find someone to blame (likely not himself) and increase the pressure by, perhaps, shouting at some innocent bystander like the project manager or the architect and demand more accuracy in the planning. You know the drill.

The problem with this picture is that the manager does not recognize that a group of teams will always deliver a certain % of their planned work (the larger the group the more reliably so). They may oscillate between, say 0% and 50% most of the time but their accuracy is realiable. What that means is that, any person aware of systems thinking will identify that there is a system at work that prevents the teams from being more accurate. And here is the lead for the informed manager: if you find such a situation don't waste your time shouting at people around you, instead go and study the system. Ask the question: "why can't they deliver on their plans?" and then ask why again (and again, and again). Investigate the deep causes for the planning failure. It is only then that you will be able to do something about it!

Embrace reality, understand reality and then change reality! Fighting reality is a waste of your time and just annoys everybody around you.

Photo credit: clawzctr @ flickr

Labels: , , ,

at 22:34 | 1 comments links to this post
RSS link

Bookmark and Share

 
(c) All rights reserved