Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scrum disempowers developers

lambdacambridge.com

Post reply on HN
Print view View original

291–300 of 382 posts

Re: Scrum disempowers developers

#291

Post by monksy »

termau wrote: post #202
nickelcitymario wrote: post #36

Like any and every business theory, Scrum has one or two core ideas that are awesome, but could be explained adequately in a paragraph or two. This does not sell books and consulting, so it evolved into a field of its own. The fact that there is so much B.S. in Scrum doesn't mean that it has nothing of value to offer, though. Here's what I get out of it: 1. Sprints are a better way to organize than Waterfalls. I've e…

Sprints are a shit idea and need to die a horrible death. The number of times we've had to break up some functional requirements for no reason other than to meet some stupid concept isn't funny ultimately it's a waste of time in itself

That or having to estimate work based on your sprint. This is a 130 pointed task? Oh we only go up to 8.

Re: Scrum disempowers developers

#292

Post by s73v3r_ »

geezerjay wrote: post #188
specialist wrote: post #78

Earlier quoted context omitted.

You're describing having a well defined goal, setting a critical path, and then regularly updating your progress. What we gray beards used to call "project management".

> You're describing having a well defined goal, setting a critical path, and then regularly updating your progress. What we gray beards used to call "project management". That's not true at all. The whole point of organizing projects around scrums is precisely that there is no well defined goal nor can one exist. What exists are the client's needs, and those needs do and will change frequently and radically as projec…

"The whole point of organizing projects around scrums is precisely that there is no well defined goal nor can one exist. What exists are the client's needs, and those needs do and will change frequently and radically as projects move on."

I don't feel this is true at all. The issue is that most clients aren't willing to put in the time or effort to actually see what their needs are.

Re: Scrum disempowers developers

#293

Post by yebyen »

alistairSH wrote: post #273
yebyen wrote: post #149

Earlier quoted context omitted.

> What is driving the turn-over? Are team-members being moved elsewhere "72%" is really misleading... from the original team of 2 developers and one PM/Scrum-Master, the Scrum-Master was promoted to a newly formed team, and the other developer is still with us, but in a mostly consulting-only capacity, as she is focused on other projects in our team. Nobody is quitting out of frustration. (Not yet anyway!) We've sinc…

overridden by the PM's boss Yeah, lack of buy-in from senior management is probably the biggest single problem with scrum, any other agile framework, and probably even non-agile frameworks. Interesting that you're in higher ed. I am as well, thought it sounds like you're at a college/university and I'm at a software company selling into that market.

That's correct! And as much as I may gripe about these issues, we're consistently ranked as one of the best places to work in tech. I believe that's specifically with respect to employee happiness. (Go figure! LOL)

Just goes to show that wherever you look, you're going to find problems.

Re: Scrum disempowers developers

#294

Post by s73v3r_ »

funkymike wrote: post #193
nickelcitymario wrote: post #170

Earlier quoted context omitted.

That's... actually pretty accurate? Dang.

So it becomes this? * Get feedback often from the business owners * Get feedback often from the developers * Get feedback often from the users

And act on that feedback.

Re: Scrum disempowers developers

#295

Post by s73v3r_ »

srtjstjsj wrote: post #210
termau wrote: post #202

Earlier quoted context omitted.

Sprints are a shit idea and need to die a horrible death. The number of times we've had to break up some functional requirements for no reason other than to meet some stupid concept isn't funny ultimately it's a waste of time in itself

Are you saying you have projects that show 0 progress of any kind after 1 month, but still succeed later? What is happening in that first month?

Research? Experimentation? Foundations?

Re: Scrum disempowers developers

#296

Post by s73v3r_ »

ggregoire wrote: post #263
ownagefool wrote: post #239

Earlier quoted context omitted.

I can probably agree that sprints are usually more realistic than old school waterfall (arguably it depends, like all things) but why do we feel the need to perpetually sprint? A simple kanban board seems to give all the same benefits without the constant pressure and weekly death march to meet the end of sprint commitments.

Because a simple kanban doesn't have any scope/goal, it's just a disorganized TODO list. A sprint/milestone is a way to set goals for the next 2-4 weeks. At the end of the iteration, you redefine new goals according to what would bring the most values to the clients at this new moment T. If the sprint is not finished, well it's not a big deal. You move the tasks back to the backlog, or in the next sprint, or delete t…

"Because a simple kanban doesn't have any scope/goal, it's just a disorganized TODO list."

Not everything has to be encapsulated in the TODO list. I mean, a Jira backlog is also just a TODO list.

