Slow change in agile consultancy

Luuk Dijkhuis

We as Agilists are extremely result driven: delivering value to the customer as soon as possible is the axle around which our work and vision revolve. This can help us but also hamper us in the process of bringing Agile to a non-Agile environment. Being aware of this may already help us be more effective in bringing about changes in an effective way. The question “is this a quick-change or a slow-change organization” should be an explicit part of your analysis. Be patient!

Being hired as an Agile consultant or coach, you get to see a lot of organizations where the software development processes, or rather the whole chain between business idea and system implementation, is in serious trouble. They wouldn’t have needed a coach if they weren’t. Being experienced in this line of business, one can analyse and identify the main sources of problems quite quickly, and will come up with a concise plan to make big steps toward improvement.  Then we take the bull by the horns and want to implement the plan. RIGHT, GET TO IT DUDES, GO, GO, GO, AND MAKE iT SNAPPY!!! Agilists are roll-up-your-sleeves types by definition. Well, great, isn’t it? Get results fast, improve that process in weeks! Won’t we? Err…. Nope…

Coming in, finding the sore spots fast is great value. Moving too fast after this initial step is a HUGE pitfall for Agile Change Consultants. Why is that? There are several reasons why you shouldn’t move too fast, I’ll get to that. First  a disclaimer. When you arrive at a company that has a young, fresh, eager, willing team, that has a can-do mentality but is simply not structured, disciplined, focused or whatever enough, THEN it  can be a very good idea to do exactly what I described above. Get in, pump them up, do the right things and there you are, streamlined in weeks. Those are the “easy” ones, the exceptions to the rule.

 Usually you come into an organisation where ancient processes reign, where the culture has assimilated to having problems and to only allowing traditional solutions. Where the manoeuvering space of individuals has shrunk bit by bit, and where hierarchy, handovers, fingerpointing , ratty behaviour and lack of personal responsibility for the overall results (“not MY problem”) are present wherever you look.

 If you move too quickly there, you will leave everyone behind. Yes, I will say that again, if you move too quickly you will leave everyone behind. You will not change a damn thing, lose all the momentum and enthusiasm that you have managed to whip up and actually be counterproductive, producing only more disillusion and frustration when you have left.

The big question here is WHY? Wouldn’t one expect that once it becomes clear what to do to improve their situation, people would readily adopt the improvements?

Change is scary.

As good old Niccoló Machiavelli (“Il Principe”) astutely pointed out, all change has fierce adversaries and at best lukewarm supporters.  No matter how awful and inefficient the current process is, no matter how much frustration and superfluous work and effort is put in for minimal results, it is still THEIR PROCESS. This is what they currently do business with, it’s what they have got used to. So although it’s bad, it is at least “proven”. They will think “How do I know that this new approach will deliver our stuff AT ALL? We have lengthy cycles, but we do meet our deadlines now. Ok, the quality sucks, but the customer does accept it now. How can we forecast what will happen with all this new ideas?” Maybe they don’t even consciously think that, but they will feel it at least.

Moreover, in an environment of hierarchy and distrust there is an enormous risk to moving away from the Main Path, because if you fail within the path it is recognized as “standard failure” but if you fail taking an unconventional approach you will be seen as irresponsible because you didn’t follow procedures. Workers are not happy to take such risks just because some hotshot external Consultant comes shouting these crazy new ideas, even if they sound plausible. Or even proven someplace else.

Higher up

Then there are the higher layers. These people have been responsible for designing and implementing exactly the processes that you are burning to the ground. Not a message that will be received with big cheers., understandably, unless you ease it in. Inherent to agile is bottom up responsibility and empowerment, which is at first seen as a threat to manageability as well, so, lukewarm supporters at best, if at all.

Customers

And let’s not forget the customer end of the stick. Probably they will be the easiest to convince, because inherently they will experience the biggest problems with the quality of the existing process. For them there will have to be a lot of increased effort in that Product Owners (to use a Scrum term, it doesn’t matter which Agile method you employ) are expected to have a lot of direct involvement with the project, so it will cost them a lot of time and work. But it is not unlikely that they will go for it, if the problems of the current processes are big enough. Yet even so, if you go too fast in getting their support and enthusiasm, the slow response of the delivery organisation will annoy them and the customer satisfaction will go down even if you have slightly better results than before, because then it doesn’t go fast enough for them. Risky!

We could go on about the maintenance departments, the exposure of poor performers in self managing teams, the necessity for hugely increased discipline which is not always comfortable, etc. etc. but the picture is clear.

What to do.

Change will work best if it is experienced as something that comes forth from the people themselves. It must be their thing, or it will meet resistance.

So what you need to do is to talk to all of these stakeholders of the process (you already have while doing your analysis), and have them find out what their top two (yes only two) problems are. Then you help them find out the root cause (of course,  you may know what it is at a single glance, but you don’t necessarily TELL them just like that, you help them find out). If you help them find out it will be “their thing” and they will be much more involved. Once they’re involved they will be more susceptible to adopting a solution. You propose some small changes to improve their main problem. Of course you also have your own prioritized list based on your experience and analysis, and you will be tempted to nudge them towards your own top N issues. Don’t underestimated the force of addressing their top two however, even if you wouldn’t think their  road would be the most effective one towards implementing improvements. Take it seriously, and negotiate a bit perhaps. Then you give it some time to be implemented, not too much time because you will have selected the size of the change to be small enough not to disrupt too much of the current process, and big enough to make a measurable difference.

Don’t be smug. These people are not stupid, they have just evolved into using processes that can be improved. Try your very best, all the time, to think like them, to stand in their shoes, why does he behave like this and how can I help him realize that there is another way. See everyone with a problem as a friend with a problem.

PATIENCE and relentless energy at the same time. Sow the seeds. Water the plants. Nudge. Pet. Steer. Guide. Let the teams grow into the change. Make improvements visible. Except for the latter, this is contrary to our innate urge to get results quickly. But don’t be fooled. In this type of organizations “getting results quickly” means that you have implemented any change AT ALL in half a year, so instead of wanting to rearranging the whole process to an end to end Agile approach in eight weeks (“hey, come on we KNOW what we must do, what’s the big deal, just go and do it”) and be frustrated if everything comes to a grinding halt, rather be happy to improve productivity and quality measurably and to have whipped up the beginning of enthusiasm and acceptance for the Agile culture after, say, six months and counting. WHAT? SIX MONTHS?! Yes. Deal with it. It goes with the job.

Comments (2)

  1. Vishwa - Reply

    January 28, 2010 at 8:43 pm

    I see now that understanding people and acting accordingly matters so much !

    Great article, Thanks !

  2. vivek - Reply

    February 24, 2010 at 10:07 am

    Absolutely agree, The biggest factor is people. For any organization to adopt agile and “be agile” people need to be mature enough to appreciate the difference.

    I have seen many companies that just stand up during their meetings to call them "stand-ups" and burn midnight oil to complete the chunk of software promised to customer in 2 weeks so that they can call them "sprints", While all the time creating 100’s of documents so that they wont miss the next CMMI level X certification !!!

Add a Comment