Ok. You don’t believe in them. You’re the lead of an 8-person team. How do you get everyone rowing in the right direction and shipping software? It sounds like

Ok. You don’t believe in them. You’re the lead of an 8-person team. How do you get everyone rowing in the right direction and shipping software? It sounds like you’d just leave everyone to sort it out themselves and believe they will build the right thing and ship it on time. I don’t think sprints are a required practice. I’ve used them with teams simply to help shield them from micromanagement and get them used to iteration cycles. They were held up on releasing anything until a huge batch of features was perfect. Only every deploy into production was met with a week or so of overtime fire fighting because the amount of change they were introducing to the production environment was too large and their staging environments were always under provisioned and didn’t have the same load. Sprints helped them break down work instead of crunching for months at a time. After a while they didn’t need it anymore. So you change things up. Where it goes wrong I think is when people start copying the practice hoping that following the rituals will grant them good software. You still need something though. A little planning goes a long way.