The Evolution of UX

And why most of us are doing Water-Scrum-fall

Let’s be honest, integrating UX in an agile development environment isn’t easy. Agile is very development driven and it challenges traditional design practices. Andy Hunt (one of the authors of The Agile manifesto) has recently even gone as far as saying Agile has failed. Even though I tend to disagree with his conclusion, I certainly see where he’s coming from. As a UX Designer I can say that designers in general like a holistic approach, to see the “bigger picture”, which is counter-intuitive to the incremental nature of Agile. In Scrum all members of the development team are referred to as “developers” (which I’m not!), any user story or task could be picked up by any of them (ever been on a project where this is the case? I haven’t.) and where do you read up on how and when wireframes or mockups come about and what role they play in all of this?

How do we deal with the daily reality of having to align a development team with UX Design and Product Management?

Sure, you could think how hard can it be, I will just create two tracks and have designers and researchers work one sprint ahead so that they will provide the development team with input at each end of the sprint. Even though this (Water-Scrum-fall method) is a common approach, especially when first starting to incorporate UX in an existing development cycle, it misses the core aspects of what Agile is truly about and here’s why:

1. Whatever you manage to design in a sprint can be very different to what you can develop in a sprint. As a result the two tracks will eventually not match. If your designers are late or need longer than a sprint to provide the developers with input, the developers are left without work. It’s not a sustainable situation.
2. For the developers it becomes impossible to see beyond the 2 week sprint and they will develop a tunnel vision. The bigger picture will be missed, it will be harder for them to choose the right solutions and provide designers with valuable input.
3. Designers and developers don’t form a cross functional team. It’s hard to have a shared understanding across designers and developers when designers are merely “throwing things over the wall”. In this setting there’s a hand-off which results in loss of “ownership”. The designer can argue he’s produced the appropriate artifacts and the developer can say, I’ll just build it the way I understood it should work.
4. Risk increases since it takes longer before you can validate whether what you've made solves your users’ issues.
5. When developers are not involved in engaging users directly in design they lack the implicit knowledge of the users’ needs. A lack of knowledge often results in a misalignment between what would benefit the user and what developers feel is important to deliver.

Requirements misunderstood by S. Hogh 1993

While “Water-Scrum-fall” or the one-sprint-ahead method might be right for some organizations at a specific stage in their evolution, it’s more often than not merely an in between phase when coming from a more traditional way of working (Big Design Up Front) to adopting Agile. It’s in fact the manifestation of a low maturity level, just a way of an organization and its people finding a way to incorporate change in digestible chunks.

In the initial stages of adoption people often feel as if they’re lost in the woods, trying to figure out what to do next and where to go. On their journey they learn, the situation stabilizes and in time there’s going to be someone who will wonder whether things could be better. At this point the status quo is questioned and someone will recognize that those separate design/develop tracks come with a bunch of disadvantages.

Questioning the status quo will spark the next step in evolution.

The Next Step: The Lean UX Manifesto

Early customer validation
over releasing products with unknown end-user value

Collaborative design
over designing on an island

Solving user problems
over designing the next “cool” feature

Measuring KPIs
over undefined success metrics

Applying appropriate tools
over following a rigid plan

Nimble design
over heavy wireframes, comps or specs

(source: Smashingmagazine.com by Anthony Viviano)

Lean UX is user experience at its best, because at its core is the importance of learning through trial and error by having an iterative approach in place where your most important stakeholders validate the assumptions you have made: your users!

The daily reality of a scrum team is: get this thing to “done”.

This is why it’s so important for UX Designers to be part of the same scrum team. When knowledge sharing and an exchange of ideas is facilitated, the UX Designer is able to give developers insight in the mental state of the users and the problems that need be solved for them. A shared understanding will emerge across team members and as a result developers will be able to shift their focus from purely getting things to done, to actually enabling the user and solve his problems when completing a story.

I can recommend this article if you want to know more about the experiences of UX professionals when working in an Agile framework, based on interviews conducted by Aviva Rosenstein.

For UX to effectively work in the same team as developers (and testers!) we need to have some basic ground rules:

1. Everyone works on the same stories, this means that not only testers and developers do, but that there’s true collaboration in which UX provides input while the story is in development.
2. Get technical input in design activities. Developers and testers actively participate in backlog grooming sessions with UX, to see what’s technically feasible and to prepare the workload for sprints to come. This is where UX does design proposals and goes through different options with the team. No one should design on an island, but instead should take the input from developers to be able to make well-guided decisions. Positive side effect: this is excellent preparation for Sprint Planning.
3. One designer for every 3–4 developers, to ensure UX doesn't end up playing catch-up and it has enough leeway to fulfill its role optimally. Let’s offer developers clarity and proper guidance so that we don’t leave them guessing.
4. Implement a design review and add it to the Definition of Done. You’re a team, you not only have code reviews and functional tests, you need to have someone look at the design aspects. This will add to quality assurance and it prevents re-work.
5. Manage expectations in what the team can expect from UX contribution. Educate and involve your team in what UX does.

Go forth, include UX and when sprinting, work on the current sprint while collectively preparing for the next. Sounds so easy, doesn't it.

If you want to learn more about how UX Principles can help guide your development process, please read my previous article: UX is Useless.