Subscribe to read my programming experiences, ideas, mistakes and tips I wish I'd known myself earlier. Learn how to enable high-performing teams, make an impact, grow as a software engineer and level up your career.
So, we’ve discussed lately what are Scrum’s tradeoffs, now it’s time to weigh them and decide whether it’s a good fit for your team or not. The guideline is misleadingly simple: if you’re faster with Scrum - go for it, if you’re slower - ditch it. But what does it mean “faster”? Well, as Marty Cagan says, we should look beyond Time to Market - the metric when your feature gets deployed in front of your users, but rather focus on Time to Money - metric which means that you delivered something of value, that people are happy to pay for. And that’s something much harder to plan for. I believe that strong, independent product teams don’t need Scrum. Ideally, you give them a problem to solve and they’ll dig into it with their complementary skills and produce a good solution. However, there’s a lot of work out there done differently, just to give a few examples:
​ Have a good one, Wojciech ​ PS. I have lovingly crafted this email using only the best artisanal keystrokes. If you find come across any typos, feel free to fix them yourself and enjoy this new, unique, kintsugi version. |
Subscribe to read my programming experiences, ideas, mistakes and tips I wish I'd known myself earlier. Learn how to enable high-performing teams, make an impact, grow as a software engineer and level up your career.