Putting Agile UX into practice

Thinking of taking the plunge into Agile? Experience Planner Jon Somerscales explains how Dare West made Agile UX a reality at our Bristol-based digital agency.
 

Here at Dare West, we’re always keen to adopt and adapt to new ideas. After our development team successfully embraced an Agile approach, we decided to roll it out agency-wide. In terms of user experience planning, this meant fusing Lean UX methods with our Agile software delivery – so now we can build better products, reduce project risk, and deliver live solutions faster.

We’ve already learned a lot, and are still discovering new ways to make Agile work for us. Hopefully, our story will give you some hints and ideas you can use on your own Agile journey.

We often work with enterprise clients that are unable to work in a truly Agile way for whatever reason, even if they wanted to. Lean UX is all about developing your product or service to fit your users and business model. So as an agency, we have to make sure the service we provide adapts to fit the needs of our clients, but at the same time we need to ensure that clients understand our process and come along on the journey with us.

Every client is different and each relationship will change over time as they become more familiar with the process. We can be Agile inside even if the client generally isn’t – we just need to give them the understanding, tools and training they need. Clients from more traditional and non-digital-first industries must be able to recognise the importance of a strong digital strategy for the current and future success of their business. If not, they won’t place enough importance on the project or invest enough time in building the right solution.

We work with the client to help them align their strategic and digital goals. On a day-to-day basis, having a single point of contact with the client (the client-side product owner) who is empowered to make decisions is vital for clear communication and building a quality product. We hope to have the necessary contact time with key stakeholders at critical points in the project because we know this usually means building the right thing first time. For larger clients, the inside agency model can offer significant benefits in communication and understanding of the problem domain.

We often get an incomplete set of upfront requirements that don’t reflect real user needs. Or sometimes the client has a large set of requirements benchmarked by the functionality of their current system, so the minimum-viable-product quickly becomes unwieldy. Frequently, clients will want to know upfront how much work their software project will take. We find the best solution currently is to break a project estimate down into smaller phases and run an ‘Experience Architecture’ phase to further drill down on requirements, build up the project backlog and create an experience strategy.

In the Experience Architecture phase, we set the initial course by identifying the key problems to solve. We consult with domain experts (usually the client themselves) and ideally real users. We identify and map out the most critical user flows. We build a prioritised backlog of requirements and lo-fi prototypes. And we coordinate with the team on how to approach the project. 

From the Experience Architecture phase, we’ll have a set of requirements captured as ‘user stories’ – this is our project backlog. Once we know the priority stories, we can run design/UX Sprints where the aim is to take each user story (or problem) and build a solution that’s ready for development. Our design/UX Sprints are two weeks long. A development Sprint follows straight after. We can also stack Sprints so they both run at the same time.

Dare_West_Agile_process


These design/UX Sprints are a chance for us to do detailed work on a high priority user flow (or set of related user stories) and arrive at a solution that’s fit for purpose and suitable for the user operating within all intended contexts – taking into account all criteria captured from the various stakeholders. Ideally, the solution prototype will go from low to high resolution, get signed-off by the client and, along with the supporting user story, be ready for test cases to be written. 

We involve core team members in the UX process as early as possible – the earlier you can get dev and design involved and collaborating, the earlier problems are identified and the more elegant the final solution because you can have more chances at iterating to get it right. The daily standup is a great way to communicate project developments on a day-to-day basis. We schedule front-end review sessions to get timely feedback, encourage communication and keep up project visibility.

In our cross-discipline team, we strive to work in a highly collaborative, user-centred way – designing for real needs, using real evidence and data whenever available. We use rapid prototyping to learn quickly and test potential solutions. We use and select from a wide range of UX methods and prototyping techniques, always choosing those best suited to the task at hand.

Implementing Agile in an agency has its challenges but can transform your ability to build the right solution and adapt to changes. Agile should be implemented in a way that works for the individual needs of your organisation. It’s really a process of trial, feedback and adjustment.

If you’d like to talk to us about our Agile UX process, or how we can help you with your own, get in touch at darewest.com.

 

Why being agile doesn’t make you Agile.

As a smaller agency, we’d always fancied ourselves as agile. But it was when we discovered we could also be Agile that things really changed – and not just our appreciation of the importance of capital letters. Managing partner Fergus Adam explains how Dare West learned to love the Agile development process.
DareWestAgileProcess

 

We’ve always been small – able to flex and change the way we work to deal with whatever issues and situations we had to. And it worked pretty well for us… right up to the point when it didn’t.

Digital projects are fiendishly difficult to manage. Every function you need to add leads to greater complexity, more possible ways to do things, and a higher risk of things going wrong.

