3 ms·

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 u

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.

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.