3 ms·

I've been lucky enough to be on projects where it's done well (not scrum) and would never go back after working that way.

emodendroket 9y ago
I've experienced "no methodology; just people kind of describing what they want and you make it up as you go along" and Scrum and I prefer the former, but I suppose it's possible that someone out there is doing Agile in a way that is better than the one I learned in a bunch of excruciatingly boring training sessions from consultants. e: Actually I did Kanban too and that was OK, but that is a lot closer to the "no methodology" thing and anyway doesn't involve you making decisions like "oh, can't start working on that, because the sprint is almost over."
- lmm 9y ago
  Kanban is very much Agile. Scrum can be implemented in a variously heavy to lightweight way, though FWIW I found having leftover time at the end of a sprint that could only be used for non-business-facing work (e.g. improving the build system, refactoring of code that wasn't immediately being worked on) to be very valuable.
  - emodendroket 9y ago
    I guess the cynic in me finds it predictable that most Agile shops (at least IME) would be doing Scrum and not something like Kanban, even though it largely works against the supposed core values of Agile.
    - dreamfactored 9y ago
      Yep Kanban is the way to go, focus on flow, small batch sizes, reducing waste of wait times and handovers. Look at cumulative flow and rightsize stories instead of fretting over estimation, points, burndown, and all that mini waterfall that scrum seems to entail. Takes most of the drama and hysteria out of delivery.
      - emodendroket 9y ago
        Ultimately it makes no difference whether you're doing "story points" or estimates in units of time. All that's going to happen is they'll be converted to units of time in a way you don't quite understand. It's just so naive to believe any of the Scrum promises.
        dreamfactored 9y ago
        It's why we always do rightsizing and never numerical estimates. You can calculate delivery dates by counting stories * average story time - very fast, very simple, and amusingly at least as accurate as detailed time estimates. Has an interesting side effect of tying scope to delivery. So if you want to reduce delivery time, it's clearly understood as under control of stakeholders and done by dropping stories. If you can't rightsize to a reasonably narrow range (we use 1-5 days) and have to estimate (e.g. sifting stories for prioritisation purposes), t-shirt sizing usually works ok and gives the required info without opening it to abuse.

emodendroket 9y ago

I've experienced "no methodology; just people kind of describing what they want and you make it up as you go along" and Scrum and I prefer the former, but I suppose it's possible that someone out there is doing Agile in a way that is better than the one I learned in a bunch of excruciatingly boring training sessions from consultants. e: Actually I did Kanban too and that was OK, but that is a lot closer to the "no methodology" thing and anyway doesn't involve you making decisions like "oh, can't start working on that, because the sprint is almost over."

lmm 9y ago
Kanban is very much Agile. Scrum can be implemented in a variously heavy to lightweight way, though FWIW I found having leftover time at the end of a sprint that could only be used for non-business-facing work (e.g. improving the build system, refactoring of code that wasn't immediately being worked on) to be very valuable.
- emodendroket 9y ago
  I guess the cynic in me finds it predictable that most Agile shops (at least IME) would be doing Scrum and not something like Kanban, even though it largely works against the supposed core values of Agile.
  - dreamfactored 9y ago
    Yep Kanban is the way to go, focus on flow, small batch sizes, reducing waste of wait times and handovers. Look at cumulative flow and rightsize stories instead of fretting over estimation, points, burndown, and all that mini waterfall that scrum seems to entail. Takes most of the drama and hysteria out of delivery.
    - emodendroket 9y ago
      Ultimately it makes no difference whether you're doing "story points" or estimates in units of time. All that's going to happen is they'll be converted to units of time in a way you don't quite understand. It's just so naive to believe any of the Scrum promises.
      - dreamfactored 9y ago
        It's why we always do rightsizing and never numerical estimates. You can calculate delivery dates by counting stories * average story time - very fast, very simple, and amusingly at least as accurate as detailed time estimates. Has an interesting side effect of tying scope to delivery. So if you want to reduce delivery time, it's clearly understood as under control of stakeholders and done by dropping stories. If you can't rightsize to a reasonably narrow range (we use 1-5 days) and have to estimate (e.g. sifting stories for prioritisation purposes), t-shirt sizing usually works ok and gives the required info without opening it to abuse.