Dave Austin argues that failing fast is really about succeeding fast, a mindset shift that changes how you approach sprints and product development. He gives practical advice on choosing the right sprint length for your team and project to move quicker.
Chapters
Failing fast. I'm a firm believer in failing fast. I'm also a firm believer that it's a way— I personally think words are very important. How you look at the world, how you think about the world is really important in your attitude. Failing fast in some parlance, and it's not so bad in the startup space, failing is considered— everybody goes, oh, failing is actually a good thing. Well, in my mind, I say I want you to succeed fast. That may mean you make mistakes and have some problems along the way, but the whole goal is succeeding quickly, not just failing. Again, this is really— this may or may not make sense for you, but for me, I think how you approach life and how you approach your products and what you do is really important, how you think about it. I think it's okay to succeed slow. Most businesses do succeed slow. They're not instantaneous hits. There's a few. Those are the massive exceptions. I'm sure— I suspect Tim's talked about how the percentage of venture capital funded things, what percentage actually succeed and get funded versus— it's a small percentage. Hopefully with what you guys are getting here, you're getting— you're increasing your chances. That's the whole idea. I'm sure that's part of why you guys are here. You want to increase your chances for success. But if you have context and think about the longer view, it's okay to succeed slow as long as you're incrementally getting toward that success. I want to talk about sprints a little bit. It sounds like you guys are doing a form of sprints in product. It's very popular. A lot of people think, oh, we do weekly sprints, we do weekly standups, we do this thing. And I want you to think again, if you think more holistically, Sprints, time-wise, everybody goes, oh, it should be weekly sprints. It should be every 8 months. That works sometimes. It doesn't work all the time. So holistically think about how long the sprint really needs to be to be able to actually accomplish what you want. Maybe it's not a week sprint. Maybe it's a day sprint. Maybe it's a 3-week sprint because of the complexity of this core thing you're trying to work on. And maybe it's an engineering thing that takes 2 weeks. But the design's actually only going to take a week. So maybe it's very possible that they should be different for different people in your group who's trying to accomplish something. So think about context again, that word. Think about what's right for your team. Don't just follow, well, this is what it says in Reese's book, so this is what I must do. Think about what works for you. Try things. That's a great thing to try, and if it doesn't work, then fix it. But don't think about it that you have to do Exactly the same as what's been proselytized. Okay.
