2 ms·
if you have any kind of size to a team your going to have to coordinate. If your releasing to production you can't break things or change things without communi
by sharemywin 3y ago
if you have any kind of size to a team your going to have to coordinate. If your releasing to production you can't break things or change things without communicating to your customers.
batching those things up seems like way to minimize context switching type activities.
- benkan 3y agoI guess you're right about that. Do you need cycles of two weeks for that? (Scrum officially doesn't force two-week cycles, but it's still the norm) How do you handle Continuous Deployment then? Only to Staging?
- sharemywin 3y agoor a dev server and you then you can deploy qa server or staging for load testing, integration testing if you have multiple sub systems. and testing for load balancing type issues. I'm not arguing against more flexibility when your in small team /pre or early release MVP stage(s) Also, you need a "Hot Fix" short circuit process as well. Although you need to watch it and make sure management is on board with the idea that a reliable road map is important and specific criteria for urgency or everything turns into a "hot fix".
- sharemywin 3y agoI would advocate for a 3 month road map. leaving about 20-25% of your time for small request/bug fixes(unscheduled work). Again this is for an existing product with users. For an MVP you just do it with no code/google sheets/email what ever it takes to get something out the door.