Anti-agile

It’s that time of year where those prone to procrastination find themselves knee-deep in bank statements, receipts and other bits of financial flotsam and jetsam. Yes, it’s the end of January and the last chance to complete one’s tax return.

The online self-assessment service is a classic example of an information system that is complex and further complicated by the infrequency of use. Once a year just isn’t enough to gain deep familiarity with either the process or the system, and even though I personally have been doing it for nearly a decade every time still feels like being behind the wheel of a car on driving test day. I guess pressure is further exacerbated by the implications of getting it wrong.

The HMRC system is not a thing of beauty. From a fashion sense, it looks its age (my memory is that it’s been in more-or-less its current form for maybe eight years now). But as these sorts of things go, it’s not terrible, and I’ve often used it to describe a benchmark by which internal systems should be judged: if your expenses system, or timesheet system or appraisal system is less easy to use, then you’ve got a usability problem.

But systems that are used infrequently, but are complex, pose an interesting challenge for development and management, and one that I’ve not seen much thought around. How should we design and build digital services that are to be used infrequently?

Agile methods tend to base their design on the principle of continuous improvement. Release working versions, and then continually iterate to refine based on the experience and feedback of the user base. If you are running an online retailing operation, that works well: there is a constant stream of positive and negative feedback data enabling refinement at infrastructural and user experience levels.

If you are providing systems that are to be used by people frequently, it’s surprising how bad an experience can be tolerated, as people build up their own workarounds to cope with the limitations of the technology. I’m not advocating this as an approach, but it seems to have been the default strategy for many time and resource management systems I’ve experienced over the years. Heaven forbid that, say, and expenses system should be designed to be as painful as possible to reduce submitted claims…

However, for tax returns, annual appraisals, pay review processes, employee benefit selection – those once-a-year activities that are the structural plumbing of big corporations and government – it strikes me that traditional waterfall approaches to development have much to recommend themselves. In general, the timeboxed, iterative approaches of agile might help to deliver technically, but when two sides of the project management pyramid (functionality and time) are defined by a hard deadline like a year-end, are they going to do much for user experience?

Agile is so much the common currency of development these days that sometimes it feels we lose sight of how it might not always be the best approach (top to bottom) to run a project. I also wonder if we are losing the skills to run projects in anything other than agile methods…