How agile can keep up morale on long term projects

By Gavin Davies on 7 Septmber 2012

A long-term project can be hard work…

A long-term project can be hard work. It’s really easy to lose sight of goals, and begin drifting. It feels like actually DELIVERING something is simply out of sight, over the horizon. Then, suddenly, that intangible deadline begins to rocket towards you and a frenzied “crunch time” begins. Until that turning point, the huge, great, enormous goal seems unachievable, remote, and progress feels slow. After that point, it’s frenzied activity, poor quality, bodge jobs and hacking about – not the recipe for good results OR good morale!

This is one of the reasons software people tend to work on their own projects outside of their day jobs – because these projects tend to be feel achievable, and the sense of progress is tangible. When I’ve been unhappy on projects, I’ve come home and built games – because I was in control, because I was achieving things, because I could feel that I was using my skills to make progress.

I think it’s greatly underestimated how much developer morale affects productivity. Unhappy devs will twiddle their thumbs and fiddle around with toy projects, sighing at the thought of another arduous day working on the “goal over the horizon”. Agile development has, in my experience, made devs far happier simply in terms of having achievable, tangible goals that actually relate to deliverables.

That’s why agile – or, really, any kind of iterative development – is helpful from a psychological standpoint. Short term goals (in the form of “user stories to complete this sprint”) is incredibly helpful because you have an achievable target (and if it’s not achievable, your team has failed at sprint planning). You aren’t trying to fit the universe into your headspace at once – you are instead working over a short period to reach a goal that remains in sight.

Of course, it doesn’t always work – crosscutting concerns can remain arduous and difficult and I don’t believe anything entirely responsive, such as tech support, can be run fully agile (although it can adopt some principles). It’s not a golden hammer. Furthermore, adherents to agile can get almost kool-aid swilling in their adherence to their particular interpretation of the paradigm and can offhandedly dismiss concerns about how agile may not apply to a given project as “negative” without really thinking them through. Also, sometimes agile is not given enough of a chance – I spoke to someone this week show suggested that it can take three iterations before agile really starts showing benefit.

In general, though, I’ve found agile development practises improve my morale, productivity and focus. I would never wish to be part of a non-agile project team ever again. I don’t want to have to come home and work on my own projects, just to feel like I’m not chucking my skills away.

The picture is simple:
1. Keep the goals in sight – keep them focused on delivery – and keep the devs happy!
2. ?
3. Profit!