It's been over a year since I've been on a team that does Sprints as part of its engineering process, and I've really changed my mind on their usefulness. I'm probably pretty old-school "agile" by most standards, so I still think Scrum is better than what most teams out there are doing, but I think it's lost me as a proponent for a few reasons, with the most surprising reason (to me) being its use of sprints.
The sprint, for those few engineers that might not have ever developed this way, is simply a time box where you plan your work at the beginning, usually estimating what work will fit within that time box, and then do some sort of review afterward to assess is efficacy, including the work completed, and the accuracy of the estimates.
I've been involved in sprints as short as a week and as long as a month, depending on the organization. The short timespan can have an amazingly transformative effect on organizations that are releasing software less often than that: it gets them meeting regularly to re-plan, it gets them improving their process regularly, and it gets a weekly stream of software released so that the rest of the company can get a sense of what is happening and at what pace. These are huge wins: You get regular course-correction, improvement and transparency, all helping to deliver more working software, more reliably. What's not to love?
Well I've always ignored a couple of major complaints about Sprints because I've felt that those complaints generally misunderstood the concept of the time box. The first complaint is that a Sprint is just another deadline, and one that looms at a more frequent pace so it just adds more pressure. If your scrummaster or manager treats them like weekly deadlines, he/she is just plain "doing it wrong". Time boxes are just meant to be a regular re-visiting and re-assessment of what's currently going on. It's supposed to be a realistic, sustainable pace so that when observed, the speed that the team is delivering at can start to be relied upon for future projections. Treating it like a deadline has the opposite effect:
Here's the thing though, if it's supposed to encourage a reliable, sustainable pace, why would you ever call it a "sprint"? "What's in a name?", right? Well it turns out that when you want to get people to change the way they work, and you want them to understand the completely foreign concepts you're bringing to them, it's absolutely crucial that you name the thing in a way that also explains what it is not.
In Scrum, it's also common to have a "sprint commitment" where the team "commits" to a body of work to accomplish in that time frame. The commitment is meant to be a rough estimate for the sake of planning purposes, and if a team doesn't get that work done in that time, it tries to learn from the estimate and be more realistic in the next sprint. Developers are not supposed to be chastized for not meeting the sprint commitment -- it's just an extra piece of information to improve upon and to use for future planning. Obviously naming is hugely important here too, because in every other use of the word, a "commitment" is a pledge or a binding agreement, and this misnomer really influences the way people (mis)understand the concept of sprints. Let's face it: if people see sprints as just more frequent deadlines (including those implementing them), the fault can't be entirely theirs.
Well "iteration" is definitely a much better name, and I hope people use that name more and more.
More importantly though, I'd like to argue that time boxes for planning and delivery are fundamentally flawed.
I've personally found that sprint commitments are entirely counter-productive: A team can just gauge its speed for planning purposes based on past performance instead, which is really what the sprint commitment is meant to be. We should be forecasting entirely based on past performance, and adjusting constantly rather than trying to predict, and trying to hold people to predictions.
Also, with planning happening at the beginning of the sprint and software delivery happening at the end, in a regular cadence, the team is much less likely to do things more frequently than this schedule.
Instead of planning and releasing on the schedule of a sprint, we've had a lot more success practicing just-in-time planning and continuous delivery.
Planning should happen on-demand, not on a schedule. Planning on a schedule often has you planning for things too far ahead, forcing people to try to remember the plan later. I've seen an hour's worth of planning fall apart as soon as we tried to execute the plan, so I really don't see the point of planning for particular time-spans (especially larger ones). Teams should simply plan for the work they're currently starting, the natural way, not based on time, but based on the work they have to do. They should plan and re-plan a particular task as frequently as is necessary to deliver it, and they should plan for as long or as short as necessary to come up with a plan that everyone is happy with. Planning naturally like this leads to more frequent situations where developers will say "hold on, we should sit down and talk about this before we continue the current plan", which is good for everybody involved.
The cadence of delivering software at the end of a sprint almost always means an organization does not deploy the software more often than that cadence. I've worked on teams that tried to make "deployment day" somewhere in the middle of the sprint to emphasize that the sprint boundary is just an arbitrary time box, decoupled from deployment, but we never managed to deploy more often than once per sprint, and it really only resulted in a de facto change in the sprint schedule for our QA personnel. The very existence of a time-box puts people in the mindset that releasing software, deploying software and calling software "done" are all the same event and there's a scheduled time for that. Without the time-box, people start to think more freely about ways to decouple these events and how to safely improve the customer experience more often. Today, free from sprints, I'm safely deploying to production multiple times per day.
Now Scrum proponents will argue that Sprints can be exactly like this -- sprints do not preclude JIT planning or continuous delivery -- and the time-box just adds additional points of planning and review to ensure that the team is doing the necessary planning and reviewing. While I wholeheartedly agree with this on a theoretical level, this is not what ends up happening in practice: In reality, when you schedule time for particular aspects of work, people tend to wait until that schedule to do that type of work.
And I realize that what I'm suggesting sounds a bit more sloppy, and lacks the formality of a scheduled cadence, but it simply ends up being more natural and more efficient. These concepts aren't new either -- any teams that have been using the venerable kanban method will be familiar with them.
With all this said, if a team is going to continually improve, I haven't seen a better mechanism than the regular retrospective. I just don't think Sprints are necessary to make that happen.