Every limit is a beginning as well as an ending.
As an experience design agency with a strong technical foundation we often find ourselves sitting at the intersection where design and development meet. Or maybe it’s more accurate to say ‘where worlds collide.’ Recently, we’ve had the opportunity to explore the relationship between Design Thinking and Agile Development in our work with clients, and the insights we’ve gained are worth sharing.
What we thought
We got here because as a digital agency we love to experiment – with new ideas, new technology, and new processes. Our development teams were familiar with Agile – we’d used it successfully on many engagements where we needed to align our processes with our clients’ own development environment. And our design teams knew about agile – some of them even had experience being on agile teams or involved in agile projects. This would be the first time we tried running an entire experience design engagement as an Agile project, however – start to finish. To our minds, all we had to do was convert our standard design ‘iterations’ into Agile sprints.
What we found
It soon became clear that while our design teams were able to orient themselves to the cadence and ceremonies of Agile, there were several elements where we struggled to reconcile the needs of the project with the Agile methodology.
1. The concept of a well-defined Product is central to Agile, but we were only just beginning to design a wholly new experience. This made it particularly challenging to function in the role of Product Owner – as there was no product to own.
2. Agile Sprints did not provide a workable framework for incorporating client review and feedback into the design process. This rhythm of interaction and collaboration is critical to the success of the engagement and the health of the client-agency relationship, and it was being neglected. Mid-sprint reviews were an attempt to solve this, but it left our design teams, our Scrum Master and our clients with unclear expectations as to what needed to be accomplished.
3. Agile organizes communication and collaboration into discreet sessions: the sprint kickoff (or planning), daily standups, sprint review and retrospective. By establishing agreements upon effort and clearing any unknowns or other obstacles, Agile is able to establish a basis for rapid, independent work. When design teams are seeking to define a wholly new experience, however, their communication needs are very different. Our design teams needed to be constantly connected to each other – reforming and refining solutions based on new information and new design in real time – edging ever closer to a final solution over the course of a sprint. We found ourselves ending a sprint with the kind of definition that Agile seeks from the outset.
Faced with these challenges, we needed to learn and adapt – which fortunately as designers we were already pretty good at doing.
It was time to step back and rethink the way in which Design participated in Agile. Rather than being a variation/type of a sprint (Design sprint vs Development sprint), we reframed the idea of a Design Iteration; as the means by which we create an experience design product – which Agile is then able to deconstruct into user stories that can be backlogged, developed, tracked, tested and ultimately launched into the world. Since it was important to have continuity in our overall process, we also needed to find a way to maintain a strong connection between Design Iterations and Agile Sprints. Having a consistent cadence to our work and leaning on the terminology, roles and ceremonies of Agile provided that connection.
Why it works (so far)
We’ve seen immediate benefits for our teams and our projects since adopting this revised approach to Agile.
First, our design teams can work towards a more holistic, collaborative vision, represented by the experience design product. Our clients are active collaborators in defining the experience design product through a structured cycle of review and revision. And the role of Product Owner is made more clear and more meaningful, improving the effectiveness of subsequent Agile Development Sprints. Those Agile Sprints are no longer hampered by the need to translate design stories into development stories – an artificial hurdle we created in our attempts to merge Design into Agile. Finally, our project management process was able to more easily and accurately provide meaningful updates to our clients – both on the status of designs in progress and review cycles, as well as development velocity and launch trajectory. This enabled us to better manage the agency-client relationship as well as the project outcome.
Despite our progress so far, there’s still work to be done. Each new engagement brings a unique set of factors and challenges – design, technical or organizational. Our adapted approach to Agile Experience Design needs to be flexible enough to accommodate the particular needs of our clients and their business. We’re still working on getting the timing right – how far ahead must Design Iterations be, to allow Agile Development Sprints to begin? We’d love to hear your thoughts, your experiences, and your ideas. Share them here.