Agile processes that aren’t really agile…
by networkThere’s nothing new about Agile development. Of course, it means all kinds of things to all kinds of people. Of late, I often bump into the idea of Agile business processes. Companies want to speed things up. They’ve heard of this agile development stuff and think that they can apply it elsewhere. Sounds good, in theory.
Sadly, this often means putting the word Agile in front of existing business processes, making people work harder and simply insisting that timescales get shorter, as if simply saying that a 2 week job should be achievable in 1 week will actually make it so. This reminds me of the frustrated - and generally incompetent - teacher whose only means of getting more from a student is to raise his or her voice. Take a different stance? No. Give an alternative explanation? No. Use a different method? No. No. No. Just repeat the same explanation a bit louder.
I was recently asked if I could work on a project that needed to be done in minus three weeks - the usual extremely ‘urgent’ that never is. You probably know the story. Gets delivered in minus three weeks and sits in some ‘in tray’ for another six weeks, perhaps doesn’t even get used.
Clearly this is a human problem, not a process one, if we can distinguish the two. It’s an emotional problem. People need to feel good about themselves. They need to feel as if they’re making a difference, making progress, getting things done. It’s all about the feeling and not the actual results. That’s how we often end up with someone whose surge of adrenalin, or some other brain chemical, sends out a big URGENT signal. Everyone gets in a frenzy to get things done. Was it the right thing to do? Was it really needed? These questions get asked later. About six weeks later on a minus three weeks project.
In my experience, the greatest delay is not the actual doing, it’s the deciding to do. Unfortunately, the so-called agile processes are almost exclusively about the doing, not the thinking. There is a critical phase called ‘Preamble’ that is worthy of all kinds of attention, but falls outside of the scope of what we think of as ‘project,’ so it gets left out. We have project management, but no preamble management. Problem is that all these preambles add up to a lot of time. Ironically, they probably add up to all the time that the Agile processes save.