Agile development methods are sweeping the software industry, but reconciling UX, Agile and stakeholder demands for certainty are a struggle for many companies. Expanding on a (in)famous “Agile doesn’t have brain” quote, Nick Van Weerdenburg, founder of Rangleio, shares his insights from 60+ modern front-end JavaScript projects on how Lean UX can drive the conversations that drive the creation of the right solution for the right audience. Objective Show the audience how Lean UX practices can drive the conversations that drive the effective adoption of Agile in companies small and large. Target Audience Managers, designers, developers and anyone who has a vested interest in build the right software for the right audience in the most effective manner. Assumed Audience Knowledge A basic knowledge User experience and Agile development. Five Things Audience Members Will Learn How to connect the user to the Agile development process How to use Lean UX to drive Agile prioritization How Lean UX creates the right conversations and eliminates the wrong ones How to avoid UX design become a defacto waterfall process How to use Lean UX to help drive effective enterprise transformation to Agile practices

1. Is Lean UX Agile’s Brain?
How Lean UX Fixes Common Agile Challenges
Nick Van Weerdenburg
@n1cholasv

2. What is Lean Agile?

3. Lean/Agile/Scrum Recap
• Incremental and iterative delivery
process
• Work from working software
• Focused on teams

4. Rangle.io
• Lean/Agile design and delivery of modern
HTML5 applications built with modern
JavaScript
• JavaScript-only consultancy “the JavaScript
experts”
• Lean UX design practice

5. Sounds Simple

6. But It’s Not

7. The Process is Hard

8. Lean/Agile Product
Delivery

9. Product
• What?
• When?
• How Much?
• What risk?

10. Product
• Delivered
Horizontally
Database
Integrations
Authentication
Module 2 UX
Data APIs
Social Media
Module 1 UX

11. Product
• Delivered
Vertically
ViewItems
Filterbyinterest
Viewdetails
Bookmarkitem
Notifyaboutnew
Notifychanges
Buyitem

12. Product
• Delivered
Vertically
Database
Integrations
Authentication
Module 2 UX
Data APIs
Social Media
Module 1 UX
ViewItems
Filterbyinterest
Viewdetails
Bookmarkitem
Notifyaboutnew
Notifychanges
Buyitem

13. What’s Hard About Agile
• Building a Team
• Integrating with surround business context
• Maintaining Your Team
• Maintaining Core Practices of Agile

14. Agile Table Stakes
• Clean Code
• Testing
• Communication vs. Specification
• Continuous Delivery
• Working Software
• Sustainable Development

15. Building an Agile Team

16. Aspects of a Strong Agile Team
• Strong communication
• Quick discovery of user and business context
• High EQ- can discuss issues

17. Aspects of a Strong Agile Team
Continued
• Self-organizing- fix issues unique to that team
• Strong bias to delivering value
• Tacit understanding of lean/agile process
• Highly Effective Team (Psychological safety)

18. How to Break an Agile
Team

19. • Provide specs and no communication
• Have no process to discuss specs
• Low autonomy / self-direction
How to Break an Agile Team

20. • Unrealistic schedules
• Pressure to estimate accurately
• Overworked
How to Break an Agile Team
Continued

21. How much of that was about the team
or the process at a high level?

22. The Solution?

23. Look at the Entire
System

24. PO
Scrum Master
Designer
Developer (2)
Quality Assurance
Industry Context
Users
Company Context
What’s the Stakeholder Experience?
What’s the UX?
What’s the Industry Context
Team

25. The Stakeholder
Experience Rules

26. Stakeholder Response to Agile
Project Funding Request

27. PO
Scrum Master
Designer
Developer (2)
Quality Assurance
Industry Context
Users
Company Context
Stakeholders
1. scope
2. budget
3. schedule
4. approval
No Learning

28. Common Conversations

29. “We are doing Agile well. We completed
our last project on time!”

30. What this implies…
1. A fixed scope (Specs/mockups)
2. A fixed schedule
Did conversations happen?

31. How to Fix This in One
Slide?

