So, there’s a lot going around just now about iterations vs pure pull. I feel like I want to weigh in on this one.
I should say at the outset, as a coach the presence or absence of iteration/sprint is not a major outrage for me one way or the other. I routinely encounter sprint-based methods. Somewhat less frequently do I see attempts at pull, tho at industrial logic we’ve used pure pull for our product development for many years.
Some ask the question, what do you get for pure pull? This feels a bit presumptive, as if sprints have proven their own cost-benefit ratio to be in our favor.
My experience is contrary. That is, I have not found sprints to give me very much at all, and I have not found them to be cheap. Inevitably, to get at this, i’m afraid we have to be prepared to wrestle with the distinction between theory & practice.
When sprints were proposed, they brought with them several hopeful aspects.
- They aimed at providing simple rhythm, a regular time & place for us to pause, look around, and decide what to do next.
- They intended to shorten planning cycles, a tremendous benefit in a trade that is obsessed with making useless and unresponsive long-term plans.
- They provided a convenient place to hang retrospectives, a potentially critical technique for continuous improvement.
- They provided a rhythmic data pulse up and out of the team so that large orgs could monitor/manage production.
So. Did they do all this? I am certain they did, here and there. And yet, and yet…
The situation in the trade has changed quite a bit and also not at all since then. And as a direct result I am far less positive about the need for sprints than I once was.
First, the rise of CI/CD have made it clear that even smaller cycles are possible and desirable. Sprints are smaller than what came before, but they’re still bigger than what they could be.
Second, we have been singularly unsuccessful, even with sprints, in reducing the planning cycles of large orgs. Sprints are regarded in the majority of cases as nothing more than simple addable work-units bound to far larger plans — on the order of quarters or even years.
Third, tho sprints provided us with a place for retros, now that we know we like retros, we can give them their own place without sprints at all.
Fourth, sprints lend themselves readily to — what to call it — a "bookkeeping" approach to management. People say they hate jira. But they don’t. Jira works fine. What they hate is the expense & stress of the horrific management-by-jira that is so readily supported by the sprint+velocity concept.
Fifth, sprints aren’t free. I commonly encounter 20% end-of-sprint ceremony costs. Not universally, and not in theory, but commonly and in practice. 20%. One day in five, two days in ten.
And sixth, sprints are used nearly everywhere I go as lockstep sync points, which is exactly what I don’t want anywhere in my org if I can avoid it.
On balance, then, I prefer to de-emphasize and even eliminate sprints altogether wherever I can. They are not inherently-in-theory a bad thing, but they seem commonly-in-practice a net negative. I reiterate though: I never walk into a shop and say, "wow, the biggest problem I can see is these damned sprints, we must all immediately toss our sabots into the sprint gears and destroy them!"
What would I do instead, in the rather unlikely event that I finally ascend to my rightful role as king-of-all-the-world?
Daily 10-minute high-discipline standups. A physical board showing all and only WIP and blocked WIP. Product decision-makers living w/geeks. Backlogs maintained away from geeks. Half-hour retros every week. No stories >2 days in length.
So I guess i’m a pull guy. I understand the theory of sprints. I have seen them help. But I believe the theory-practice divide means they don’t help enough or cheaply enough or often enough.