Just today I had a long discussion with a colleague of mine about Agile Development and UX. She has the non enviable task of re-writing the ‘company manual’, a gigantic (I imagine) collection of processes to be used in every department so to make sure that best practices are applied everywhere. Stuff like compliance to ISO standards and other obscure regulations, I am told.
Luckily, it’s none of my concern as a UX practitioner. Nonetheless, I was more than happy to help her understand what it is that we do all day with our post-it scattered all over the corporate whiteboards and walls.
After sharing the UX gospel with her, I explained all about research and strategy and I dutifully showed examples of personas, user journeys, wireframes and prototypes.
Next, came the unavoidable question: “This is all very good and it makes a lot of sense, but we follow Agile development. How can we fit all that stuff in a two-week sprint basis, so that we can produce small chunks of the product to show the client for revisions? We can’t employ time in creating the big picture and the go into coding, that’s Waterfall!”.
The debate that ensued was so long and passionate that I thought it would be a shame not to share its outcome with the world (I’ll spare all the ‘and so I said, and then she said’ and so on).
My pedestrian explanation of Agile and Waterfall
If you are reading this post, you are probably aware of the ongoing discussion about Agile and UX.
Just to give you a quick recap, Agile is an approach to the development of digital products that divides the work in small segments, called sprints. At the beginning of each sprint, the team and the client decide together what piece of the functionality will be delivered, for instance something like the ‘Login to the website’ feature.
Forgive me if I overlook all the details of this process – I won’t mention user stories or team velocity – you can find a lot of valuable material on line. The bottom line is, we use Agile to deliver something quick, to keep the client engaged and to avoid to build a huge application for months in the solitude of your office, then show up at the client’s office, present the almost finished product and then discover that the client is horrified and wants to change it completely. This last, unfortunate situation (disappearing for months to code) is caused by the Waterfall approach.
Now, please, please ignore the superficial words I used to describe both Agile and Waterfall. I’m not a project or SCRUM manager, I just report what I learnt on the job and briefly summarised using everyday language.
My proposal to mix UX and Agile
What I also see everyday is that UX and Agile struggle to get along, which is a shame, because Agile is good, real good.
I love working with a team of developers where everybody keeps the others up to date during the daily stand up. I also – surprisingly – came to terms with our project management software, whose UX could be highly improved (how ironic is that?) but it helps .
The retrospective analysis of the sprint is an excellent moment where to raise issues and tackle them, right away. Everybody works better, once you get the gist of it.
The biggest obstacle, here, is the time allocated for the UX part of the project, it’s rarely enough in an Agile environment, where apparently every attention is to development.
The only solution I see is to use a hybrid between Waterfall and Agile. What I see working very well is to allocate enough time to UX practitioners to lead the strategy and design phase, so that when we are ready to go into development the whole project is well scoped out and documented. Honestly, it doesn’t need more than that. And if the word ‘documented’ sounds like pages and pages of specs and flow, well, it doesn’t have to be.
Call it Sprint 0, Initiation, Discovery, whatever you prefer. I honestly don’t care about being etymologically correct, what I do care about is having time to dissect the problem the client has and come up with a solution that makes the users and the stakeholders happy. And also developers.
Whereas Agile is all about these famed small chunks of functionality, I see that developers work better when they have the whole picture clear in front of their eyes. This is also the reason why I always want to involve developers as early as possible in the design phase.