That was us about a year ago. Even using the latest prototyping and online sharing tools we started to find that, as projects got bigger, it was all too easy for small issues to quickly become big problems. Suddenly it was hard to make a profit because we’d got ourselves into a situation where we were managing all the risk of a project – just before going live.

We needed to change how we worked. And, about a year after this realisation, we have. It’s been bloody difficult. There have been some rocky moments along the way, but we have a way of working that is really making a difference to what we produce.

The core attraction of Agile was frontloading risk. We were pitching everything on the big firework moment. That moment that builds up in a flurry of late nights and arguments, and the inevitable ‘if something can go wrong, it will’ moment. Instead, it would surely be better to lump the risk into the front-end planning, then focus on small increments – delivering bits to the client as you went. Perhaps even launching when it wasn’t completely ready. It all sounded very appealing.

Putting it into practice was hard. Twenty years of trying to change consumer behaviour didn’t really prepare me for how hard changing the way your team works can be. 

Instrumental was Henrik Kniberg’s book Scrum and XP from the Trenches. If you’re looking at your process, this is a must read.

So, off we went and we started working the development team in this way. High fives all round. But it wasn’t really working very well. UX, design and the dev team were not joined up. That’s putting it politely. There was very nearly a fight at one point. 

The solution presented itself when reading about tractors. John Deer put in place Agile as a way of developing new product launches. This grew organically from small IT projects into a company-wide adoption. If they could use it to develop tractors, perhaps, just perhaps, if we adopted it fully, it might help us develop software… the thing it was actually invented for. Pretty obvious in hindsight.

Embracing the methodology wholeheartedly across the business has had a massive impact. And convinced me you are either Agile or not. I recently heard about someone extolling the virtues of WAgile!? Waterfall + Agile, apparently = WAgile. Sounds a bit like our (lower case) agile approach of old.

Also vital was having the right tools. There are three main ones I think.

Central to this process is the humble, not very technical, Post-it. Super Sticky ones are a must – thanks 3M. And a wall. Or several. At the task-level you can’t beat the physical interaction with Post-its and a wall. It’s easier to make sure a stand-up is actually a stand-up in front of a wall. And it’s hugely satisfying for everyone – watching your Post-its march across the board during the two-week Sprint. Our agency is now awash with them. And thankfully, and without a briefing, the cleaners seem to get that they are important and leave them alone.

Next was a tool that allowed us to do a lot of stuff. It’s fine to have the task level on Post-its, but organising everything to get to that point needed a more technical solution. We wanted to standardise and manage User Stories; assign them to (and manage their priority within) Sprints; view and update their status; capture and report poker scores and the task planned detail. We needed to be able to collaborate on and comment on User Stories in a place that keeps that manageable – NOT via email! Lastly, we needed to be able to make all this completely visible to clients. Wrike has been a revelation. It does all this and more. We’ve recently added automatically generated reports. Once created, they’re a live view of progress on a job, removing the overhead of creating client status reports. And dashboards allow each member of the team to view stuff that’s relevant to them. Thank you, Wrike!

Number three is a willingness to change. One of the most valuable things about Agile is the constant opportunity for learning and improvement.  The easiest bit to fall out of the habit of, is reviewing what’s working and what’s not in an end-of-Sprint review. But it’s probably the most important bit (along with a willingness to tear up what you’re doing if it’s not working and try something new).

The team are now working together brilliantly. Our UX, design and test teams are building solutions in collaboration with developers and QA up to the point they are approved, tasked, planned, and head into the development Sprint. Then they’re out the other end as fully formed and tested bits of functionality ready for review by our client and customers for brands as diverse as Good Energy, Places for People Leisure, Starbucks and the institute of imagination.

It’s exciting to be a part of it and watch it happen. And I think it works because we’re creatures that rely on immediate feedback to help us develop and make us happy. Mihaly Csikszentmihalyi stressed this in his groundbreaking book Flow: The Psychology of Happiness. Bringing a bit of this to our jobs can only be a positive.

And we have a Sprint retrospective tomorrow … so this may all have to be re-written. 

Inside the UK’s biggest Umbraco event

Dare West’s Senior Developer Mike Bull takes us on a guided tour of the Umbraco UK Festival held recently in London.

As a developer, I've worked with the open source content management system Umbraco for many years now, and have attended plenty of user groups in that time. But one thing I’d never done was attend the Umbraco UK Festival. That is until 4 November this year at CodeNode in London.

For the past seven years, the hard-working guys at The Cogworks have organised the annual Umbraco UK Festival, and each year it gets bigger and better. With over 300 people in attendance, visiting from all over the world, it’s the second largest Umbraco event in the world, second only to the official Umbraco festival – Codegarden in Denmark. The venue this year was CodeNode in Moorgate, and I can’t speak highly enough about the place. All the tea and coffee you could drink, ample space for everyone, padded chairs – it had the lot! After a bit of socialising and filling up on caffeine, we all made our way to the main room for the introductory talk.

