Agile Lite: Agile without all the burnout

Sorry, there is no "faster" button. The only lever you have is cutting scope as you go. Fixed scope just makes no sense. Otherwise you get one of three outcomes: 1. We underestimated how much we can get done. People now start gold playing stuff and wasting time that would be better spent on future backlog items. 2. You estimated just right and are done Friday at 5pm. Obviously this doesn't happen frequently. 3. You overestimate and now something's gotta give. People will start cutting corners or putting in over hours as a punishment for being bad at estimation. This is not sustainable.

We need to get away from the fixed scope mentality with which Scrum had poisened the Agile pool. If we cannot trust or developers to do the best work they can and wanting to be proud of their work, the organization has entirely different problems.

It seems like you could solve this problem in an even more dev-friendly way by sticking to one of the most fundamental principles in scrum (and possibly others): Don't schedule 100% of your developers' time, and definitely don't fill them up to 100% on coding work. Not even close. Devs are supposed to work at a sustainable pace.

A sustainable pace leaves plenty of time for kicking your feet up on the desk in order to think about things. It leaves plenty of time for chatting with one's teammates to make sure ideas are fully baked before implementing them. It leaves plenty of time for trying out new ideas.

And, importantly, it leaves the time for doing this relatively unstructured. Because the dev team is a bunch of working professionals who should be free (and trusted) to figure out for themselves when they need to take a pause from cranking through tickets in order to do other stuff. A "3 weeks on, 1 week off" approach doesn't get you this.

I think that the spot where the car always ends up upside down in a ditch on agile implementations is a misunderstanding of the basic idea behind velocity. It isn't a KPI that you're supposed to maximize. It's a feedback mechanism that the product owner uses to manage the pacing of some of their own work, in order to make sure that the pipeline neither empties out nor becomes jammed full of work.

If the PO is doing that job correctly, then they would be making tough decisions about what is and is not reasonably doable in a given timeframe, and providing backpressure to stakeholders when they're asking for too much. If they're instead accepting every single feature request, and dealing with the resulting backlog logjam by continually pressuring the dev team to work faster and faster (and more and more sloppily), then, no sense in mincing words about it, they're doing a bad job as a product manager. And the dev team is well within their rights to push back against them on that.

Which, incidentally, is what the orthodox Scrum formulation is trying to do when it disallows the PO from deciding how many items (or story points, or whatever) to pull into the sprint. That's supposed to be based solely on the dev team's own opinion of what's a reasonable amount of work to take on.

This is another time to ask uncomfortable questions. Why are issues coming up in the middle of the iteration that "take higher priority"? Why can't they wait?

Is it a production bug? If it is, can it wait? Just because it's a production bug doesn't mean it must be addressed outside the normal iteration cycle. Criticality should matter.

If it's not a production bug...

Is it a missed critical requirement? WHY??? How did the entire team miss something that must be done right now? That's a major process failure.

If it's not a missed critical requirement...

Is it someone with great power just disrupting your iterations for their pet project? Do you have multiple customers who are competing for your team as a resource, and not hashing priorities out together in iteration planning?

Following from that...

Are they directly in your chain of command? Is it your superior changing horses in midstream, or your customer? Because you can tell customers no. Even if they scream and shout and say they're gonna tell Mom. The customer is not always right. Learn to say no.

And if you still feel like you have no authority and no control over your work...

Quit.

There are three parts involved in any project. The product, the process and the people. As it currently stands scrum does not make any provision to address the people. Hence management uses this void to turn scrum into scrum butt and turn the devs into jira ticket processing machines which are pushed until they break.

Until the big names in the industry accept that error and address that, I guess there will be no hope for most people doing dev work.

Most companies on themselves don't have any incentive to address this fact because the commoditization of programmers benefits them and because they aren't in a position to understand the long term consequences of this (or don't care)

25% overhead is a little too much