4 ms·
I've never been in an environment where Scrum was used to create real pressure. I've been in environments where it creates fake pressure. Standups where you ha
by NAHWheatCracker 4y ago
I've never been in an environment where Scrum was used to create real pressure.
I've been in environments where it creates fake pressure. Standups where you have to say something for fear that you'll be axed if you say nothing. Questions about whether a ticket is going to get done by Friday. I call these fake pressure because it becomes obvious that there is no teeth to them. People get away with doing nothing and making up a few sentences at standup. People say a ticket is going to be done, but it roles over through two or three sprints.
It's always been a sham for me. You can't point at the Agile Manifesto and say that we're focused on process over interactions. You can't point out that we need a Product Owner who is focused communicating the needs of real users. You can't point out that standups should be for the team's benefit and not status updates to project managers who are barely involved.
Still, I'm a firm believer that the Agile Manifesto makes some good points. I believe that there are elements of Scrum that are really beneficial if implement well. I believe all of it is subverted by management that wants a semblance of control/power. Most of the workers don't care whether it's subverted, they're just there to be paid while doing as little work as possible.
So, who's left to change it? A few righteous agitators? Who are they going to agitate? The managers who have control aren't going to give up the reins. The hoi polloi will ignore anything that takes extra effort.
Saying the scrum master needs to be accountable is true. Everyone should be accountable for something. However, there's simply no way for that to happen in many environments.
I've had scrum masters that were basically just required to gather status updates and report them back to the CTO. I've had contractor scrum masters that were hired because Scrum said they had to have that role but they ignored the part of Scrum that said there was a product owner role. I've had scrum masters that were just engineering managers who ignored their engineering manager roles to be the one who screen shared the Jira during standups, including one who was a Director of Engineering.
All of those scrum masters were installed by the people in power not to be held accountable for anything. Most of those scrum masters, like all the other workers, just want to get by with doing as little as possible while being paid.
- icedchai 4y agoI worked at a place that ran sham sprints all the time. If you couldn’t finish something, your ticket would get marked complete, and a new one opened to finish the work (“integrate [component]”) next sprint. This was so the points would be booked and the team stats wouldn’t look bad. I saw one ticket roll over for a good 2 or 3 months like this.
- praptak 4y agoSprints are bullshit, so people use this method to work around this. It's actually kanban implemented over Scrum. It's just too common for a task to turn into an "epic" mid-sprint. I only see value in sprints as regular checkpoints but the expectation that all tasks are finished after 2 weeks is just contrary to reality of software development in large organisations.
- bladelessninja2 4y agoWhat are you talking about is problem that you are committing to to much in sprint, thus, your velocity is inaccurate. If I can give you a piece of advice: not finished items should be marked as 0 work done and moved to next sprint, and thus it will affect your team's velocity in future sprints making you commit to less items, which should result in that eventually you will have real velocity of the team and you will know how much work you can complete in each iteration. Of course opposite is also true - with time you can get knowledge or improve codebase in such way that your velocity will go up.
- icedchai 4y agoI agree with you, but the "scrum masters" did not want to do that, as it would not "properly account" (their words) for any work done. There was a head bean counter that actually believed the numbers, and would count up all the points and track the completed vs planned. It would cause our stats to look bad if we achieved less work completed. Personally, I did not care about stats, I would rather improve our estimation process. I thought the whole thing was a gamified sham and left.
- bladelessninja2 4y agoIn my professional experience as developer I'm terribly disappointed with so called "scrum masters" dedicated for the job, the teams that I worked in that implemented scrum correctly were the teams where the team itself took the responsibility to do it right on themselves. ...and we come back to one of agile principles: "the best architectures, requirements, and designs emerge from self-organizing teams". I think the scrum itself says to not confuse the job title with the role and I believe that's what happening in many cases. But it all looks good on paper, we have scrum because we hired scrum master so management is happy whereas in reality it is not true - I saw it many times.