Agile Mindset

Agile is a software development movement that aims to cut fat from the industry's trademark bulky timescales and bloated specifications. Its been devised by 'developers' or 'programmers' and as such has so far been pretty thin on procedural detail for the user experience designers. In fact, some of the specific methodologies within the Agile family make absolutely no mention of 'experience design' at all. Most advocate lines of code being written from the very beginning of a project. Almost all state that you work through a list of requirements until you have the minimum amount of functionality to release a product. However, few go into any detail about how you get to the point of having requirements in the first place.

So, this is where a project team used to working from the very start of a project (determining what it is that needs building) can go wrong. Trying to lay lines of code before you have some idea about why or for what purpose is like taking a journey to a foreign city you've never been to before, without looking at a map first. You may hit the right continent if you have some vague sense of direction, however, all roads do not lead to Rome.

But there's more to Agile than laying lines of code as soon as possible. Its a mindset which can rid the shackles of rigid 'design first' processes that pride themselves on quality but have done more than their fair share of creating the software industry's bad reputation by delivering late or not to specification or not within budget (or a combination of any and all of these). The Agile Manifesto is a set of fundamental tenets to remind Aglie practitioners to "Get On With It". And really, thats what it boils down to, regardless of which role you fulfill in the team.

In my recent experience of working on a project that was very much at 'seed' stage when we began trying to work out which of the many manifestations it could take on, I found that an Agile mindset was an effective mechanism for ensuring that rediculously tight deadlines would be met. Being Agile means that the perfectionist that lays within most experience designers has to be persuaded that it's OK to get it right the second or even third time. Taking a 'sketch approach' to design where the first versions are a best guess based on the knowledge available at that time, abates deliberation for fear of getting it wrong. Watefall processes are frought with fear of the bad specification. Once coded, a design is set in stone, not for revision. Technical folk usually get very cranky when you sheepishly sidle up to them with "You know that section here... the one that took you weeks to code, tweak and get just right... well... um... we er, need to um, change it... y'know, just a little bit..." [ducks for cover]. However, when the project team all agree up front that everything is subject to change, it loosens up that feeling of foreboding which has a side-effect of making people check thrice before committing to a specification. Naturally, changing things takes time, but when things take less time to design in the first place, you have more time to iterate until it is right.

A coding practice known as Refactoring can liberate us all from what Alan Cooper refers to as scar tissue, a phenomenon where code that has to be changed leaves a 'scar' that makes the foundations of the program unsound. It can be argued that working in an object oriented fashion should enable components of a system to be rebuilt with no impact on the remaining body of code, therefore should be the method of choice when following an Agile development process.

The Agile shift in thinking about experience design is not just about being iterative. Its fundamentally about designing in an object-oriented fashion too. Components need to be designed individually in order that they can be built individually in a staggered project timeline. Some components will be a few degrees more defined than others at any one time and this is hard to reconcile at first. Its uncomfortable thinking that you have to design a mid section before a start section etc. Some might say you can't possibly do it and expect to get it right. And there's the crux of the mindset right there. You don't expect to get it right the first time. You expect to get it right the second or third time around, when you have had time to design the start section.

Agile works, but the idea of laying lines of code from the outset of a project, does not seem like a great idea to me, for reasons stated earlier. I think this is where a production process can learn from User Centred Design's 'understand' or 'discovery' phase to flesh out business requirements, user requirements and the competitive marketplace. I would still advocate that the body of work that is done in this period, is managed using an Agile methodology like SCRUM though, as it still works to 'gee the team along' even when they're not laying lines of code. The rhythm set by being iterative, combined with an disparaging attitude to excessive documentation and ecouraging face to face dialogue, is a very effective framework to ensure maximum efficiency within the team.

It does take a significant 'opening of the mind' to allow ourselves to really work in this way, when everything we've known to date says we're going to get burned if we do. But it's inevitable that you get burned the first time you try new things. We must persevere, because unless the software and web industry embraces a total shift toward delivering on time, to spec and on budget, clients will continue to lose faith in its ability to get itself together. This will affect its monetary value in very real terms. If the tech sector's stock price collapses, as the survivors the dotcom crash know only too well, it will really, really hurt.