(This article is a sequel to Here is How UX Design Integrates with Agile and Scrum published in October 2018. It also appeared first in my once-monthly newsletter. Sign up here and join 12k others.)
When I started my career, software came in a box. If that sounds weird to you, know that when I was a kid my dad would bring home the punchcards on which software came in the 1970’s. In both of those cases, more than 20 years apart, software was static. It had an end state. Fast forward another 20 years and these concepts seem ridiculous now. Today we build continuous systems that can be optimised indefinitely. This makes the question, “When are we done?” a difficult one to answer. We need the answer to this question because it helps answer other, even more important questions. Does the team get rewarded or chastised? Do we move on to the next initiative or not? Does the stakeholder get their bonus?
Product development teams using scrum (or any form of Agile development) have a clear understanding of the definition of done. It will often mean “the minimum criteria the product/service has to have to meet the needs of ‘the business’.” This regularly amounts to a checklist of features a stakeholder (or product owner) has mandated that is now 100% complete. Software developers often call this, “works as designed.”
But “works as designed” only tells us that the software consistently does what we told it to do. Unfortunately, that’s not enough. In fact, it’s only the start of the conversation we have with our users and customers. It’s the continuous improvement of our systems to deliver increasingly better experiences that helps us deliver real value to them.
So then how do we define “done” for our teams? When do they move on to the next initiative? A lack of return on investment is a good place to start but how will we know that the return won’t come? The answer lies with our customers. We measure their behaviour. We listen to their needs, assess if our systems still meet them and what we’re willing to do to meet those ever-changing needs. We call these measures outcomes.
These outcomes can’t be predicted because human behaviour is difficult to predict. They require team members actively engaged with customers to understand these behaviour changes, the reasons behind them and the possibilities for better meeting customer needs in the future. The good news is that your company likely already employs people who are particularly good at these activities — designers. And while designers are present in nearly every company today, most of them don’t sit in positions to influence broad decision-making. In fact, many are often left outside the agile development processes reserved for developers and product managers.
Integrating designers into the agile product development process is an ongoing challenge for most organisations. With the benefit of nearly 20 years of designing, leading and consulting with product teams I have come up with the following 5 rules for product teams to follow to make sure user experience (UX) design is integrated successfully into the agile process:
- A dedicated designer on every team
There is no compromise here. Without a dedicated designer on the scrum team, what you have is a software engineering team and, while that team will absolutely deliver a user experience, it will not be of the same level of quality without a designer’s input. - Team-wide customer exposure hours
I learned this term from Jared Spool who did research proving that teams who spend at least 2 hours per person every 6 weeks “exposed” to customers (e.g., taking support calls, talking to users, watching people in a store, etc) developed more successful products. - Design work is a first-class citizen of the backlog
The tl;dr here is this: one backlog. Development work, QA work, design work, research work, you name it — it all goes on one backlog, prioritised together with one team (the *same* team) doing all of that work. As soon as the work is divided between more than one backlog, the team will look to one of them as the “primary” one and the other(s) will go neglected. - Outcomes as prioritisation filters for the backlog
I’ve written at length about outcomes (and Josh Seiden’s written a whole book on it!) but the one thing I want to point out in this context is that every backlog item must be filtered through the team’s outcome goals. Ask, “Does this work help us towards our goal?” If the answer is no then we don’t work on that item. - Cross-functional participation in learning activities
User Experience and Design bring with them many types of learning activities. These activities may be led by Designers (or researchers) but they should be practiced and attended by the entire team. The more the team can learn together, the less time is spent sharing and debating the learning and more time spent deciding what to do about the things we’ve learned (which is a far more productive conversation and use of the team’s time).
The iterative, retrospective (inspect and adapt anyone?) nature of scrum is a natural fit for UX and Design activities. The integration of customer insight into the process comes directly from the Agile Manifesto (customer collaboration and all that…). UX and Design move us even closer towards Agile’s customer-centric goal of satisfying the user frequently and at high quality. Follow these 5 rules to help bring your agile design and development practices closer together.
What rules have you used to bring UX and scrum closer together? If you’re interested in learning more, Josh Seiden & I have recently launched the Professional Scrum with UX certification course along with Scrum.org. Lots more information here.
[Jeff]
@jboogie
www.senseandrespondpress.com
jeff@gothelf.co
Upcoming events can be found here
