Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Why Sprint Zero Sucks

429 views

Published on

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.

Published in: Software
  • 1. What you do matters a lot/ UX is needed for excellence We’re working within frameworks, like the Agile development framework, that fail to lead us to excellence. U.S. government adoption of Agile continues to grow, yet 92% of the most-used sites fail to meet basic standards. How important is it that IRS.gov works? It’s our ethical imperative to change this. It needs to be commonplace that digital products work really well for people. The work we do matters. The spaces we build penetrate the lives of more than half the people on the planet, over 70% of the people in the Americas alone. Think about what you do. Taking examples from my own recent experience, you put tools in the hands of people who have to find the nearest emergency room in a hurry. Or who need to learn whether vaping is okay for their teens. (It’s not.) We create structures that help people make a difference in the world. I’m inspired by Gofundme. People use it to raise money for large scale relief. It’s also a platform for personal and local causes. In Chicago last fall a passerby spotted Fidencia Sanchez pushing his ice-cream cart, and thought: This guy needs a vacation. The campaign raised not $3 thousand but over $300 thousand dollars, enough for the Sanchezes to retire, if they want to. User experience is key to building products like these, excellent products that solve real problems and get used by people. You have this power and this responsibility.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • 2. Agile isn’t user centered But consider where we do our work. We often find ourselves in semi-functional or dysfunctional IT projects. In fact, it’s kind of the norm. I’m focusing on Agile, but not because Agile is evil. On the contrary, it’s been a tremendous step forward. But Agile is not inherently a user centered method. It’s about building functioning code that gets launched on time. User experience is the missing piece. UX is the way we build the right product, one that solves a problem and gets used. There are people who know this, and there have been efforts to integrate UX into Agile. One primitive method is to wave some UX around after things have gone wrong. But we’re not magicians to paraphrase Pope Francis. It doesn’t work that way. Another approach is to add a Sprint Zero or Design Sprint in front of each release. That’s where UX folks do UX things to set the development team up for Sprint 1. After that, we just keep UX ahead by a duration. The upside is, user experience does become part of development. That’s great! The downside is, the team is siloed, and more to the point, we’re still delivering digital products that aren’t excellent. That don’t meet basic standards or solve real problems. Even though we’re delivering those things faster. Why? It’s because in the Sprint Zero approach, UX is bolted on. Its products are handed over to the real team, who are waiting impatiently to get started on the real work. UX is not core to how Agile operates. It’s a way of waving the magic wand iteratively.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • 3. Try other ways/ the Lean Volte approach How can an Agile practice manifest its destiny? We need to drive with UX. UX in the car, not in the trunk. In other words, center the team AROUND the people we’re solving problems for. Make user centered design the normal way for everyone to work. My colleagues and I have been experimenting for several years and have developed an approach that uses Lean UX, design thinking, and Agile. We call it the Lean Volte. I offer it to you as one field-tested alternative to Sprint Zero. • We work in collaborative, multi-disciplinary teams that include every necessary role. • Everyone does design, and everyone supports building things, each from their unique perspectives. • We integrate clients and end users into the design process. • Design thinking is baked into how the team solves problems. • Attention to well-being is important. A typical Lean Volte includes exercise, healthy snacks, meditation, and yoga. We’re set up this way – not because it’s fun, even though it is fun. But because it lets us focus on finding and solving the right problems. To state our assumptions, then build, test, experiment, and adjust course. We’ve done more than a dozen of these so far, for the National Cancer Institute, EPA, CDC, and other clients. We’ve used it to write proposals. And we used it to develop a How-To Guide and explainer video to train staff in doing Lean Voltes. You can access the materials at this website. So. Is this the right way to integrate UX into development? Is it the only way to do it? Would it work in your situation? Is it not going far enough? I don’t know. It’s an experiment in the field, on real projects, with real problems and real teams. It’s working for us. And if I’m wrong, as we discover there are better ways, we’ll change what we’re doing.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • 4. Research says we live in interesting times Speaking of testing assumptions, let me share some research I’m conducting. Here’s my hypothesis. Some details of the study, characteristics of the respondents, and data on their perceptions of UX in their Agile project. In these projects, UX happened during the sprints and at Sprint Zero in about equal proportions. All this was somewhat interesting, but then I analyzed the open ended question: How does the timing of UX involvement affect the outcomes? By normalizing the responses, we see when people thought UX should have been done. The majority said UX should have happened before development. I noted this doesn’t support my hypothesis about Sprint Zero. And interestingly, a significant number said UX should not happen at all. Digging deeper into the qualitative data, what emerges is not the conclusion that Sprint Zero works. It’s a tale of frustration and dissatisfaction, of wanting to answer the same question I’m asking. How do we really integrate UX into Agile? When people said UX should happen BEFORE the sprint, it was for one of 3 reasons. Because doing it after development’s over is too late. Because UX is secondary to what the Agile team is doing. Or, because doing it during development just didn’t work. For instance, I've tried "let's do design and dev in a two-week sprint," and it was painful, and led to poor outcomes. I’ve seen many teams try to run UX in parallel with dev and have never seen it succeed. These observations are arrows through my heart. While I’m fighting for integrated UX, the reality is, doing it that way is painful and sometimes never succeeds. But people who said UX should happen DURING the sprint had experienced it succeeding. It’s not just a dream. Finally, some said UX should be done sparingly or not at all because, they said, Agile work is not about the user. UX gets in the way of the real work of the Agile team. These views came from UX practitioners as well as developers. In other words, bolting UX onto Agile is not the answer for anyone.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • 5. Experiment and figure it out In summary, the question of how to get to excellent is critical. Digital systems that work really well are not a nice-to-have. Indeed, we have a moral obligation to make sure the systems we design are excellent. Tweaks and workarounds to integrate UX a little better aren’t good enough. We need a transformation. We need a revolution. Sprint Zero Sucks! Sprint Zero sucks. And we’re not going to take this any more.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

Why Sprint Zero Sucks

  1. 1. @stacysurla #sprintzerosucks Why Sprint Zero Sucks Stacy Merrill Surla UXDC :: 4.15.17
  2. 2. @stacysurla #sprintzerosucks 1. What you do matters a lot UX is needed for excellence
  3. 3. @stacysurla #sprintzerosucks Benchmarking U.S. Government Websites, ITIF, March 2017, https://itif.org
  4. 4. @stacysurla #sprintzerosucks
  5. 5. @stacysurla #sprintzerosucks
  6. 6. @stacysurla #sprintzerosucks
  7. 7. @stacysurla #sprintzerosucks 2. Agile is not user centered
  8. 8. @stacysurla #sprintzerosucks Thomas Hawk
  9. 9. @stacysurla #sprintzerosucks ladyb
  10. 10. @stacysurla #sprintzerosucks Thomas Hawk
  11. 11. @stacysurla #sprintzerosucks 3. Try other ways The Lean Volte approach
  12. 12. @stacysurla #sprintzerosucks Lean Volte
  13. 13. @stacysurla #sprintzerosucks
  14. 14. @stacysurla #sprintzerosucks icfcreative.com/lvb/
  15. 15. @stacysurla #sprintzerosucks 4. Research says: We live in interesting times
  16. 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. 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. 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. 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.
  20. 20. @stacysurla #sprintzerosucks 5. Experiment Figure it out
  21. 21. @stacysurla #sprintzerosucks Never give up, never surrender
  22. 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

×