32. PO
Scrum Master
Designer
Developer (2)
Quality Assurance
Industry Context
Users
LEAN UX
Company Context
What’s the Stakeholder Experience?
What’s the UX?
What’s the Industry Context
Team
Solve the Boundaries

33. Traditional UX and the
Tyranny of the Spec

34. High Fidelity Mockups…

35. …destroy your ability
to delivery small high-
value features

36. Because screens are big…
1. you can’t identify value
2. you can’t discuss why
3.you can’t prioritize value

37. The unit of conversation
!= the unit of design
!= the unit of development
!= the unit of validation

38. HIGH VALUE
low/Medium Value
HIGH VALUE
low/Medium Value
HIGH VALUE
low/Medium Value
HIGH VALUE
low/Medium Value
Feature 1
Feature 2
Feature 3
Feature 4
Specs =>
Screens =>
Larger Features
That Mix High
and Low Priority

39. The Result?

40. The Result?
30 to
60%
Waste

41. Compared to…

42. HIGH VALUE
low/Medium Value
HIGH VALUE
low/Medium Value
HIGH VALUE
low/Medium Value
HIGH VALUE
low/Medium Value
Feature 1
Feature 2
Feature 3
Feature 4
First 4 features
are built fast
and deliver 80%
of value in 1/3
of the time
Feature 5
…

43. HIGH VALUE
HIGH VALUE
HIGH VALUE
HIGH VALUE
low/Medium Value
Feature 1
Feature 2
Feature 3
Feature 4
do we even get
to these?
Feature 5
…
HIGH VALUE
HIGH VALUEFeature 6
Feature 7 HIGH VALUE
HIGH VALUEFeature 8
why build the
low value when
you can go to
the next high
value?

44. Funny Fact…
User’s can’t tell you what’s high value-
you need to watch them experience
the software.

45. Traditional UX design can
increases scope because
there is no way to LEARN
what’s high-value versus
low-value.

46. Lean UX DECREASES IT.

47. By Splitting Big UX into…
1. The design theory/context
1. Style guide
2. Themes
3. Playbooks
2. Small features around conversations
3. Rapid delivery of software
4. User feedback

48. The unit of conversation
== the unit of design
== the unit of development
== the unit of validation
Now…

49. And Replace
1. certainty
2. cost estimates

50. With…
1. understanding and involvement
2. feedback on value delivered and user
engagement
3. trust in the process
4. understanding of the journey and solving
the boundaries, not breaking the team

51. Effective Stakeholder Experience
1. Get the team built
2. Fix the Spec
3. Fix the context
4. Provide feedback that creates a good
Stakeholder Experience

52. Alternative? Try to
Explain the Process

53. Personas Requirements
Lo-Fi
Mocks +
Some Hi
HTML5
Mocks
I1 I2 I3 I4 I5I0
DevelopmentUX Design
Req Docs
Backlog + Prototype + Arch.
Doc + Developer Specs +
Code + QA
50%Clarity
Change
70% 90%
40% 30% 20% 20% 10% 10% 10%
Process
Requirements
QAQA QA QA QA
Hypothesis to Code: The Agile SDLC

54. UX
Design
Design Thinking
Domain
Knowledge
User Goals
User Interactions
User Personas
requirements
static mockups
interactive
prototypes
UX Architecture
and Style Guide
HTML5 Prototype
• visual and interaction
design
Iterative Development
UX
architecture
iterative
development
• refinement of design
• foundation for
developers to use
• developers are autonomous
to build features, even
without prototype
Design Refinement
Lean UX Design Process

55. Now Back to the The
Team and the Context

56. PO
Scrum Master
Designer
Developer (2)
Quality Assurance
Industry Context Users
LEAN UX
Company Context
What’s the Stakeholder Experience?
What’s the UX?
What’s the Industry Context
Team
Conversations
Features
“No Specs”
Solve the Boundaries

57. Immutable Teams,
Mutable Boundaries

58. Thank You
To discuss further, please email
nick@rangle.io, twitter @n1cholasv or call at
416-737-1555.
Follow Rangle.io on twitter @rangleio