Scrum's Built-In 'Get Out of Jail Free Card' Against Criticism

Different paths for different styles of work. In my experience you have teams who can have a pulse with the incoming work, more often development, so being able to limit the disruption makes scrum easier to work with.

On the other hand, if you have a team who is going to be working on more "at the time" needs, Kanban lets the disruption get absorbed in real time while the team gets to focus on the WIP pipe. I've seen it used most successfully in teams that have smaller, more isolated tasks to deliver that are able to be isolated to the scope of the team. Intra-team coordination with Kanban is more difficult than scrum (but doable) as long as the working model is understood on all sides.

My preference is to operate more in a Kanban model but when working with other groups who operate with scrum you need to tweak things to integrate.

It also isn't a system that, once picked, you're stuck with. I had a team who did scrum for a few weeks, twice a year during organizational planning so we are kept in rhythm with the rest of the company. Once we had a good enough idea in how we were going to move forward, we switched to kanban to manage our work until the next Co. planning cycle.

There's no true Scotsman when it comes to planning and agile and you'll never find a definitive correct answer that can be broadly adopted. Being open to change to make it work with your org and the people you work with is going to get you closer than blindly following any strict dogma.

// ramble

My firm introduced Scrum in 2023 and it's so clearly about #2.

* The sector of the business I'm in is 90% about integration with third-party services. How many sprints does it take to walk through their certification process? Depends how many cycles the third-party wants, how fast they respond, etc. So we end up checking in tasks representing "2 weeks of work" that really mean nothing so the points can be made up.

* The long-established policy (pre-scrum) involves several phases (development, another developer reviews, QA, final review by project manager). Any one can be a bottleneck. So if Frank in QA has enough points for his sprint, Dev Steve probably can't take on any more tasks even if he has capacity.

* This also works on a time scale; you're often going to end up with "last Thursday of the sprint, there's nothing left in the queue, and we have to twiddle our thumbs or possibly start some experimenting on next sprint's work" -- it's hardly a smooth process of "just keep pulling tasks".

* The primary outcome of all the meetings is that they complain "we're delivering 80% of our estimate one sprint, and 115% the next sprint, how can we be more predictable?"

Bearing in mind the number of points have nothing to do with actual achievements and business value; a huge spec uplift on the #1 partner can end up as fewer points than just endless weeks of dragon-chasing for a partner that will never deliver a dime of revenue.

Combining the worst of both worlds is definitely a nutty thing to do! You need to use critical thinking and analysis when coming up with new processes. It's definitely possible to make use of the best of both worlds. Though you still need to synthesize and re-evaluate the whole.

Though two wrongs don't make a right, two rights can sometimes make a wrong when combined.