Over the last year or so I’ve come across quite a few people – technologists mostly – who keep asking the question – why can’t Agile be used as a methodology for both UX and development? Having spent some time considering it, I’ve put down a few thoughts below. Apologies in advance for the use of overused clichés.
So to begin, if you think about the differences between what we do as the differences between Architects and Construction teams working on buildings it might help.
Additions and renovations
Analogy: Think of this as modifying the interior of your home or building a small addition to an existing home.
In this instance you will likely need some kind of planning permission and therefore some designs drawn up for the planners to review. Once you have permission you will engage contractors to do the work. They will of course want to utilise the plans, but you can work with them side by side throughout the process. As the end customer you will have to live with the output of their work, and therefore any changes and modifications you make along the way will affect the outcome of YOUR project, affecting YOU as the user.
From a web or software development viewpoint, on small projects, where something already exists, and you understand its structure and use, adding something new or making modifications means working with known technology, design, users and a history of analytics. You may, at this point, even be working from a wish list provided by your users.
The Agile process can work very well here, where you are talking about iterative design and development and you have teams who understand the environment in which they are working. Many projects fall into this space, and I can understand why people might simply jump right into the Agile (development) process, running mini-UCD cycles either in, or slightly in advance of the development sprint.
Significant failure is low in this circumstance, and the ability to iterate or retract work should there be a problem minimises project risk. However you do run the risk of people not fully understanding, interpreting or developing things in the way you would have liked, and therefore may have issues with the quality or output of the work carried out.
Building a house
Analogy: Think of this as building a house from scratch. You start with a plot of land, planning permission and architectural blueprints.
On these projects, you are best served by putting process and structure in place. More to the point, before you engage a builder, you should understand – as much as is possible – what it is you want them to build. You likely engage an architect who you will work with throughout the process to get the best out of your budget and ideas.
The more you know about the build before it starts, the more potential you have for success – and the more possibility you have to efficiently build what you set out to build. We’ve all watched those shows on television where the owner went ‘off-piste’. What ensued was runaway costs, layouts that didn’t suit, missed opportunities and homes that, in the end, were livable but may well not have met the expectations or desires of the people who set out to build them. In essence, they began and ended with the Agile process, throwing User-centred design out the window.
From a web or software development viewpoint, on these medium sized projects, where nothing exists, you need to understand what problems you’re solving, who you’re doing the work for, why they want it, who else is doing it, and how what you’re doing will be measured to better understand success or failure.
In this instance you really need to understand the requirements of the business and the users. You need good prioritisation and clarity around the requirements. And because you are now building something new, with no pre-history, you really need an understanding that exists beyond that which Agile will give you. It is no longer enough to carve up what you perceive as the work, and then jump right into Sprints. You need to understand the shape of what you are building, what the major interactions are, and if there are technology constraints or technical architecture issues.
In short you need a set of blueprints to work from so that you don’t end up with something that no longer meets the needs of the business or the users, but satisfies a technical need to develop something. You need to do a larger portion of the product design up front, understand workflows and understand what a successful build will look like – and then engage development teams and work in an agile process.
Significant failure is high in this circumstance, and the reality is that most agile teams – even though they are supposed to be iterative – are often only given time and budget to develop new functionality, with one of the foundational aspects of agile – the ability to iterate – falling by the wayside.
Raising the skyscraper
Analogy: Think of this as building a large multi-story (say 40 floors) office building.
These projects are all about getting the planning right. From understanding the location and impact on the environment, to structural design, understanding how people flow and move about the building to how you integrate necessary function (elevators, stairs, electrical, heating and air conduits, power plants, plumbing) in a way that is people-friendly.
You simply wouldn’t jump right into construction of the building without understanding all of these things – it would be a disaster. In fact, understanding how these sorts of things are so important that companies like BAA – whom I worked with several years ago – go to the extent of setting up prototypes of bathrooms in warehouses and conduct user flow testing to understand how people use bathrooms and how to build them more efficiently for the people who use them. Even they don’t just say ‘Hey, we need a new bathroom’ hire a bunch of contractors and just start building.
You would engage with architects, planners, experts in construction, clients, and a myriad of other stakeholders, develop your plans – to a very detailed degree – which you would then use in a RFP to construction companies so that quotations would be as focused on what you are attempting to develop as is possible.
In the same way, with large web or software development projects you wouldn’t imagine kicking off with ‘just enough’ requirements to get going. There isn’t enough context at this stage to know if your starting point is appropriate, if what you are doing is even relevant, and how what you are doing interacts with the rest of what you are building.
Failure on this scale of project is catastrophic and costly.
So why do so many companies do just that?
Agile is too often being sold as the entire methodology, when in reality it is a development – note, development, not design – methodology. For that, we have a User-centred design methodology.
These things don’t work in opposition to one another. They should be complimentary. And yet, often you find people saying that UCD is too much like waterfall, and because they have bought into the idea that Agile solves all of their problems, they see Waterfall as antiquated and Agile as the new kid on the block, shiny, new, better.
The truth is, that in the latter two examples above the potential for catastrophic failure is quite high – and can be accomplished quite quickly. When a team hasn’t taken the time to understand what it is building how can they know that what they are building answers the needs of the business – or the users – for whom they are developing? And when – as is so often the case – the agile process itself is compromised and iteration isn’t allowed to occur how can you expect success?
I think of UCD and Agile as working together on a sliding scale. To the left we have the known, where UCD and Agile are in the trenches together solving problems as they go and adding incremental functionality. On the right side of the scale we have UCD and Agile working in a different configuration where Requirements and UCD provide more shape and detail before the development process begins and Agile delivers the output once everyone understands the shape and function of the application. The fact that this doesn’t often occur doesn’t mean it isn’t the right process to follow.
More open conversations need to be held between the Agile and UCD communities to ensure there is a process that works for everyone. And more recognition needs to be given that there is significant differentiation between small incremental projects and large-scale web or software development projects.
I hope the two communities continue to work together to understand the best implementation of these two methodologies.