Any time I feel effective in pure scrum, I also feel like I'm an accountant for the mafia; all the bookkeeping is a fiction to keep the authorities happy, meanwhile something completely different is happening in the back room. There's amortizing refactoring across every feature in a module, and there's deep rationalization of why this refactor can plausibly be tied to this ticket.
It's a mixed bag. One thing refactoring is good for is getting past friction introduced by people who don't like a good idea. Early in my career I got a lot of "that will take too long" for features in the High Cost, High Value quadrant of the feature graph. A couple months of picking away at the accidental complexity and you can come back with a <6 week estimate instead of 4 months, and your proposal gets more consideration. I'm not saying 4 months is a reasonable estimate, I get why that causes concern, but refactoring can be so much more effective when you have long-term goals in mind. When you have a list of 'target of opportunity' features. When you can romance an epic into the code, instead of forcing it in.
I still get that pushback of course, but I'm more used to it and also sometimes don't ask questions I don't want the answer to. It's all subterfuge and puppet mastery. If I wanted to be an accountant or a lobbyist I wouldn't have enrolled in a CS degree at a semi-respectable institution.
Giant industrial corporation, giant projects with other giant corps as clients.
Process process process. SAFe Scrum.
Somehow I ended up in a team that started to care. Like, we, small individual team, had a agenda and a goal. We saw path to success for this mess of a giant project.
And we started to shadow work our way thought it.
At first myself and another senior guy. As a hobbit.
But it became prevalent for the team as a whole to do “prep work” on top of our tickets.
We self organize, self train.
Why? So we can move faster and actually deliver.
Our normal ticket we’re adjacent work. It’s not like we started 30 repo on the side.
Finally our scrum master caught on that. She went onboard.
We repurposed tickets like nobody’s business. Acceptance criteria was a mere indication, because the QA folks were on board as well.
Not to less us merge crap, QA is QA and you don’t go to prod with a buggy industrial system. That shit is dangerous:
but they knew where we were going and were fine with changing the AC if they see progress, and if the black market scrum master say we’re gonna have a black market ticket to fix it.
We delivered. It fucking worked.
My favorite part ? We were the “bad” team. The team without a cool project or a decent backlog. The cleanup crew.
We submarined Kanban into a similar project at a large, old, waterfall company. It was such a silent conspiracy that to my recollection we never mentioned Kanban out loud. Limited Work In Progress was as close as we got to uttering the name.
It's a mixed bag. One thing refactoring is good for is getting past friction introduced by people who don't like a good idea. Early in my career I got a lot of "that will take too long" for features in the High Cost, High Value quadrant of the feature graph. A couple months of picking away at the accidental complexity and you can come back with a <6 week estimate instead of 4 months, and your proposal gets more consideration. I'm not saying 4 months is a reasonable estimate, I get why that causes concern, but refactoring can be so much more effective when you have long-term goals in mind. When you have a list of 'target of opportunity' features. When you can romance an epic into the code, instead of forcing it in.
I still get that pushback of course, but I'm more used to it and also sometimes don't ask questions I don't want the answer to. It's all subterfuge and puppet mastery. If I wanted to be an accountant or a lobbyist I wouldn't have enrolled in a CS degree at a semi-respectable institution.