Mar 19 2019 - 5 Rules for integrating UX with Agile and Scrum

5 Rules for integrating UX with Agile and Scrum

March 20, 2019

5 Rules for integrating UX with Agile and Scrum

After more than a year of work, I'm thrilled to announce the launch of this joint effort between Scrum.org, Josh Seiden and myself. The Professional Scrum with UX certified class starts to answer the questions scrum practitioners from all disciplines have been asking. How does design work fit into sprints? What does "done" mean for non-software tasks? How many backlogs should we have? What is dual-track agile? All these questions are answered in the class and they are being offered worldwide now. See you there? Learn more. 

(This article is a sequel to Here is How UX Design Integrates with Agile and Scrum published in October 2018)

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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

Upcoming EventsSmart Scrum Product Ownership - New York City - April 22-23, 2019 - Jeff Patton and I are back in NYC to teach our 2-day class. 9 seats left.Smart Scrum Product Ownership - Denver - April 25-26, 2019 - Please join us in Denver for our first class together west of the Mississippi. We are about 2/3 sold out here. Don't wait. Leveraging Lean UX to Lead Successful Agile Design Teams - Stockholm - May 2, 2019 - This workshop is a one-day event and part of the From Business to Buttons conference. Smart Scrum Product Ownership - Berlin - May 6-7, 2019 - We sold out 6 weeks in advance last time in Berlin.Smart Scrum Product Ownership - London - May 9-10, 2019 - Tickets moving quickly here too.Professional Scrum with UX - Barcelona - May 14-15, 2019 - I am personally teaching one of the first PSU certified courses in Barcelona. Did someone say May in Barcelona? Yep, I did. Lean Product Development - Warsaw, Poland - May 28, 2019 - First time doing a stand alone event in Poland and first time back in Poland in nearly 3 years. Last time I was there I ended up seeing a Polish reggae band that was amazing. :-)

As always, if you want me to work directly with your company on training, coaching or workshops on the topics of organizational agility, digital transformation, product discovery and agile leadership, don’t hesitate to reach out.Like this newsletter? Forward it to a friend.

Reply

or to participate.