Have you read the Agile Manifesto lately? If you’re doing Agile work then hopefully you’ve come across it. I always find it a really good touchpoint to come back to when thinking about what *is* and *isn’t* Agile – much more useful than looking at how any one particular flavour of Agile or one companies interpretation of a flavour of agile can be!
At any rate, here’s a refresher. The
We are uncovering better ways of developingsoftware by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Seems almost straightforward, doesn’t it :) Deceivingly so, of course. There’s all kinds of complexity wrapped up in that simple manifesto, some of which we touched on recently and which requires so much more exploration.
Add in the UCD (User Centred Design) aspects and the questions only multiply!
Let’s start with this really easy one – who is the ‘customer’ in Agile UCD?
I would hazard a guess that your response would depend on whether you’ve been doing more Agile or more UCD lately.
If you’ve been doing lots of Agile lately, your answer would quite likely be that the ‘customer’ is the person who is paying the bills. The company or department who has commissioned the work that you’re undertaking. And that, as such, they essentially get a seat at the table as the development goes on, to have their input as decisions are being made minute to minute, and to request changes as they see fit. With any luck, this person is actually a real decision maker within their organisation and their input won’t be completely over-ridden as soon as your work is presented to the wider client team.
If you’ve been doing lots of UCD lately, then your response will probably be quite different. You’ll probably be thinking that ‘customer’ means ‘end user’ – the people who will ultimately end up as the beneficiaries of all your hard work. The people who you’re observing in order to generate your design work and who’s needs and characteristics are influencing decisions about the product functionality.
They’re two very different types of customers, aren’t they. With very different demands and expectations and requirements of you as a designer or developer of a product.
So, what to do?
Well, frankly, in Agile UCD, you need *both* of these types of customers. A successful project takes into account both the business requirements and the user requirements and having direct input from both sources directly is incredibly valuable.
Is it really necessary and valuable to have a member of your ‘client’ (which is what we’ll call the people who pay the invoices you send for this work) as a part of your day to day project team? I don’t think so. I think that ‘clients’ should be highly involved at the beginning and end of each iteration/sprint and on call throughout this time, but I don’t think that either the project team or the client gets much out of them having a permanent seat on the development team. I’d much rather see the team being left to get the work done and the client doing whatever it is they do best – which is very rarely being part of a design or development team. (Hands up if you think I just committed some kind of Agile heresy?)
On the other hand, one of the key reasons for moving Agile to Agile UCD is to add in involvement from actual end users. Traditional flavours of Agile simply haven’t allowed for the type of observation that we do in UCD and that serves us so well as designers to be included in the Agile process. This is why we are seeking to building in scope for contextual research and usability testing activities as iterations occur – rather than just at the very beginning of the project and at the very end.
So, in fact, there are two ‘customers’ in Agile UCD – but perhaps we’re better calling them the ‘client’ and the ‘end user’. One of the challenges of working out how Agile UCD should work is to determine the best way to involve each of these parties in our cycles of work so that we get the best from them and they give us the information and insight we need to do the best work we can.
You’ve seen some of my ideas about how this might work… what are your thoughts, ideas and experiences?