3 ms·

Kanban is better, especially paired up with continuous delivery. Once something is done, ship it and move onto something else. Longer research things can be b

by matt_s 9y ago

Kanban is better, especially paired up with continuous delivery. Once something is done, ship it and move onto something else. Longer research things can be broken down into smaller cards, you're just constantly pulling them in. We skip estimates, they prove to be useless indicators of when something will be done so why bother? I think our PM's use velocity as a metric (num of cards done over time) and generally plan enough work so we aren't idle. If you have a weekly grooming session to keep grooming the cards that are next, there shouldn't be wait times. Waiting for sprint review before moving onto further steps is wasting time which goes against Lean Software Development principles.

jfaucett 9y ago
Completely agree. I arrived at a more or less kanban methodology, with a few leftovers from SCRUM of things that do work, like biweekly reviews of the past "sprint period" to evaluate progress and direction, and groom the backlog. It took a couple years of pain and struggle to develop the highly adaptive and dynamic continuous delivery system I now use when managing projects, and I would never return to SCRUM. It works better than the good ol waterfall method perhaps, but it is nowhere near the SE optimum.
chuck4932 9y ago
I will look into Kanban since it has been suggested many times here. However, I'm skeptical of these rigid processes in general. I dont see the need for them unless you have extremely strict requirements from management. I don't see whats wrong with having somebody who is a project manager who understands the work being done and who coordinates with the developers to ensure it gets done in time. In other places it would have been like Project Manger says "we need a feature to do this, this and this, how long do you think it will take?", "I say I will need to spend a few days working on it and then tell you a very rough estimate", after a few days I say "I think it will take at least a month maybe two" or something like that. If I see that there is more work that needs to be done or it will take longer than I initially I thought then I go back to the PM and we re-evaluate what to do. Its not that difficult.
- matt_s 9y ago
  If you are estimating things at increments like "a month" then you need to break things down into smaller chunks that are deliverable. The key part is continuous delivery - even if nobody uses the small addition or you need to put a feature flag in that "turns it on" at some point in the future. If you get into the practice of continuous delivery, which means a dev can ship something into production anytime they need to (with approvals, code review, etc.) then it becomes a more fluid process. Take building a To Do app. It might take a month to deliver the whole thing, right? What if you broke it down into smaller chunks like: * Showing a static list of open items * Clicking an item marks it complete in UI * Save state to a database * Archiving items If each of those 4 were shippable to production with tests, etc. then you can incrementally build the system. It may sound like extra work but once you automate away the builds, running tests, and deploys you can respond much quicker to changes.

by matt_s 9y ago

jfaucett 9y ago

Completely agree. I arrived at a more or less kanban methodology, with a few leftovers from SCRUM of things that do work, like biweekly reviews of the past "sprint period" to evaluate progress and direction, and groom the backlog. It took a couple years of pain and struggle to develop the highly adaptive and dynamic continuous delivery system I now use when managing projects, and I would never return to SCRUM. It works better than the good ol waterfall method perhaps, but it is nowhere near the SE optimum.

chuck4932 9y ago

I will look into Kanban since it has been suggested many times here. However, I'm skeptical of these rigid processes in general. I dont see the need for them unless you have extremely strict requirements from management. I don't see whats wrong with having somebody who is a project manager who understands the work being done and who coordinates with the developers to ensure it gets done in time. In other places it would have been like Project Manger says "we need a feature to do this, this and this, how long do you think it will take?", "I say I will need to spend a few days working on it and then tell you a very rough estimate", after a few days I say "I think it will take at least a month maybe two" or something like that. If I see that there is more work that needs to be done or it will take longer than I initially I thought then I go back to the PM and we re-evaluate what to do. Its not that difficult.

matt_s 9y ago
If you are estimating things at increments like "a month" then you need to break things down into smaller chunks that are deliverable. The key part is continuous delivery - even if nobody uses the small addition or you need to put a feature flag in that "turns it on" at some point in the future. If you get into the practice of continuous delivery, which means a dev can ship something into production anytime they need to (with approvals, code review, etc.) then it becomes a more fluid process. Take building a To Do app. It might take a month to deliver the whole thing, right? What if you broke it down into smaller chunks like: * Showing a static list of open items * Clicking an item marks it complete in UI * Save state to a database * Archiving items If each of those 4 were shippable to production with tests, etc. then you can incrementally build the system. It may sound like extra work but once you automate away the builds, running tests, and deploys you can respond much quicker to changes.