Should a team be able to abort a sprint?
After my second retrospective on a new project, I unloaded some pretty harsh criticism about what we were building. I felt it was a “solution in search of a problem” and “not high value.” After proposing an alternative and convincing everyone to change direction, our sort-of Product Owner blasted me for not bringing my issues up sooner and basically wasting two weeks of work. I said I had voiced my concerns, but not strongly or formally, because I was focused on getting the sprint work done. My feeling was that it wasn’t constructive to second-guess things in the middle of a sprint, and that I trusted the people who made the decisions. Especially as the new guy on the team, I leaned towards agreement.
We both had a point. As a senior person, I had a responsibility to speak up. As a team members, I had a responsibility to get our work done. I don’t know if I made the right choice in this instance. Perhaps if I argued too loud too early, I wouldn’t have had enough credence for people to believe me, and would have been in a worse spot at the end. Or perhaps I would have saved two weeks or work.
This is one more reason I prefer one-week iterations. A week is too small to break up, so you just go heads down. But you don’t work on the wrong thing for too long. You get two or three times the chances to learn and improve.
While I love Scrum, in practice the whole product owner idea often seems to be the weakest point, because it assumes the product owner knows what they want, and that they have an interest. With a paying client it’s okay (if your contract supports it) because, hey, it’s their money they’re wasting on iteration after iteration after iteration.
But in a company, it’s not just the PO’s money. It’s you and your team member’s money and time too. And I think you have a responsibility, as professional, to educate your PO if needed. They hired you as an expert to solve a problem. After all, people usually listen to doctor’s too and trust them as experts. Why not trust the engineers you hire? On the other hand, PO’s who don’t give a damn and are only marginally interested in a project are an annoyance too. The sort your organization picks by random.
The problem with aborting sprints is that it can set a precedent. There is often constant change in a project. What change is severe enough to justify abort? If aborting becomes the norm, the cycles between producing a deliverable cannot be planned any more. You will end up with an unpredictable release cycle, the thing you wanted to avoid by adopting Scrum. i.e. there’s no constant time between release dates. If you really want to abort sprints, then I think you need very very tight rules, which ensure aborts are well justified and are an exception.
But in the end I think the problem lies with the relationship with the PO, and not the way sprints are handled.