In the quest to get agile and UX to get along better, and following successful retreats in the US, last weekend Johanna Kollmann brought together a bunch of agile and UX folk for an Agile UX retreat in London sponsored by. Giving up a weekend was hard, but was worth it, meeting a great bunch of people and sharing thoughts and experiences from the agile and UX camps. So what did I learn.
Rethink what we do
Coming out of the retreat it is clear that the way we do UX today needs a fundamental rethink. As UX professionals we have fought long and hard to gain credibility and traction in organisations for what we do, but we need to be ready to evolve and embrace the changing world around us. A world where IT no longer needs to have detailed specifications signed off before development start. We no longer have the need (or the luxury) to do the up-front research that we are used to doing. We no longer need to sign-off detailed wireframes before handing them over the fence to the developers to implement. Software today really is soft. It is more about creativity than engineering (see below). The serialisation of activities is inefficient and wasteful. It is time to ask how do we focus upon doing what is needed and when, working in parallel and infecting the whole system with user-centric thinking rather than siloing it into the upfront design. This after all is what systems ergonomics is about; a forerunner to UCD that we know today, thinking about the macro (a broad system view of design, examining organizational environments, culture, history, and work goals) as well as the micro (fitting the task to the human).
But I am digressing from what I wanted to blog about, the Agile UX retreat. Some key takeaways for me included Anders Ramsey’s analogies to the restaurant and the theatre.
Thinking analogies
Think of a restaurant. We have the kitchen, the back room world that is focussed upon delivering consistency of servings. Everything in the kitchen is utilitarian, serving the purpose to meet this goal. At the front of the restaurant we have the dining room where the dishes (of consistent(ly good) quality) made in the kitchen are served. The dining room is all about the ambiance. Quality here is far more subjective, but a successful restauranteur will be as passionate about the dining room as she is about the food that is cooked in the kitchen. This is the way that software is all too often built, with the kitchen and dining room being separate entities, however the way they are organised, paid for and owned, there’s little communication between the two. To quote another Ramsey, Gordon, it is a Kitchen Nightmare.
Anders’ second analogy to consider was the Theatre. An overly simplistic representation is that the director starts with a script. From the script he iterates the production. The producer’s role is to provide the director with what he needs to make the production successful. Just be ready for the premiere which is on a fixed date. In the lead up to the premiere the director assembles the cast, the crew and they rehearse. They’ve got a strawman plan to work from – MacBeth, but how they implement it will evolve according to the stage, actors and artistic direction the director wants to take. The producer does not care how or when they rehearse, she is only concerned with the success of the end goal. As they rehearse they increase the fidelity of their performance until they premiere (go live). but even then they are not done. They are happy to accommodate changes to the performance, and if something different happens that clearly delights the audience they will happliy incorporate that into future performances (releases). Sure, the audience is seeing a performance of Shakespere’s MacBeth, but it is a unique performance that has taken the initial plan and evolved as it has been created.
And so should we approach software development. Not as an exercise in engineering, where our raw materials are fixed and highly stable, but as a creative artform, where our iterations are rehearsals for the premier and ongoing performances.
Thinking tensions
I’m sure there are more, but some examples of tensions that emerge when we try to work together:
AUX promotes rapid open communication and sharing but designers fear sharing. (They worry early designs will be seized upon before they are ready)
AUX promotes visualisation and use of walls but corporate policies prevent this
AUX promptes doing just enough, just in time but a legacy of deliverable expectations gets in the way (research is rarely bought by the developers who will ultimately consume it).
Thinking people
At the end of the day, success comes down to people. Agile zealots have done Agile no favours when they bang on about business value and see anything other than code as waste. Good product design needs vision, it needs research to ensure you are building the right thing for the right people. No one has the right to tell a UXer that testing ideas or building a prototype or undertaking research is waste if it is right for their context. But it doesn’t need to take the time it does today. The UX community needs to get out and spend time with the development community and understand how software is built today. UXers need to start seeing developers as partners rather than consumers of what they do. What if we aligned our teams around the products we build rather than the functional silos that the roles describe? Bringing agile and UX together is more fundamental than arguing about the process (one iteration in front, washing machine cycles etc), it is about fundamentally changing the way we build software; see it as a team activity that works collaboratively rather than a factory production line with process gates and separation of responsibility.
More on the #auxretreat twitter feed
