A few months into any company's journey towards agile development I often see a point which I call the Low. This is where you've brought in a few experts, and done a few of the things they've said... but nothing seems to have improved and now people are wandering round complaining about everything all the time. It's suddenly become normal to talk about how bad project management and development standards are, even in front of the PMs and developers themselves. The air in the office is one of gloom and the idea that nothing will ever get fixed.

This is an easy point to give up. It feels like the logical thing: the agile experts have come in and all they've done is made everyone miserable and combative without improving anything. Why did we bother?

This is the Low. It's not a nice place to be, but it's also an important one. To understand why, you need to understand the cause. What's happening is people are looking at the way you work and realising that not only does it need to change, you need to start talking about how and why it needs to change. What makes it a Low is that teams in this state are yet to develop the ability to introspect in more positive ways, or the power to enact change.

Escaping the Low

So once you're in this state, how do you get out of it? Here's the bad news. You're going to have to start fixing the causes of complaint. Remember the primary habit of an effective agile team: they eliminate waste. One of the characterising factors of a Low is that people aren't complaining about salaries or the weather or the CEO buying a new Lamborghini - they're complaining about the genuine obstacles to productivity they face every day. I do sometimes hear that all agile leaders do is cause trouble, and it may seem like that's what's happening here; but the reality is different. In my experience the Low tends to happen after one or two teams have experienced a proper Scrum cycle, worked collaboratively, and delivered software they enjoyed making and are proud of. They and the people around them are starting to look at your existing structures and think, "it doesn't have to be this way". They feel prevented from working effectively, and start to complain about it.

What turns this pattern of itinerant moaning into positive engagement is action. That's the crucial thing about this phase. You have to act - this problem isn't going away otherwise, short of sacking everyone who thinks things should be even just slightly better than they are. Paying lip service, creating powerless discussion groups, anything which doesn't involve making real changes will only worsen and prolong the Low. This isn't conjecture: to give you an example, a good few years ago I worked with a management group who refused to address a prolonged Low. They were determined to follow their own vision of Enterprise-grade Agile, and eventually got to a point where the average length of employment in their department was under three months. (i.e. all the existing staff left and none of the new hires stuck it beyond their probation). The organisational change they wanted was left in tatters and even now they still haven't fully recovered from the fallout.

Action turns the sentiment of "it's bad" into, "it's bad, but people listen to what we're saying and try to improve things". When people feel they have the power to change things, they become positive about even the bad things. Problems become opportunities to make something better. At this point your agile leaders can start formalising the process into regular retrospectives, and encourage teams to measure the impact of the changes they make to ensure they're worthwhile. One of the things I do with a retrospective that's overwhelmingly negative is the, "whatcha gonna do about it?" challenge (with apologies to the Small Faces) - if my teams can't make those changes without opposition it undermines the whole activity.

The more effectively you respond to those demands for change, the faster you escape the Low; organisations who commit to overhauling the entire way they handle development see bigger and more immediate gains than those who only fiddle with small things - this is one of the reasons Enterprise variations of agile methodology fail far more often than the real thing; they lack the commitment necessary.

The good news is that transformation happens a lot faster after the Low than before it. This is obvious if you think about it; people already knew what was wrong, and now they've been given an avenue to fix it. This is, after all, one of the things we're working toward: the idea that people working within a process are able to introspect about it and improve it themselves.

Image by Mcyjerry CC-SA 3.0