Re: Scrum disempowers developers

#297

Post by dgreensp »

alistairSH wrote: post #274
dgreensp wrote: post #187

Earlier quoted context omitted.

Does Scrum itself empower individual members of the development team? Saying it’s on the developers not to be “mindless drones” and the managers to not be “bad managers” may be true but doesn’t really refute the article’s point. Maybe you have Scrum disempowering developers and (at the best companies) other forces, including other practices and processes, empowering them. For example, Scrum says responsibility for op…

not having officially recognized responsibilities I feel like that's a bit of an overstatement. While scrum advocates for shared responsibility, it doesn't demand no-titles, no-roles, or no-passions. It's all about ensuring the entire team possesses 'T' shaped skills. Depth and expertise in some areas, but still generally knowledgable across all areas. My test engineer doesn't write much code, but in a pinch, she can…

Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;

Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis

Maybe T-shaped people are required to make Scrum work, or vice versa? Like if you are running a restaurant and your company process says “there is no distinction between waiters and chefs,” then your waiters need to be decent cooks, and your chefs need to be personable and presentable. “Passion” can be a liability in this environment, for example being passionate about great food or great service. The lack of specialization doesn’t seem directly related to how to do great work, or be really happy at work.

Re: Scrum disempowers developers

#298

Post by s73v3r_ »

nradov wrote: post #268
ownagefool wrote: post #239

Earlier quoted context omitted.

I can probably agree that sprints are usually more realistic than old school waterfall (arguably it depends, like all things) but why do we feel the need to perpetually sprint? A simple kanban board seems to give all the same benefits without the constant pressure and weekly death march to meet the end of sprint commitments.

The business benefit of having a longer planning horizon is that it enables making some commitments outside the agile team. In the real world sometimes that's necessary. A sprint cadence also helps ensure that the team does real retrospectives rather than putting those off. But certainly Kanban can work as well or better in some environments. Pick what works for the circumstances.

I definitely feel that once something has gone into "maintenance mode", where most of the work of making the project exist is done, then Kanban can be much better for organizing work.

Re: Scrum disempowers developers

#299

Post by fwip »

srtjstjsj wrote: post #238
fwip wrote: post #234

Earlier quoted context omitted.

About a year ago, we went from no-process to "agile?? I guess?" And let me tell you, a badly implemented process is a great way to turn self-driven developers into cogs that just do what's in Jira. Getting your tech decisions questioned by non-tech scrum masters during standup, requirements that don't arrive till midsprint, inability to deploy anything that hasn't been specifically inspected by the sole overworked pr…

> questioned by non-tech scrum masters during standup, Standup is for raising issues, not answering questions. Standup rules says to defer discussions to a separate meeting. > requirements that don't arrive till midsprint, Not scrum-specific, and scrum requires either (a) not doing that, or (b) negotiating a trade to remove another requirement. > inability to deploy anything that hasn't been specifically inspected by…

Yes, these are all examples of process done badly.

Re: Scrum disempowers developers

#300

Post by squeaky-clean »

ggregoire wrote: post #271
nickelcitymario wrote: post #36

Like any and every business theory, Scrum has one or two core ideas that are awesome, but could be explained adequately in a paragraph or two. This does not sell books and consulting, so it evolved into a field of its own. The fact that there is so much B.S. in Scrum doesn't mean that it has nothing of value to offer, though. Here's what I get out of it: 1. Sprints are a better way to organize than Waterfalls. I've e…

I completely agree. I don't get why people try to strictly follow the methodology (and then complain about it) instead of just taking the core of it and apply what work for them and their company. I've a SCRUM master certification and still, I follow only what's good for us. It's totally fine for me to add a task in a current sprint. If you care about finishing the sprint, you just move a task of same points back in…

My best experience with Scrum was with a team that was willing to completely overhaul our weekly process if we needed to. We finally settled on a structure pretty different from the general recommendations, the most significant being we had no daily standups. They felt kind of useless, one guy on the team particularly hated them and pushed for us to do a sprint with no standups. So we tried it out once and kept it that way permanently, turns out our team really didn't benefit from them.

When the rest of the company saw our productivity, they moved every other team over to Scrum, hired a Scrum coach, etc... And it didn't work because they were extremely strict about the "process" and any changes to the process were like arguing against the bible. They even made our team begin doing daily standups every morning again.

I'm not certified or anything but the entire point of Scrum to me is that you frequently re-evaluate your situation and team and adapt to that. Everything else is just a good baseline to start with.

Post reply on HN