Wow LeanUX works with Scrum.
Hello,
A client asked me to explain (in 1-page) how LeanUX works with Scrum.
My answer is below.
I basically see LeanUX working in advance of Scrum, or LeanUX working quite independently of Scrum.
I would be very thankful for any comments / insights / points of view from this community.
Thanks so much!
Bolt-On vs. Independent LeanUX Function
BOLT-ON: Feature Focused Designed
LeanUX can be applied as a ‘bolt-on’ to the Scrum function. In this format LeanUX operates ‘ahead‘ of development, in a staggered sprint approach, providing ‘just-in-time design’ to a development team.
The Product Owner (of the Scrum development team) chooses a User Story (or a Large User Story/Epic) from the Product Backlog for the LeanUX team to work on. The LeanUX team then works an iteration ahead of the development team.
Scrum development teams operate best when they have high-level wireframes, designs, and/or prototyping work that provide additional context and transparency behind what they need to develop. LeanUX provides these artifacts at the commencement of each development sprint, giving the Scrum team a head start in thinking through the idea through from a user-centric approach, and providing some much needed visualization around the ‘words’ of the business case.
But there are some definite cons to the ‘bolt-on’ approach.
- One of the key principles of LeanUX is problem-focused design. When LeanUX is closely tied to a feature-focused development methodology such as Scrum, it tends to become feature-focused as well.
- Doing this type of ‘just-in-time’ design runs the risk of both teams losing sight of the big picture. And a high level view of system is critical to everyone’s success.
INDEPENDENT: Problem Focused Design
Unlike the ‘bolt-on’ LeanUX function, an Independent LeanUX function conducts its work as a completely separate work stream. It focuses on the whole system and the large problems/opportunities that exist within it (instead of working within a feature constrained box). Additionally, it is expertly aware of the overall strengths and weaknesses of the system against competitor offerings in the space.
An Independent LeanUX team typically maintains a ‘living prototype’, and adds to this incrementally with solution-providing Minimum Viable Products (MVPs) over time. Now, you may be thinking, “Having a full living prototype looks an awful lot like a waterfall process- and we’re agile!” I believe this to be a false dilemma. Scrum works best when the team understands the big picture it is building toward. (“Are we building a cathedral, or a garage?”).
Also, the living prototype does not in any way represent a “list of requirements” for the Scrum team to dutifully follow. Optimally the Product Owner (of the Scrum development team) will leverage learning’s from the living prototype to inform the Product Backlog, but the Product Owner is not compelled to draw ideas from just this one source.
Some items that the LeanUX team may feel are worthy of investigation, may not be of similar interest to the Product Owner at the time. LeanUX may choose to focus on an interactive carousel that surfaces product in an exceptionally innovative and useful way for customers, while the Product Owner may have a business requirement to add acceptance of a new credit card. The Product Backlog will contain many items- and it will continue to be prioritized by the Product Owner as s/he deems appropriate.
Further distancing the living prototype from a “list of requirements” is the reality that any MVP chosen by the Product Owner, needs to be validated, refined and iterated on by the Scrum team as the increment gets built.
The living prototype should be a source of inspiration and insight for the Scrum team. It should help the Scrum team extract more detail around a business case, help it to put more context and transparency behind what it needs to develop, all while providing a high level view of the system’s possibilities.