![@stacysurla #sprintzerosucks
Agile teams don't want to wait for [UX] results
because they are often focused on getting things
done
Early and frequent UX iterations mean less time
spent by developers getting to done.
UX frequently needs to come behind functionality
and is often dictated by the solution platform.
[We need to do our work] without being
encumbered by visual prejudices
UX is the driving force behind the user's
interaction with the product. Designing early while
developing features is essential, however being
able to respond to user feedback during sprint
cycles is a great case for the Agile approach.
There doesn't seem to be a real understanding of
how to integrate UX into the process.
Working a problem, from research to possible
design solution, before AND during the sprints…
typically yields a better product. "Sprint zero”... is
important, but so is working and iterating through a
design problem with the developers. We try to
make our user stories as robust as possible, but
there's no way to cover everything. Working
alongside the developers closes those gaps.
We need the time and creative trust/buy-in to
make any real difference.
[T]he devs and PM look more for UX on demand,
or even [as] a blessing after the fact
If the UX team would have been involved prior to
development, the project would have been
successful… it was too late. We were recently
ordered a stop-work order
[There are] too many other items that can surface
that take time away from UX
[UX] causes developers to have to undo and redo
work as UX folks and the clients change their
minds
I've tried the "let's do design and dev in one two-
week sprint" approach, and it was painful, and led
to poor outcomes.
I have seen many teams try to run UX in parallel
with dev and have never seen it succeed.
UX is the driving force behind the user's
interaction with the product. Designing early while
developing features is essential, however being
able to respond to user feedback during sprint
cycles is a great case for the Agile approach.
There doesn't seem to be a real understanding of
how to integrate UX into the process.
Working a problem, from research to possible
design solution, before AND during the sprints…
typically yields a better product. "Sprint zero”... is
important, but so is working and iterating through a
design problem with the developers. We try to
make our user stories as robust as possible, but
there's no way to cover everything. Working
alongside the developers closes those gaps.
We need the time and creative trust/buy-in to
make any real difference.
[T]he devs and PM look more for UX on demand,
or even [as] a blessing after the fact
If the UX team would have been involved prior to
development, the project would have been
successful… it was too late. We were recently
ordered a stop-work order
[There are] too many other items that can surface
that take time away from UX
[UX] causes developers to have to undo and redo
work as UX folks and the clients change their
minds
I've tried the "let's do design and dev in one two-
week sprint" approach, and it was painful, and led
to poor outcomes.
I have seen many teams try to run UX in parallel
with dev and have never seen it succeed.
Agile teams don't want to wait for [UX] results
because they are often focused on getting things
done
Early and frequent UX iterations mean less time
spent by developers getting to done.
UX frequently needs to come behind functionality
and is often dictated by the solution platform.
[We need to do our work] without being
encumbered by visual prejudices
Before During NeverBefore During Never
I've tried the "let's do
design and dev in
one two-week sprint"
approach, and it was
painful, and led to
poor outcomes.
Early and frequent
UX iterations mean
less time spent by
developers getting to
done.
I have seen many
teams try to run UX in
parallel with dev and
have never seen it
succeed.
Designing early while
developing features
is essential... [It’s] a
great case for the
Agile approach.](https://image.slidesharecdn.com/whysprintzerosuckssurla-170416002935/75/why-sprint-zero-sucks-19-2048.jpg?cb=1669069151)
Why Sprint Zero Sucks
•1 j'aime•721 vues
Signaler
Partager
Télécharger pour lire hors ligne
For all of Agile’s strengths, it’s not inherently a user centered method. We’re challenged to find ways to integrate UX into agile development, and the Design Sprint or Sprint Zero has become an accepted way to do this. But Sprint Zero isn’t the solution. It’s a workaround. It makes design a different kind of sprint, and silos UX away from the work of the “real” team. This isn’t even an agile way to work, and it’s not the best route to designing excellent user experiences. We need a revolution. We need to incorporate user centered design into the work of everyone on an agile team.
Contenu connexe
Tendances
Tendances(20)
![[Case study] User Center Design in Practice - World Usability Day 2014](https://cdn.slidesharecdn.com/ss_thumbnails/casestudyrft-uxmethodsapplied-wud2014-final-141118074513-conversion-gate02-thumbnail.jpg?width=768&fit=bounds)
![Conducting Usability Research with a Team of One [Revised: October 2009]](https://cdn.slidesharecdn.com/ss_thumbnails/kowalskiheweb2009aps7-091002163651-phpapp01-thumbnail.jpg?width=768&fit=bounds)
Similaire à Why Sprint Zero Sucks
Similaire à Why Sprint Zero Sucks(20)
Plus de Stacy Surla
Plus de Stacy Surla(12)
Dernier
Dernier(20)
Why Sprint Zero Sucks
- 1. @stacysurla #sprintzerosucks Why Sprint Zero Sucks Stacy Merrill Surla UXDC :: 4.15.17
- 2. @stacysurla #sprintzerosucks 1. What you do matters a lot UX is needed for excellence
- 3. @stacysurla #sprintzerosucks Benchmarking U.S. Government Websites, ITIF, March 2017, https://itif.org
- 7. @stacysurla #sprintzerosucks 2. Agile is not user centered
- 10. @stacysurla #sprintzerosucks Thomas Hawk
- 11. @stacysurla #sprintzerosucks 3. Try other ways The Lean Volte approach
- 15. @stacysurla #sprintzerosucks 4. Research says: We live in interesting times
- 16. @stacysurla #sprintzerosucks Bringing UX into Agile using Sprint Zero produces less excellent results than integrating UX into the work of the whole team. = Sprint Zero sucks. Hypothesis:
- 17. @stacysurla #sprintzerosucks Surveyed 516 people 59 responses BA, PM, Tech, Visual, UX UX and Agile Research Respondents by role Who does UX tasks? How well did the project go for: Users, Client, Team, Overall?
- 18. @stacysurla #sprintzerosucks When was UX done? When should UX have been done? UX and Agile Research How does the timing of UX involvement affect the outcomes of Agile projects?
- 19. @stacysurla #sprintzerosucks Agile teams don't want to wait for [UX] results because they are often focused on getting things done Early and frequent UX iterations mean less time spent by developers getting to done. UX frequently needs to come behind functionality and is often dictated by the solution platform. [We need to do our work] without being encumbered by visual prejudices UX is the driving force behind the user's interaction with the product. Designing early while developing features is essential, however being able to respond to user feedback during sprint cycles is a great case for the Agile approach. There doesn't seem to be a real understanding of how to integrate UX into the process. Working a problem, from research to possible design solution, before AND during the sprints… typically yields a better product. "Sprint zero”... is important, but so is working and iterating through a design problem with the developers. We try to make our user stories as robust as possible, but there's no way to cover everything. Working alongside the developers closes those gaps. We need the time and creative trust/buy-in to make any real difference. [T]he devs and PM look more for UX on demand, or even [as] a blessing after the fact If the UX team would have been involved prior to development, the project would have been successful… it was too late. We were recently ordered a stop-work order [There are] too many other items that can surface that take time away from UX [UX] causes developers to have to undo and redo work as UX folks and the clients change their minds I've tried the "let's do design and dev in one two- week sprint" approach, and it was painful, and led to poor outcomes. I have seen many teams try to run UX in parallel with dev and have never seen it succeed. UX is the driving force behind the user's interaction with the product. Designing early while developing features is essential, however being able to respond to user feedback during sprint cycles is a great case for the Agile approach. There doesn't seem to be a real understanding of how to integrate UX into the process. Working a problem, from research to possible design solution, before AND during the sprints… typically yields a better product. "Sprint zero”... is important, but so is working and iterating through a design problem with the developers. We try to make our user stories as robust as possible, but there's no way to cover everything. Working alongside the developers closes those gaps. We need the time and creative trust/buy-in to make any real difference. [T]he devs and PM look more for UX on demand, or even [as] a blessing after the fact If the UX team would have been involved prior to development, the project would have been successful… it was too late. We were recently ordered a stop-work order [There are] too many other items that can surface that take time away from UX [UX] causes developers to have to undo and redo work as UX folks and the clients change their minds I've tried the "let's do design and dev in one two- week sprint" approach, and it was painful, and led to poor outcomes. I have seen many teams try to run UX in parallel with dev and have never seen it succeed. Agile teams don't want to wait for [UX] results because they are often focused on getting things done Early and frequent UX iterations mean less time spent by developers getting to done. UX frequently needs to come behind functionality and is often dictated by the solution platform. [We need to do our work] without being encumbered by visual prejudices Before During NeverBefore During Never I've tried the "let's do design and dev in one two-week sprint" approach, and it was painful, and led to poor outcomes. Early and frequent UX iterations mean less time spent by developers getting to done. I have seen many teams try to run UX in parallel with dev and have never seen it succeed. Designing early while developing features is essential... [It’s] a great case for the Agile approach.
- 21. @stacysurla #sprintzerosucks Never give up, never surrender
- 22. @stacysurla #sprintzerosucks References Benchmarking U.S. Government Websites, ITIF, March 2017, https://itif.org Digital in 2017: Global Overview, We Are Social, January 2017, https://wearesocial.com/blog/2017/01/digital-in-2017-global-overview ICF Perspectives, “The Lean Volte Approach,” ICF, October 2016, https://www.icf.com/perspectives/case-studies/2016/the-lean-volte-approach ICF Lean Volte, March 2017, ICF, http://icfcreative.com/lvb/ @stacysurla #sprintzerosucks Stacy Merrill Surla stacy.surla@icf.com