When Sprints Undermine Agility
Sprint Anti-patterns and Why You Might Not Need Sprints
There is a worrying momentum regarding adherence to process and sprints when it comes to agility in the software industry. If one is not careful, an organization may claim to be agile on paper but in practice it is not embodying the essence of Agile.
Here are two anti-patterns relating to sprints to be on the lookout for in your organization.
#1 No cohesive narrative
This first anti-pattern is about having the wrong focus when planning work. Temporal sprint boundaries and velocity are often first class considerations during planning while customer value is secondary, thus making the idea of wrapping work in a cohesive narrative fairly challenging.
You’ll be able to detect this anti-pattern in a sprint demo. When the demo is more recognizably described as a sprint audit that is a bright red flag indicating the team is more focused on process than customer value.
This sprint we completed User Story 123. Proceeds to demo clicking two new buttons.
We also completed some backend work in User Story 456. Proceeds to demo a cURL request to the endpoint.
Lastly, here is a list of bugs we fixed these past two weeks.
If the customer were in the room, which I strongly recommend if you’ve never tried it, what would they take away upon hearing what the team accomplished the past 2 weeks in this example?
Could the customer describe to their boss what the software team accomplished and more importantly why that matters? Would they have any idea what was going on during the API part of the demo? Do they have enough context on the fixed bugs to speak to the value?
From a customer value perspective a sprint audit indicates the software team is getting process tunnel vision while not having strong enough focus on delivering customer value.
#2 Flexible scope is discouraged
This second anti-pattern is the natural drawback of the phrase “sprint commitment”.
It’s often asserted that if the team did not commit to the work during planning then that work can’t be pulled into the current sprint. It’s said that unplanned work needs to go into the refinement, pointing, prioritization, and planning machine before being assigned to a sprint regardless of the ROI of pulling the work in now (where the cost is potentially minimized).
I challenge the reader to identify which of the 12 Agile Principles this kind of pushback is in service of. Can you read past the second principle before having an AHA moment?
To be unwelcoming of changing, clarified, or unforeseen requirements is to pretend that software is easier than it really is and can surely be planned for in rigid two week cycles.
Let’s be clear. Making software is hard. Really hard. I can’t name a single team or organization I’ve worked with where we’ve perfectly threaded the needle on what can be accomplished in a two week timebox more than one consecutive sprint in a row. This anti-pattern is the assertion that that anecdote is the exception, not the norm.
Process is a means to an end.
This is a good opportunity to clarify that process, just like a tool, is a means to an end. We do not build software in service of rigidly adhering to process. Rather, process serves us so that we may serve our customers and if process is in the way then one must push it out of the way for the sake of our customers.
Let’s Recalibrate: Narrative Planning > Sprint Planning
The prompt below is the remedy that guides planning a body of work for a high functioning, customer focused team.
What’s the next story you’re going to tell your customers?
The prompt is solely focused on cohesive value delivery for the customer and it does not matter if that value delivery takes 1 week or 3.5 weeks. I’ll reiterate, rigid 1 or 2 week sprint cycles is not the point. Delivering value to the customer is, even if that value delivery doesn’t neatly fit into a multiple of 5 business days.
Note what is absent from this prompt. There is no mention of story points or velocity. No mention of static two week cycles. No capacity planning and therefore no rigid commitments. Remember, software is hard. It’s ok to plan on some flexibility.
What you’re planning, and therefore what you will demo in a matter of weeks, is a narrative. It’s a story you’re going to tell about what value the customer has now unlocked. It’s the very essence of being customer focused.
You can think of this as introducing a metric that matters. If the goal of a software organization is to iteratively deliver value then make that value delivery a first class concept. Invite a customer to your demo and afterwards have them repeat back to your their takeaways. If they can articulate in a couple sentences the unlocked value you know you’re doing planning correctly. This is a measurement, albeit somewhat subjective, toward a metric that matters most: value delivery.
