1. Clickbait heading
2. Lots of strawman arguments
3. Punchline: Don't be stupid (implicitly assumed you are). Do it my way instead!
4. Success!
51–60 of 298 posts
1. Clickbait heading
2. Lots of strawman arguments
3. Punchline: Don't be stupid (implicitly assumed you are). Do it my way instead!
4. Success!
I added up all of the time we were spending in Scrum-related activities at a recent job. The company hired a lot of project and program managers who were pulling everyone into everyone meeting. I presented the number of hours (meetings multiplied by engineering participants) to our VP and he insisted I must be wrong. He insisted there was no possible way we could be spending that much time doing Scrum things and that…
> everyone meeting
This is one of the things I've added to me repertoire when I interview with teams: I always ask how often they meet and how they structure their meetings. Big red flag is there is a daily all hands (yes, I've seen this in a 16 person startup)I think it's emblematic of a few things about the founder/cofounder/lead: 1) they are an egomaniac and just needs to see everyone reporting in, 2) they don't trust their teams because they need to have daily all-hands status updates, 3) they're not connected to their teams' work; there is no visibility into what's getting shipped, 4) there's a strong correlation with micromanagement.
Learned this through a few mistakes joining teams where the founder/lead insisted on frequent all-hands standups (sometimes lasting 45-60 minutes to get through all of the teams reporting in).
I added up all of the time we were spending in Scrum-related activities at a recent job. The company hired a lot of project and program managers who were pulling everyone into everyone meeting. I presented the number of hours (meetings multiplied by engineering participants) to our VP and he insisted I must be wrong. He insisted there was no possible way we could be spending that much time doing Scrum things and that…
The amount of time lost to doing Scrum things was so out of control that some people had fewer than 3-4 hours per day to actually work. If the aggregate of the sprint planning, backlog refinement, retro and dailies is more than 10% of the total time (eg 1 full day out of a 10 day sprint) for most of the team then something bizarre is going on. If the everyone is losing 50% of their time to agile things then your proc…
Essentially every problem ascribed to scrum is its departure from this origin story.
Scrum is about making each team work better, but somehow it turned into the same weird top-down imposed structure that it was supposed to replace. 2 week sprints are mandatory for all teams? They all have to start and stop on the same day? And you can use any story point system you want as long as they neatly summarize into these t-shirt sizes?
There is little resemblance between the agile manifesto and what people are pretending to do today.
Earlier quoted context omitted.
The far biggest time sink is not what you logged though, but how you need to pad estimates and delay work to please the Scrum Lords. Like, the burndown chart has to be nice and steadely go to zero. There is no way to do that without decoupling reported hours and estimated hours from actual hours. Or points. It doesn't matter which.
"POINTS AREN'T TIME! THEY'RE EFFORT AND/OR COMPLEXITY!" I've been routinely told. Yet... low complexity stuff was expected to take less time, even if it was high effort. All 'in my experience' of course. Changing 95 files because someone didn't want to centralize some value in a method call last year (YAGNI!) is now high effort, even if low complexity. Then... "that's too many files in a PR! break it up! no one can r…
I added up all of the time we were spending in Scrum-related activities at a recent job. The company hired a lot of project and program managers who were pulling everyone into everyone meeting. I presented the number of hours (meetings multiplied by engineering participants) to our VP and he insisted I must be wrong. He insisted there was no possible way we could be spending that much time doing Scrum things and that…
I added up all of the time we were spending in Scrum-related activities at a recent job. The company hired a lot of project and program managers who were pulling everyone into everyone meeting. I presented the number of hours (meetings multiplied by engineering participants) to our VP and he insisted I must be wrong. He insisted there was no possible way we could be spending that much time doing Scrum things and that…
> the Scrum proponents will rush in and tell me that we were doing it wrong The "no true scrumsman" fallacy at work.
The problem, like everything these days, is corporatism. Things have been added to the old development model to create positions for knowledgeless managers to do nothing and make money. Agile means fast without preparation. That name no longer reflects the model.
These days, businesses have become so ritualistic to maintain power structure that they're inefficient, and morale is low. It gets to an unsustainable point and fails, meaning mass layoffs and restructuring, or the organization itself going down.
Is it because everyone is an idiot (e.g. management)? Or for some nefarious reason? Or maybe it isn't actually that bad?
On one project I was on, there was a contractor company billing millions per year to create a React admin tool frontend. Many developers involved, Scrum master full-time, and so on. Tickets were created for small parts of features, of course not considering anything more than 2 weeks ahead due to agility, then later other tickets would be created for the next phase of the feature so everything that had been done so far had to be thrown away as it was wrong (great for billable hours), etc.
The person on the customer's side managing this didn't really know what they wanted, so was happy to be told that, due to agility, they wouldn't have to specify anything more than two weeks ahead. A big decision can't be wrong if you aren't allowed to make big decisions! Can't get fired for decisions being wrong if you aren't allowed to make them.
So everyone won out of this situation really.
I don't know if there would have been a better way to manage this project. But I can see what everyone got out of it.
I've seen it suck even worse when trying to manage large X-Ops organizations. Something about the work, let's call it DevOps for the sake of simplicity, simply does not seem to lend itself well to the scrum methodology. Often priorities will shift rapidly even during the course of 1 working day, issues are vaguely defined and poorly scoped by nature (AZ1 cannot reach AZ2, plz fix ASAP), and the work is extraordinaril…
For those not in the know, "DevOps Days" was the conference that intended to deliver Agile to Systems Administration. The job title that was supposed to come from it was Agile Systems Administrator...
Alas, people got the conference conflated with the "10+ Deploys a day" talk from Flickr which merged ops and dev, and a mythology was born where everyone has their own interpretation of what devops means. :)