How to Avoid Agile’s Wrath

We’ve all been there.  It’s three days to the end of the sprint and suddenly the business decides that the world will END unless a brand-new feature (that they just hatched) is implemented immediately … if not sooner.  Are you done yet?  How about now? Being a good and faithful Agile scrumling, the Scrum Master tells the Product Owner that this awe-inspiring new feature “will need to go into the next sprint.”

 

The Consequences of Extending a Sprint

You can imagine that this is met with a reaction that would melt most inexperienced Scrum Masters and send their shiny little sprint spiraling off into the abyss. 

You can’t blame the Product Owner either.  These poor souls have the entire business clawing at them daily about everything from bug fixes to wanting new features to wondering why the color of this button is grey and not chartreuse.  The Product Owner is worried that missing deployment dates or not having enough “WOW” factor in each release will put a stranglehold on future budgets – not to mention their own career prospects.  What this person doesn’t want to deal with is a Scrum Master who seems to be pedantically obsessed with priorities and deadlines and doesn’t seem to want to just get moving on what’s important right now!!!!!

On the other hand, we have our haggard Agile Scrum Master who has been down this road far too many times.  It seems that there is always something earth-shattering that must absolutely be added to the sprint right at the end of development … or God-forbid in the middle of UAT.  This person is worried that the Development Team is always under huge time pressure and that this critical new feature only further increases chances of bugs and unforeseen ripple effects.  The stench of scope creep is only surpassed by the radioactive decay of growing technical debt.

Well, we’re in a fine pickle now.

What is a faithful agile scrumling to do??  Let’s go flipping thru our handy Scrum Guide and find out what the folks in the Ivory Tower have dictated from On High: 

You heard that right folks.  If big new requirements come in, then the official Scrum Methodology dictates that you should restart your sprint…

The Agile Scrum Master is getting that look again from the Product Owner who has memorized the second gospel of the Agile Manifesto:

 

So clearly some horse trading has got to be done here.  To start with, and this is really important, it’s critical that everybody understands that we’re all trying to do the right thing.  This is the moment when everybody needs to put down their manifestos and their guides and whatever other religious weapons they’ve got tucked into their socks and talk to each other.  Having lived this moment many times over here’s 3 things I suggest to keep in mind:

1. Minimum Viable Product

• Determine if there is a minimum viable piece of this new requirement that can be delivered within the remaining development time.  This is a phased approach that gets you through this initial crisis and lets you implement the full change next sprint while still delivering value this sprint

2.The Story Point

• Determine what the scope of this minimum viable piece is and have the Development Team story point it as you always would

3.Negotiate a Trade

• This is the really important part.  Remove a feature (or features) from the sprint that roughly equate to the story points for this minimum viable piece.  The removed features would then be implemented in future sprints

This isn’t perfect, but it avoids restarting the sprint which translates into missed deadlines and honestly really translates into what can feel like a soul-crushingly-endless sprint – especially if this happens again and again.  Don’t say that would never happen because I’ve lived it on too many occasions. 

 

Helping the Product Owner Understand

Why is it in the Product Owner’s best interest to deliver this minimum viable product versus just extending the sprint for however long this new feature takes.  Why should the Product Owner be willing to sacrifice anything?  Isn’t the Product Owner the boss?  Isn’t what they’re asking for the WOW factor that is always the goal?  Isn’t this precisely how we “harness change for the customer’s competitive advantage?”

Here’s what the seasoned Product Owner is gaining by understanding this compromise:

Less Chance of Bugs

• Avoiding a Bugzilla wave of issues after this goes to production.   If the Product Owner had chosen to insist on getting everything (including their cake in the kitchen sink with that enticing cherry on top) they would be signing themselves up for a huge testing effort that probably would miss critical issues. 

Fewer Opportunities for Unintended Side Effects

• Insisting on any new feature late in the development cycle is honestly risky at best because this means we’re rushing our Technical Team to quickly architect a solution that, chances are high, will miss something.  Product Owners hate bugs even more than the Technical Team does so it behooves them to avoid scenarios that are proven bug magnets. 

Decreased Likelihood of Missed Dates

• An experienced team knows its velocity.  Therefore, if you story point this new minimum viable product accurately and swap out an equivalent amount of unstarted tickets then you theoretically should be able to still make your production targets

Reduced Risk of Burning out your Technical Team and Testing Team

• Seasoned Product Owners and Scrum Masters should always be aware of anything that can lead to burnout.  You’re only as good as the people around you.  If they are abused too often there will eventually be a price to pay.  This translates into higher turnover and lower product quality 

And honestly … if this world-ending change comes in the middle of UAT, do yourself a favor and wait for the next sprint.  Otherwise, you’re pretty much guaranteed fire and brimstone when you unleash this 11th-hour meteor into your code – and ultimately onto your users.  Remember that part of the old maps that said, “Here be Dragons?”

Unfortunately, there are no shortcuts in software development.  Investing in automated testing is going to pay off in a big way in situations like this because if you have good code coverage you’ll quickly find out what you missed when you decided to play dice with the devil.

OK, kids, I’m going to get off my soapbox with this simple recap.  If you have a change late in the game, do yourself a favor and wait for the next sprint.  If you can’t do that, figure out that little golden nugget in the change request that will keep the wolves at bay and swap this out for a few of those little straggler tickets that are always pending at the end of the development cycle.  Automated tests are your friend.  

And remember, we’re all on the same side.  We all want to satisfy the customer.  We’re all trying to do the right thing … which is to deliver the most high-quality code possible that satisfies the customer’s needs by the date we promised it.

Please be sure to check out some of my earlier blogs that discuss other aspects of the development process:

• Highway to the Danger Zone
• The Illusive Agile Waterfall