After an introduction to Cogworks, and the venue, we dived right into the engine room, almost literally, of Umbraco HQ with Kris Deminick. It was a great introduction to what makes an average day at Umbraco HQ in Odense, and how they operate as a company. It was particularly interesting to hear how they’ve managed to fit their SaaS offering Umbraco Cloud into their company, and how they manage their day-to-day dev processes. As an audience of developers that primarily work in agency environments, it was good to hear how a growing software company is run, from sales to dev to support.

After a quick break, and a nice chat to a couple of the guys I recognised from Twitter and the Our Umbraco forums, I moved onto Theo Paraskevopoulos’s talk on personalisation in the digital finance sector. As someone with experience of the legal and financial sector, I was looking forward to hearing how he’d managed to use Umbraco in an environment with constraints you don’t usually find in other industries. His talk highlighted, above anything else, that trust was the leading factor, and I think that’s something we can all take away from this talk.

Next up, I joined a group of people and built a lego city!

As fun as this may sound, it served a good purpose, and that was to highlight how the Scrum methodology works. Rather than simply playing with Lego, those of us in the Scrum lego workshop were tasked with building a Lego city for our client (and workshop host) Ania Kierczynska. One of the most common selling quotes of Umbraco to clients is that Umbraco is like Lego, so it was good to actually put this into action and use Scrum when building something out of Lego. We got to grips with Scrum ceremonies, and learned how to work in a team to build everything a city could possibly need, from a nursery to a McDonalds. After some teething issues, we all pitched in, and built an impressive city together that fitted the client’s wishes.

For my last session of the day, I decided to head over to the unit testing workshop to learn some tips on how to unit test an Umbraco website from automation guru Anthony Dang. As a huge fan of automation and test-driven development, it was great to get an insight into the processes that everyone else in the Umbraco community follows. We went over some basic unit tests for the Umbraco APIs, explored the joys and pains of mocking using Moq, and ended by discussing and implementing a number of useful design patterns – namely Service, Repository, and the Unit of Work patterns. While many of the concepts are already widely used, it was great to hear how people are solving problems with them, and their experiences of building Umbraco using these techniques.

Last, but certainly not least, was the keynote. ‘Mr Umbraco’ himself Niels Hartvig took to the stage to discuss this year in the Umbraco community, and his vision for where Umbraco will be going in the future. This included a great demo of deploying through Umbraco Cloud (the artist formerly known as Umbraco as a Service – or UaaS) with the new pending changes feature and Courier 3, along with the coming changes to the package installer within Umbraco itself. Niels highlighted that the growth of the Umbraco community, and the level of quality shown by the community illustrates that there has never been a better time to be a member, and I think many Umbraco devs would agree.

After the keynote, a couple of prizes were given out to people in the community followed by some closing comments, then we all headed to The Globe for a couple of drinks to celebrate a great day.
All in all, I would say that this year’s incarnation of the UK Festival was a huge success. The location was fantastic, the talks were high quality, and the workshops had something to offer everyone. We were definitely spoilt for choice, and if there were more hours in the day, I would’ve loved to see all of them.

Why dynamic ads need more dynamism

Dynamic banners offer amazing flexibility and on-the-fly changes, but the limitations of a single template can still leave them feeling not very… well, dynamic. Here at Dare West, we decided it was high time dynamic ads got a well overdue makeover.

Years of creating dynamic ads for the likes of Aviva, Barclays and Cancer Research UK have taught us a lot about squeezing value from a test-and-learn approach – using different messages and creative for different audiences at different stages of the customer journey.

We’ve made plenty of ads that animate differently depending on the type and location of the viewer. But, unless you create multiple master banners – which becomes expensive and rather defeats the whole idea of this type of advertising – the basic construct has always been the same across the campaign.

In our latest campaign for Aviva, we’ve taken the first step in reinventing the way we do dynamic ads. By cleverly feeding HTML code into the banner for each individual message, we were able to control not only the messaging, but also the look and feel of each banner – right down to an individual word.  

The result was a trick worthy of Houdini. From just four master banners, we pulled off the illusion of 36 completely bespoke banners. Now that’s dynamic.

Pondering ‘Superhenge’ — and why super content deserves a rock-solid platform

How do you build a blockbuster of a movie site on an art-house budget? And what on earth does it have to do with ancient stones? Fergus Adam, managing partner at Dare West, digs deeper.

The recent news of a ‘Superhenge’, finally revealed after thousands of years thanks to the latest geo-scanning technology, made headlines around the world — proving that even something impressive enough to earn the prefix ‘super’ can go completely unnoticed until people have the means to discover it.

