In the first article I described combining User Experience design with Agile timelines by having the design team be 1 sprint ahead for a specific project. But at another engagement, the development team had a steady weekly sprint rhythm, and plenty of backlog for an already live product that needed new features and continuous improvement. Slotting design and prototyping efforts into the weekly sprints made no sense, as this pre-development work was very separate from the development team, and would not impact weekly releases. Doing user research, doing user testing, looking at comparators and competitors, trying alternatives, making a prototype, deciding on tests, workshopping and all just doesn’t fit weekly schedules, nor need it.

Our Product Manager, already brilliantly straightening out the backlog and pointing process, suggested creating 2 streams: one for design, and one for development. Each stream would have its own Jira board, but design would be kanban, and development would continue for weekly sprints. She wrote the design stories based on management, and product ideas, and prioritized them along business and user priorities, with my input on structuring the work. I would pull the top one or two design stories and put them in flight.

The design stories would be worked on with whatever tools of the User Centered Design cycle as required to finish. When a story had been explored, prototypes, tested, discussed, workshopped, the results would then be turned into by us into stories on the development board, with the designs and justification attached. The product design team, by that time, would have worked so close in the process I would not even have to present the designs for grooming or sprint planning, as the Product Manager would know all the nuances. This way, the design stories could take the time they needed, but I did have a responsibility to stay timely and keep the development pipeline filled.

Designing in the Browsers and Boundaries

One issue that we did not fully work out during the engagement was how to fit in Designing in the Browser. The visual designer I worked with on the green stream of work had also become an accomplished coder, and when we designed together he would create the designs directly in CSS & HTML, bypassing any comps stage. This means that the resulting design was guaranteed to be implementable–we pretty much had just coded it during the design phase, save for JS wiring–but some of the resources for the gray stream had been put into action before stakeholders had seen the results. The end result was delivered faster in the end by being able to skip the comps stage, but there was a certain unease that committing resources to coding had happened too early and could have ended up wasted. Unfortunately, we never got to the point where we could prove or disprove that designing in code was as cheap as whipping up a quick Sketch comp for people to approve or steer.

Next: Handing over Minimal / More / Complete

One of the issues that arose mixing Agile and UX in two streams like this was the amount of fine-tuning that had to be done after exploring and settling on a design, when handing it over to the development team and their ever-changing circumstances within a dynamic environment. Another issue was how, because the Agile process explores requirements as it builds systems, having a coherent experience as a goal could create major design debt in a moment when a fundamental assumption of the design suddenly got challenged by the result of a sprint or exploration with the client. I will address how these got managed in the next post.

So much has already been discussed about merging the seemingly unmergable: Agile, a software practice based on not even knowing what you will deliver when you start, but delivering it in small, validated, increments, and User Experience Design, which, like every design practice, is about delivering a complete, though-out, lovely, all-encompassing solution. Endless discussions in Agile about which practices to forget and how to convince your client to trust you without a set endpoint, and case-study after mock-up in UX circles about how micro-interactions are a place to shine and create cohesion between the end-to-end service experience. All I have to add to this topic are actual experiences of doing UX in Agile environments.

Agile always proposes People Over Procedures, so of course there isn’t one good recipe for making good UX happen in an Agile team. Here is my first example of a project that I thought went well.

Sprint 0 / Sprint Ahead

This was an agency project, in which the client did indeed have a specific goal in mind. While Agile classically does not like to have an end point truly fully specced and specified before you start, you can’t just tell a client “Give us your money and we’ll see what we will deliver at the end.” It requires a level of trust you just will not get at the start of a relationship. (It’s also counter-intuitive to any other transaction ever: give me your money and let’s see how much cheese I can give you. Give me your money and I will let you know when your bathroom is finished and what is in it. Give me your money and I may give you that much of a massage, or not. Yes, every project has unknowns and cost-overruns, but it is only in software that we so have no clue what we are doing that we cooked up a methodology where we explicitly state we are not quite sure what’s going on, but we’ll all do our best. And then try to sell it to clients. And it is considered best practice based on the bad results of previous methodologies. Software is truly terrible to make.)

This project had very high commercial value, and thus a lot of heavy weight stakeholders. While Agile is supposed to come with taking risks in releases and fixing them quickly, the client would rather first use the considerable star power they had hired to do Digital to give us in the agency good feedback on everything we did. We therefore made the following choices:

• The Design team consisted of a blend of digital graphic designers and user experience designers. Design would be one sprint ahead of Development. This required the Coding & QA team to trust us in Design not to finish a sprint with a design they could not possibly implement. We tried to manage this risk by including them in the scoping and pointing of Design sprints, and by giving them their own pointing and scoping process in their sprints. Looking back I would say that took a really big leap of faith from Development, and I am very grateful they did it, and that Design honored that leap.
• Sprints were three weeks, with a demo to stakeholders at the end of every week. The demos at the end the weeks were: sketches, which the stakeholders would help narrow down, for week one, further worked out half-comps for week two that could be further critiqued by the stakeholders, and fully finished and annotated comps in week 3 that the stakeholders had better sign off on at that point. Delivery management very quickly learned how to elicit the right feedback at the right time to keep sprints within their boundaries and not have to do emergency work after the last demo of a sprint.
• Before the first real sprint, Design was given a sprint to experiment, concept and research. While the graphic designers spent that time concepting and exploring the brand, we in UX explored various aspects of the funnel by sketching the extremes of how clients might make selections on various platforms, mocking them up in Axure, and formally user testing them. By involving the client in this phase, we created a shared understanding of the truisms and of what was actually false about retailing in this sector, and learned to work together. It is true that basically the client paid to receive knowledge they probably already had in their customer experience divisions, but it was only by exploring this area together, and in new ways from our fresh eyes, that we together could push the state of the art further with confidence. Erika Hall wrote a great article about how this works.
  
• We had also negotiated a week of international user testing before the last sprint so we could do major course correction if necessary. This did put significant pressure on the first two sprints to deliver something that could be quickly be made interactive to be tested (and yes, being responsible for that to happen did give me some bad nights) but it totally paid off when we could have really productive discussions about commercial realities vs user satisfaction regarding the amount of steps in the funnel, now with actual data instead of the guesswork and intuition during previous design.
  (Although it pains me that even after this success, too many people in the agency considered user-testing so negotiable with clients such that I kept having to put my foot down again and again.)

The result was a high-quality front-end design and implementation that could be dropped in and wired up by the client to their back-ends.

Because Development was at the story-pointing meetings for Design, they had their say early and could help us create something they could deliver. Still, there were some moments were Design, and specifically UX, was called over to help out with something that simply could not be implemented as designed in the time available, and required re-concepting on the spot. But hey, real-time design is always my favorite.

This was a very specific structure for a new effort, with no Business-As-Usual to work from, and heavy on the stakeholders and experts. It went well enough that we stayed the course for the second brand we were contracted to design an experience for.

In my next post, I will discuss Agile and UX working together on a continuously developed project, and then a post on how Agile requires UXers to think in versions way far ahead.