I haven't practiced structured agile (in my case Scrum) in years. Mostly because every single sprint becomes so derailed by "urgent" outside requirements that any sort of cohesion and planning goes out the window.
Good luck telling the client that their P0 ticket will need to wait until next sprint. Or more accurately: tell the product owner or account manager to tell the client. Which in my experience often results in them caving to the client demands.
Then you have clients who won't pay for the planning and retrospective time.
I think my record is 4 consecutive Sprints before things went completely off process. I just gave up.
This is always the issue, no institutional buy-in.
One thing I learned a long time ago is that a "bad" process that is followed universally by everyone (dev, pjm, pm) will always out perform a "great" process with only token buy-in and constant exceptions.
Consistency allows even the worst process to become familiar enough to be improved on and reduces the overload of having to context switch unexpectedly, and it's amazing how much time can be wasted by people not knowing what process to use and having to either waste someone else's time to find out or do whatever their best guess is, probably wasting time much later on.
If you've ever seen someone operating a terrible piece of old data entry software they've been using for decades it's amazing how fast someone can be even at jumping through pointless hoops to get the job done - often a problem when introducing a newer process that might seem more efficient from the outside!
It's easier to take the path of least resistance and usually you won't get shot for it. Trying to fix things often makes you look like a trouble maker, especially if something doesn't work as well as it could (which often happens when iterating through change).
> Good luck telling the client that their P0 ticket will need to wait until next sprint
A key cause of that being a problem is stacking the entire team with a full sprint of vital work. Leave some time for issues. If no issues come up, pick up some nice-to-have tickets in the now spare time at the end of the sprint, or get started on work for next sprint.
If you absolutely must give everyone a full sprint of work every time, make sure some of it is from the nice-to-have pile so it can be put off when the surprise P0s come in (and in the absence of surprises, you get to clear off some of what are now nice-to-have bits of work but later might otherwise get surrounded by code/infrastructure that assumes they'll never happen so morph into nasty technical debt and/or their very own surprise P0). But if you try this, good luck explaining upwards why nice-to-have tickets are on the board while there are more important ones in the pile…
Even if you do have room in the Sprint, the formal Scrum methodology says adding a ticket requires tossing the Sprint. I suppose if you are removing an equal number of story points you can get away with it if you look the other way.
But then you have another issue, the sprint gets oversubscribed or behind and instead of stuff moving to next Sprint the team works overtime. Now all the sudden the velocity calculations look like you have one velocity but really it's because you added extra capacity that sprint.
Won't take long until "extra capacity" because "the normal way."
Isn't this a capacity planning issue? I thought if you are 100% complete on every sprint, then you are planning incorrectly. It's not supposed to be a report card every 2 weeks but an approach to review your work to build for the long term, right?
You're supposed to use your velocity to figure out how many story points you can reasonably complete in a Sprint. But if the velocity is padded (by adding invisible capacity... extra hours unaccounted for in the velocity calculation) then you end up with unrealistic expectations.
If your velocity is correct you should end up with 100% completion and your employees having a work life balance. But I rarely see that.
If a developer finishes all their tickets they should help out other developers. And if by some stretch you overestimate... which I think may be a worlds first for software ;)... you're supposed to grab the next highest priority ticket from the backlog.
But I've also seen an approach where the sprint purposely has more than the velocity in it as kind of a "stretch goal" but everyone on the team knows anything bellow the velocity line is unlikely to get done.
I've also seem places where the stretch goal becomes the goal the client is told will be completed... those places are toxic, if you find yourself working at one, run.
Edit: If you are 100% complete on your first Sprint then yes, you probably incorrectly planned capacity. It takes 3 sprints to get a velocity. But once you have a velocity, it should be pretty stable.
Edit 2: This is why you prioritize your whole backlog, not just the current sprint. For the chance you end up with 100% completion. No use scheduling > 100%. IMO that just lends to the problem I mentioned of the stretch goal becoming the real goal.
Does it make sense to expect 100% completion? Maybe for something new our estimates are off by X% and future ones get more accurate. But then there's unplanned tasks/work from infrastructure issues or a high priority issue from upper management, or some other group.
So then the idea is - well, "fix" the other unplanned work by adding more process to those other groups...
BUT then overall the business changes anyway.
conclusion - the point of all this is:
1 - we create an illusory sense of control so the business can feel good about it
2 - so at least we don't have to be overwhelmed by an infinite todo list and can end each day with some sense of work/life balance
If you're a good Scrum Master, the goal is to get as close to 100% plus or minus BUT never as a punitive thing. If you miss the target that shouldn't mean your team failed, that should mean that the velocity was wrong and will be reflected in the velocity for the next Sprint.
I personally think forcing the team to 100% or punishing them for not hitting 100% is extremely toxic.
For me, bugs are 0 story points, and misestimated tickets are never re-estimated. If you re-estimate or adjust a ticket you are messing up velocity. Velocity when done right has a built in allowance for bugs and misestimates. It takes discipline.
Eventually, since story points per Sprint is based on a measured velocity, I've found you end up in a natural flow where you hit 100% without trying.
The one part where it gets tricky is the burn down/up chart when used as a way to tell the team to speed up vs just an estimation tool.
Also, that gets to one of the issues with agile, is that what the velocity says can be done may be less than what the stake holder wants and it takes a very strong account manager to be able to explain that rather than agreeing to the unrealistic.
If it is following a structure specified outside the working organization, it is not Agile, but instead the exact thing that Agile was explicitly a reaction against.
> Mostly because every single sprint becomes so derailed by "urgent" outside requirements that any sort of cohesion and planning goes out the window.
An approach that puts following a plan over responding to change is...not Agile.
> Then you have clients who won't pay for the planning and retrospective time.
Why does your contract not define what is a billable hour and charge an appropriate rate for the time?
> I think my record is 4 consecutive Sprints before things went completely off process.
If you aren't adapting your process continuously (or, rather evaluating it continuously and adapting as needed), you are giving process a priority over the concrete team (in the broad sense, including the customer) and set of challenges faced that is exactly what the first value statement in the Agile Manifesto is about not doing.
Good luck telling the client that their P0 ticket will need to wait until next sprint. Or more accurately: tell the product owner or account manager to tell the client. Which in my experience often results in them caving to the client demands.
Then you have clients who won't pay for the planning and retrospective time.
I think my record is 4 consecutive Sprints before things went completely off process. I just gave up.