1

Are design sprints sustainable at your company?

1 year ago from , UI/UX Designer

I'm a designer at a B2B SaaS enterprise company - the ratio of designers to developers is not so great but that's another story. We move really fast here, releasing a new feature every quarter. I've read The Design Sprint book (Jake Knapp) and have tried to run a sprint with my team. That went well but I honestly don't think it's a sustainable method.

1) The Design Sprint requires an all day commitment from everyone. It's honestly not realistic for us to do that. I can see this being more realistic for teams where all of the stakeholders are designers. How were people able to gather PMs, Engineering stakeholders, etc for that much time? Not to mention, everyone has different schedules too.

2) The sprint moves too fast. I think this is a bigger issue with tech companies where we want to move fast and not spend enough time thinking about the consequences. I know sprints shouldn't be applied to every project but has anyone actually ran sprints over and over again with successful results (released to the public and it performed well)?

If there are any tips or things you adjusted in the sprint to meet your team's needs, I would love to hear what those were.

9 comments

  • CTodd LombardoCTodd Lombardo, 1 year ago

    Hey —

    I co-authored the first Design Sprint book ( the "other less-popular" one ).

    I was at a B2B SaaS company (Constant Contact, now part of Endurance) when I wrote it, we started it because in late 2012 there was maybe one or two blog posts from Jake and the GV team about sprints. We were doing them inside a larger organization and most of the posts at the time were about design sprint in startups so we started codifying our knowledge initially to train teams internally, and that ultimately lead to converting it into a book, cookbook how-to style. (more on that journey some other time).

    I've personally led over 120 design sprints, mostly in large organizations and for a variety of topics, not just design or product, but service, technology, finance, HR, etc. We experimented with a zillion flavors of them: 1-day (too shallow), 3-day (maybe?), spread out over multiple weeks (don't bother), half-sprint (for ideation), etc in order to account for the enterprise culture of "I have no time" or "that's too much of my day." Some worked. Some didn't.

    A few things I've learned: 1) There's no magic bullet. So many people look to mechanisms like this to solve much larger problems that may be around org structure, incentives, team makeup, product/technology performance, etc.

    2) Timing: My colleague Jill Starret suggested a 10a-4p session, which worked wonders for many teams as it did take enough of the day to ensure focus, yet it allowed for individuals to still do their "day job" before and afterwards

    3) Plan, plan, plan beforehand but improvise during. Get information up front and if you don't have enough research that first day will be a mess. Do a "research sprint" ahead if you need to.

    4) Have a strong facilitator who is not a participant. Being a "Player-coach" is incredibly hard unless you have years of meeting facilitation experience.

    5) A full design sprint is rarely followed by another full design sprint, usually iterations of adjusting the prototype according to what you learned from the test, updating any assumptions you have and then testing again for what you need to learn.

    6) It's not about the outPUT of the sprint, rather it's about what you learned along the way.

    YMMV.

    Good luck!!

    11 points
    • , 1 year ago

      Thank you for the response! That definitely added clarity on how there are certain factors that have to be in place in order to breed the right environment for sprints. I definitely understand the "I have no time" enterprise mentality and it's related to your first bullet in that it points to larger organizational problems. It's definitely the spirit of design sprints that is the take-away.

      0 points
  • Aaron SagrayAaron Sagray, 1 year ago

    It's great that you got one done in your company!

    Sprints are for solving big problems, not for run of the mill feature work. I don't think there's any company that operates regularly on that schedule. We've run 20+ sprints with different teams in our company over the past 1.5 years. No two sprints are the same, and we almost never use the entire GV playbook. Rather, we tailor exercises from GV, IDEO, and Luma to fit the needs of the problem we're trying to solve and the design maturity of the product team.

    The point of sprints and "design thinking" in general is to get product teams out of the Gartner magic quadrant / feature-train mindset, and instead to approach the challenge from a problem-first perspective.

    The important thing is to use sprints as another tool that you can pull at the right time to solve the right kind of problems. They aren't a substitute for long-term discovery/research projects, design iteration, data science, or usability testing.

    4 points
    • Sylvain MarettoSylvain Maretto, 1 year ago

      Aaron is right. Sprints are a tool to get going on a big problem to solve, or to get out of a dead-end when you fill your team's creative problem solving is getting exhausted.

      2 points
    • , 1 year ago

      Thanks for the explanation! That makes a lot more sense to me. Luckily my company was already doing "design thinking" and that was probably why I felt like Design Sprints moved too fast - it's what we are already doing but much faster. There definitely is a time and place for sprints but it sounds like it's not supposed to be the main go-to strategy.

      0 points
  • Kontol Gede, 1 year ago

    yeah, because we only have 1 dev and 1 designer. That's me

    2 points
  • Antonio Carusone, 1 year ago

    I've experienced the exact same issues while at small startups. Since you have to move very fast, and everyone is insanely busy, making design sprints part of the process is very difficult. It's a nice method, but it seems more

    1 point
  • Andrew C, 1 year ago

    We got them down to three 2-hour meetings. Sprints often stem from the perspective of an outside consultant.

    Once a culture of experimentation and testing is established at your company the need for sprints diminishes. That's almost always a huge uphill battle with the way companies choose to operate—even with agile workflows.

    1 point