Better together: Agile + Lean UX

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.

lean_ux

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

About the author

Related Posts:

What Knowledge and Experience do you need to be an Agile Coach?

To be effective, agile coaches require deep, applied expertise and experience across multiple organisations, multiple projects and industries. As the organsiation scales, the Agile Coaching Development Pathway shows the focus of the role as it scales to more responsibilities beyond being a coach of a single team and provides guidance on what knowledge and experience is required to be an Enterprise Coach.

READ MORE

How do I run a Sprint Review?

The Sprint Review is one of five events in Scrum. It’s purpose is to inspect the Increment of work, get feedback, and then adapt the Product Backlog. And while many people refer to the Sprint Review as the “demo” or “showcase”, this is only one aspect of the Sprint Review.

READ MORE

How do I run a Daily Scrum?

Many people use the Daily Scrum to provide a status report to the Product Owner or Scrum Master, and even to stakeholders, but this event plays a more critical part in ensuring that the team continues to stay focussed on their goal and adapt their work so they improve their chance of achieving it.

READ MORE

How do I run Sprint Planning?

Sprint Planning is one of Scrum’s five events. There’s more to it than just making a plan. Importantly, as an action of empiricism, the team should be inspecting the Product Backlog and adapting, and creating, a Sprint Backlog that makes their plan to achieve the Sprint Goal, and deliver a potentially releasable Increment, transparent.

READ MORE
search previous next tag category expand menu location phone mail time cart zoom edit close