A hidden treasure that just needs a little help being discovered? That struck a chord with us.

‘Sounds like Dare West’, you say? ‘A mini-yet-mighty agency who may not be on everybody’s radar yet’. That’s nice of you, but I’m actually thinking of our recent project for Curzon Artificial Eye.

(You’re right though, imaginary reader. As a smaller agency, we know how it feels to have to work hard to stand out. Making us ideally qualified to work on this project — and more than happy to shout about how brilliant it is. But that’s another story for another blog post.)

Back to the story. Curzon Artificial Eye is a site that releases critically acclaimed films to discerning UK audiences. Around 400 so far from some of the world’s greatest directors. Each with its own priceless bounty of trailers, posters and images — along with information on cast, crew, awards and more.

Great content just looking for a good home? What a gift for an agency like ours! But how do you go about building a site worthy of such a catalogue without spending Hollywood money? A site robust and intuitive enough to ignite the spirit of discovery among a savvy audience of film nuts, industry types and plain old average Joes?

Well, the finished site is a perfect example of Dare West’s QuickStartUX™ process in action.

The process is incredibly efficient — and we think it’s the only way to deliver a site on this scale within a limited budget. It means we can get working InVision prototypes under a client’s nose right from the early stages of development. In fact, in this case, it allowed us to get a big chunk of the Curzon Artificial Eye site approved before a single line of code had even been written.

Such solid foundations put us on track for an intense but ruthlessly efficient development process. We didn’t need to waste time (or our client’s budget) trying things out because we’d already nailed down what we wanted to achieve in the design and UX phase.

QuickStartUX™ means a great-value site needn’t be lightweight. Far from it. For our client, we were able to deliver a powerful content management system allowing them to handle all their content in a way that makes it easy to upload and make changes, without compromising the integrity of the site design. Bucketloads of flexibility with a tight look and feel.

So that’s the story of why we were excited to shine our spotlight on the Curzon Artificial Eye film catalogue. A remarkable treasure-trove of movies that makes a few rocks in Wiltshire look like a lot of fuss about nothing.

If you have even a flicker of interest in cinema, do yourself a favour and head to the new Curzon Artificial Eye site. If you like what we’ve done with the place, do yourself another one and visit darewest.com.

Why small agencies are kind of a big deal.

Size matters, but not the way you might think. Senior copywriter James Maher explains why.

Like Lionel Messi, Singapore or the Raspberry Pi, smaller creative agencies punch well above their weight. Sure, they’re faster, cheaper and more flexible — but that’s just the tip of a modestly proportioned iceberg.

I work for Dare West — Dare London’s Bristol-based kid brother and exactly the kind of smaller agency I’m talking about — so of course I’d say that. But I’m not the only one.

According to Jeff Rosenblum (author and Questus founder), because everyone at a smaller agency is exposed to a wider range of tactics and tools, their focus is on client goals — not just their defined roles. As Rosenblum puts it, “Flexibility is wired in … from birth”, and this flexibility “grows fresh ideas”.

Also, he notes, smaller agencies “tend to be younger and less beholden to the old ways of doing business”. By placing a premium on culture, communication and team spirit, they’re able to “fail quickly and turn those small failures into major wins”.

And don’t think you’re missing out by downsizing your agency. Smaller outfits can still offer big-agency bells and whistles. As Will Burns explains in Forbes, “Production values are still valued at smaller agencies, but they don’t have to staff the entire production process in-house, they can outsource some or all of it.”

Smaller agencies “tend to be younger and less beholden to the old ways of doing business”

So, if not every job needs a big agency, why aren’t more brands turning to smaller options? The trick lies in finding them. While the big boys fall over themselves to grab your attention, smaller gems are a little harder to unearth. As Dorothy Mead of blur Group points out, big agencies “have the budget to promote themselves in major channels”, whereas, “Small agencies have to rely upon word-of-mouth, and other below-the-line activities to make themselves heard.”

At Dare West, we’ve never been shy about honking our own horn. And, with happy customers ranging from tech startup BulbThings to bestselling author SJ Watson — plus recent pitch wins for London’s Institute of Imagination and Curzon Cinemas Artificial Eye under our belts — we reckon we’ve got a lot to shout about.

Thankfully it’s now easier than ever for brands to digitally find and compare pocket-sized powerhouses like ours. As Mead rightly concludes, “You buy everything else online, why not business services?”

As I’m a decent sort of chap, let me save you the bother of a Google search. You can find Dare West at our brand new darewest.com site — and in real life at Bristol’s Paintworks — where we believe small is beautiful.

(We’re big enough to know our strengths too. So, if we think your project needs a different set of skills, we’ll happily introduce you to our friends at Dare London.)