4 ms·
> Anytime an interesting problem comes up to solve we reduce it into ridiculously small cards like "research how to connect to this API", "Evaluate if we can us
by mod 9y ago
> Anytime an interesting problem comes up to solve we reduce it into ridiculously small cards like "research how to connect to this API", "Evaluate if we can use this library", "Write a proposal on how to do X" etc.
Disclaimer: I'm not familiar with SCRUM. But I don't get it, these don't seem ridiculously small at all.
I guess if you're blocked before you get the next task, I understand that pain point, but those seem like nice actionable tasks.
It seems like revisiting the old codebase is something you could do during all your waiting time?
- sheepmullet 9y ago> Disclaimer: I'm not familiar with SCRUM. But I don't get it, these don't seem ridiculously small at all. The problem is the process is only indirectly driven by the real problem you are trying to solve and the feedback loop is slowed down 100 fold. In reality you might look at an API for a couple of hours and realise it isn’t suitable. Maybe in fact you realise that using an external API is the wrong approach altogether. This kind of think, investigate, tinker, evaluate, change loop happens hundreds of times in solving a reasonably sized 6-8 week feature. If you have to stop and wait for the next team meeting before moving forwards to the next iteration of the loop you are in trouble. In reality it causes developers to stop thinking or caring about solving the actual problem optimally. Instead it becomes all about just finishing the next ticket and leaving the hard thinking to once a fortnight.