Making Agile User Centered

To integrate UX activities into an agile software development process can be tough. Just consider this discussion between Kent Beck the creator of Extreme Programming and Alan Cooper a leading proponent of Interaction Design.

I’ll divide what Alan is talking about into two things: a set of techniques, and the larger process into which they fit. While I’m 100 percent with the techniques themselves, I’m 100 percent against the process that he described for using them. The techniques are optimized for being thoughtful in a cognitively difficult, complicated area where you’re breaking new ground, and the thinking that’s embedded in the practices is absolutely essential to doing effective software development.

The process, however, seems to be avoiding a problem that we’ve worked very hard to eliminate. The engineering practices of extreme programming are precisely there to eliminate that imbalance, to create an engineering team that can spin as fast as the interaction team. Cooperesque interaction design, I think, would be an outstanding tool to use inside the loop of development where the engineering was done according to the extreme programming practices. I can imagine the result of that would be far more powerful than setting up phases and hierarchy.

To me, the shining city on the hill is to create a process that uses XP engineering and the story writing out of interaction design. This could create something that’s really far more effective than either of those two things in isolation. (Kent Beck)

The techniques that Cooper proposes seek to define the behavior of software products “from the point of view of understanding and visualizing the behavior of complex systems, not the construction of complex systems.” He views “interaction design as part of the requirements-planning or product-planning process rather than as something that comes after the product planning is done.”

The User

Despite the fact that its tough to integrate agile and user centered design approaches it is possible because there are similarities – most notably the desire to create useful software. Take, for example, Alistair Cockburn’s comparison of agile development to a cooperative game:

Software development is a (resource-limited) cooperative game of invention and communication. The primary goal of the game is to deliver useful, working software. The secondary goal, the residue of the game, is to set up for the next game.

And as the name suggests, user centered design is about placing people, users of a piece of software, at the centre of the design process – making software that is useful to them – to do this effectively UX professionals seek to understand user goals and motivation through user research.

Or put another way user centered design helps us understand how people use our products, while agile development let us build and deliver software that is more relevant to its users. Both approaches are trying to deliver meaningful software products to people.

The problem then is not because the two approaches are trying to achieve something different but rather the way of achieving it is different; and specifically the sequencing of events and the time given to different aspect of the product development life cycle. Agile’s iterative development cycle is its key strength, but it also makes for some tight deadlines and people often question whether there is sufficient time to fully consider the users’ needs? However, as Alan Cooper suggests, the time to define the user’s needs is not during the development but before the development starts.

I’ve written previously about using an envisaging team to scout out ahead. Not to design the solution but to understand the problem space – understand what the business needs, what users need, who the users are and what the technology ecosystem looks like – and report this back in a coherent fashion to the rest of the team. This isn’t Big Design Up Front by another name. The envisaging team’s work should be limited to discovery work only. This combined with regular rounds of user testing between each iteration – the results of which are fed into the next round of development – can mean that agile software development can be highly user focused.

Photo: The User, by Pete Ashton. Used under licence.

Fall forward quickly

DilbertOne of the problems with the waterfall model is that it forces your client into think through all possibilities at the beginning of the project – and then commit to those requirements and designs or face the potential pain and cost of change control. Unsurprisingly most clients don’t like this situation. But then nor do the development teams, most of whom would rather adopt a more agile approach.

There are plenty of reasons why we end up in this situation. The process might have been foisted upon a project because its seen, by the company, as a way to maintain control over the project costs, scope and delivery time frames; even if there is evidence to the contrary. But I also think it happens because people get use to delivering projects using the waterfall model. So much so that people don’t really understand what it means to work in a more Agile fashion. They don’t really believe that results will be delivered throughout the course of the project, nor that the team should learn what works and doesn’t, and throw away the later.

Instead clients believe that they must ‘get it right’ during the requirements and design phases of the project because they fear that this represents their only chance to influence the final product. Clients therefore tend to throw all their ideas into the pot before the project team sets off on a development death march. It is difficult to get clients to trust that there really is a different, better approach.

It seems to me that to get out of this conundrum you need to demonstrate the approach, to fall forward quickly and deliver tangible outputs en route. This means breaking your project up into independent partitions each with a deliverable every six weeks or so and accept that if you make mistakes early you will get to the solution more quickly.

But how to start? It can help to find an ally and agree a bit of guerilla development to demonstrate the approach to the wider team or client. Just be careful that the entire project isn’t delivered that way. Or when gathering requirements – spend your time in situ and produce wireframes to illustrate the product so that when your done you can build an executable prototype rather than a requirements catalogue. That way you can demonstrate how you plan to proceed.

Then keep moving forward maintaining your deliver timetable. Remain flexible if you get stuck and risk not making your milestone: descope that feature, hit your milestone and put it into the next sprint.

Nature doesn’t design upfront, nor should software engineers

Creationists (‘Intelligent Design’ proponents, whatever) argue that since life is too complex to have arisen by chance, there must be a God (or designer). They argue that the alternative to design is chance and that is just too improbable – it is like climbing an improbably tall, steep mountain in a single bound.

Mountain

Or put another way, creationists only see two options: pure, blind chance on the one hand; and God on the other. Of course this premiss is disingenuous, Darwin demonstrated a third option – evolution by natural selection which supplies a strongly directional mechanism that is anything but random. Or as Richard Dawkins puts it: natural selection provides a way to navigate the gentle slopes up mount improbable, without the need to invoke the God Hypothesis.

Natural Selection provides a feedback loop to allow incremental changes that ratchet change up the slopes of mount improbable via a series of iterations. With each iteration being evaluated (by the environment) and either selected for, in which case it proceeds to the next iteration, or against in which case the change fails to be passed on the the next generation.

The approach of incremental improvement, ratcheting up the slopes of mount improbable, not only provides a mechanism or process to scale the slopes but also reduces the overall complexity of the system, by partitioning the problem into independent steps.

For example take three six-sided dice. The complexity of this system (the total number of possible states) is 63 or 216, this is 36 times more complex than a single six-sided die (which has six possible states). Now consider dividing the system into three partitions i.e. dealing with each die independently of the other two; the complexity of this system is the complexity of the first, plus the second, plus the third, or 6+6+6=18. Thus by partitioning a system into independent subsystems the overall complexity of a system is significantly reduced.

Partitioned dice

Now it strikes me that there are parallels here with software engineering. Software products are complex systems and attempting to climb a software mount improbable in a single bound seems to be foolhardy. Why attempt to design the entire system, at the start of the project, since it foists additional, unnecessary, complexity onto your project; it is safer to break your project into independent partitions.However, we need to be careful to try and ensure that each iteration (e.g. sprint) is independent of other iterations, otherwise we haven’t reduced our complexity (although this can in practice be difficult). And we should also ensure that we learn what has worked, and what hasn’t, at the end of each iteration and role these lessons into the next cycle of work.

It’s too easy to fail to genuinely review and learn from each iteration since we don’t like criticism and we are normally unwilling to throw away a month’s work (or part thereof) and instead continue to march blindly ahead. And that is blind faith, hoping that things will change on their own rather than continuing to move towards solutions that work and away from those that don’t.