Stop doing sprints? That’s outrageous, egregious, preposterous!
There are a few terms we use in the world of software development I dislike. While I’m feeling spirited this morning and would love to tackle the silliness that is “agile release train”, I’ll save that for another time because today I want to address the idea of sprints.
This tweet from my friend Cory House got me thinking, and my gut reaction to his post had me channeling Jackie Chiles from Seinfeld:
That’s outrageous, egregious, preposterous!
I love Cory, I really do. I consider him a good friend and love getting into deeper topics with him. We had a long talk at Codemash this past January where I asked him about the proclamations he makes on Twitter. This is a great example of what we talked about. So, while he’s out “thought leadering” and writing more proclamations, I want to address this particular tweet.
Cory says we should avoid sprints, instead breaking work down into small tickets, and estimating future flow by tracking the number of tickets completed per week. He does say later in the thread that his timeframe of a week is an example, and that the length of time can be anything you choose.
While I don’t disagree with the overall theme of Cory’s tweet - I do think sprints are silly for many reasons - what I want to address is the idea that we can simply stop doing them. It’s not simple, and I’ll tell you why.
I’m not sure if Cory’s clients are large or small, but I do know in every company I’ve worked with since agile became a thing, the decision to “do agile” hasn’t always come from the developers. It has almost always been pushed down from management onto the teams in hopes it will somehow make them work faster or do more or…
They have read books like “Software in 30 Days” and are convinced that Scrum will solve all of their problems! They believe developers are unable to manage themselves so they bring in Agile consultants to teach them better ways to work, and those ways almost always include more meetings, more ceremonies, and, you guessed it: sprints!
Companies hire consultants to come in and tell them that they could improve their overall efficiency in developing software if they would simply get some people certified in Scrum, start performing the ceremonies, break all their work down into two-week sprints, and then BAM! all is well!
Many companies have people in Agile Transformation Offices or Project Management Offices who are looking at things like velocity, cycle time, and more to determine if teams are doing what is expected of them. Sometimes those numbers are misused and abused. There are even special roles on a team to make sure things happen during the sprint! I mean, how could software be developed without scrum masters and agile coaches? gasp
But this gets into a larger discussion of Agile and agile, or more to the point, Scrum or something else you consider to be agile but isn’t because it can’t possibly be unless you do everything the Scrum guide tells you to do because obviously, that’s the only possible way to be Agile. Or is it agile? It’s all so confusing.
I’m starting to rant a bit now, so back to Cory’s tweet.
There are certainly some agile practices that developers like, and it’s rare to find one who would disagree with the ideas behind The Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
And yes, I know one of the principles is
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
But that to me does not say we have to work in these artificial timeboxes that we call sprints! I would rather see a team work towards building the value that’s been asked for, releasing as that value builds, but without these artificial time constraints.
I don’t remember when Sprints became a thing, but for years and years, the teams I worked with would simply build up enough value to release and then, believe it or not, they would release. The good teams would do it more frequently, but we never set any hard-and-fast timebox around our activities. Is it done? Good. Release it.
When we were given a deadline from management, we would balance the work so it would get done in the amount of time we had. We would negotiate scope and features, sometimes delivering small features quickly, while still working on the larger features that would eventually be released.
Were we perfect in our assessment and effort each time? No, of course not. We did spend a certain amount of time figuring out the What and the How before starting though, something that’s not considered very agile. Very few teams I worked with would simply start working if all they had was a sentence or two of “requirements,” but that’s how many teams work now.
It would be great if we, the development team, could tell the Business that we don’t like doing Sprints, or standups, or that we find retros to be annoying at best.
So, Cory, while I would love to avoid sprints, the reality of the modern-day “Agile” organization is that I can’t.
In the words of Hades from Disney’s Hercules:
So, can’t. Love to, but can’t.