This document discusses 3 common reasons why agile design fails and provides countermeasures to address them. The 3 reasons are: 1) High uncertainty in design work makes estimations difficult and causes sprint goals to not be met. Countermeasures include reducing uncertainty through user research and workshops. 2) Some scrum rules do not fit the realities of design work. Countermeasures include different task structures for design and development. 3) Interdisciplinary dependencies between design and development cause issues when changes are needed. Countermeasures include planning more sprints upfront for uncertainty and optimizing handoff processes.
9. 9
- Streamlined end-to-end process
- Structured meetings & communication
- Client knows what to expect (reviews,
standups)
- Handoff from design to dev should be
easier and faster
Expectations
Intro
14. Reason 1
High uncertainty
- Design work becomes less predictable
- Estimations become guesswork
- Design change requests consume time & resources
- Sprint goals aren’t met and development is blocked
14
15. Reason 1 - Counter-measures
Reduce uncertainty
- Requirements as the “lowest fidelity” prototype
- Requirements have to be ready before the next sprint
- Requirements define the WHAT, not the HOW
- Force initial User Research and Workshops
- Delivers valuable insights as decision base
- Gets everyone on the same page
15
16. Reason 1 - Counter-
measures
Reduce uncertainty
16
Uncertain Very certain
Research
Workshops
17. Reason 1 - Counter-
measures
Reduce uncertainty
17
Explorative Tickets
Workshops
User Research
18. Reason 2
Scrum rules VS the design
reality
- Some default rules just don’t make sense for the design
process (f.e. 2 week sprints)
- Design ticket size affects the design work and review
meetings, not just the burn-down-chart!
18
20. Reason 2 - Counter-measures
Scrum rules VS the design
reality
- Different ticket/task structure for design and development
- The overall design budget used is more telling about the
progress of design than the finished ticket count or ticket
estimates
- Trust the process, loosen the constraints (f.e. Kanban)
20
22. Reason 3
Interdisciplinary dependencies
- Sprint 0 is a myth
- Change request are a grey area
- If development is closely behind design, change
requests have waterfall-like effects
- Design changes are often dismissed due to other sprint
goals (f.e. Unblocking development)
22
23. Reason 3 - Counter-measures
Project setup & handoff
process optimization
- Plan enough sprints upfront for the uncertainty during design
- Adjusted meeting setup
- Standup every second day
- Review meeting once a week (1 week sprints)
- 1 additional internal review meeting for feasibility check
with dev
- Focus on a flawless delivery and handoff process between
ALL disciplines (f.e. With Figma)
23