I’ve always liked Dave Landis’s diagram on how Design Thinking, Lean UX, and agile go together. Something, however, always felt a little off. Every iteration of this framework I read about still seems to reflect a linear mindset of design that is somehow then attached to a cyclic (Sprint-like) product development mindset.
It’s time to think about discovery work differently
It took me til I went to Jeff Patton’s Passionate Product Owner course (CSPO) that I began to know what I didn’t know about agile product management and a view of its integration with Scrum. In essence, it confirmed what I had felt for a long time:
- Backlog Refinement can be considered a discovery exercise.
- There’s no real reason why you couldn’t expand Backlog Refinement time to do more discovery work if and when it’s needed.
The Product Owner is responsible for the budget and delivering value. They might feel that spending more time doing discovery, thinking and research work is worth investing in (although, this could break the 10% timebox defined in the Scrum Guide by Jeff Sutherland and Ken Schwaber).
Don’t turn UX or design thinking work into Sprint 0
That’s not to say that Jeff was suggesting people should turn Sprint work into upfront discovery in the way some people do with Sprint 0. Sprint 0 is held by agile professionals, such certified Scrum trainers and coaches, as an anti-pattern:
- A Sprint must result in a potentially releasable Increment. A design sprint (aka, Google’s Design Sprint) results in a plan.
- Sprint 0 rarely results in an Increment. Discovery work alone isn’t an Increment, it’s just paper.
- Sprint 0 is rarely timeboxed as a Sprint. People typically continue to design everything until they feel comfortable about creating their upfront design. For some, a Sprint 0 can take months, delaying the release of value and increasing the likelihood that there’ll be a change in the market and users’ needs.
- Sprint 0 is a plan-driven approach. Sprints are instead about empiricism and value.
Don’t turn design thinking into working a Sprint ahead
Many then turn their Sprint 0 design work into a regular activity. Unfortunately, this turns 2-week Sprints into 6-week Sprints before the Product Owner has a potentially releasable Increment.
Putting continuous discovery and delivery together
Jeff Patton painted a picture of two paradigms — “pay to learn” and “pay to build”. At any time, a Scrum Team could be more focussed on one than the other. He also highlighted that through delivery, the Scrum Team (including the Product Owner):
- Learns from building and that this is often more valuable than just doing paper prototypes or similar experiments because the team is actually assessing whether an idea can actually be built!
- Learns about its customers from engaging with them (customers encompassing external and internal users and stakeholders) throughout the Sprint, and in Sprint Review, with a working product. The feedback elicited is of higher quality than feedback on something less functional, like a paper prototype. This is why the Agile Manifesto states it prefers working software over documentation.
- Has opportunities to pivot their solutions by using the Daily Scrum — which is a critical part of the Development Team’s empiricism that inspects their progress toward their Sprint Goal and adapts their plan to ensure they achieve it.
Conclusions
Agile product development is different from traditional, linear, project management. As Product Owners are responsible for budget and the delivery of value to users, the most effective way to achieve this outcome is to combine and integrate experimentation, learning, user feedback into the development process. For many who are used to linear discovery, this presents a challenge – UX people working as a member of the Scrum Team to help the Product Owner steer the product with good design, but also other fellow team members to develop the product according to good, UX practices.
M
