Does scrum ruin great engineers or are you doing it wrong? • Hacker News Board

Re: Does scrum ruin great engineers or are you doing it wrong?

#181

Post by mindcrime » Tue, Jun 30, 2020, 2:12 PM UTC

JoeAltmaier wrote: post #175

xtracto wrote: post #174

Earlier quoted context omitted.

I disagree with this sentiment, well at least I disagree that it is SCRUM's fault. I think this is a problem that resides higher up. I have been in teams that to take the time to solve technical debt and even generate technical wealth. The best approach that has worked for me is to divide the development available time per sprint in: 33% new product features, 33% existing product maintenance, 30% Solve Technical debt…

Hm. That sounds like a process issue. Which is what SCRUM etc are part of. So its not process, but changing process will fix it? SCRUM + technical debt management is the cure? Then SCRUM was missing something. I put the blame squarely on the process, whether its SCRUM or whatever.

Then SCRUM was missing something.

Scrum is missing a LOT of things, because it's very specifically intended to not be highly prescriptive. The whole idea is to iterate, use empirical feedback, and evolve your process to match your context.

Right near the beginning of the Scrum Guide it reads

Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.

Re: Does scrum ruin great engineers or are you doing it wrong?

#182

Post by mindcrime » Tue, Jun 30, 2020, 2:16 PM UTC

MattGaiser wrote: post #47

mrich wrote: post #44

As a manager you should think hard about what aspects of scrum are important to you and where you can let loose. This will heavily depend on the makeup of your team - how many experienced developers are there who don't need hand holding? How many of them will still deliver without some oversight? How many of them can mentor? How many inexperienced people do you have, how many will be onboarded in the next year? Thing…

> what aspects of scrum are important to you and where you can let loose. Scrum explicitly does not permit that. A criticism that didn't make it into that answer. https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum...

Two thoughts:

1. There's a lot of stuff that is often thought of as "part of Scrum" that really isn't. To the extent that the parent post you're replying to is referring to these things, then he/she is spot on. Things like Jira tickets, story points, planning poker, velocity, two week sprints, yadda yadda yadda.

2. Scrum™ doesn't permit you to do certain things... while truly saying you are doing Scrum™. But nobody has any real authority to mandate that you do Scrum™ to the letter, as opposed to an in-house "little-s scrum" version. And if that is what works better for you, you should do it. The goal is delivering working software, not adherence to the Scrum Guide for its own sake.

Re: Does scrum ruin great engineers or are you doing it wrong?

#183

Post by sergeykish » Tue, Jun 30, 2020, 2:17 PM UTC

danjac wrote: post #163

sergeykish wrote: post #159

Earlier quoted context omitted.

Look, I've had good experience with SCRUM team. Later I've been searching for work, "SCRUM", interesting, interview, what? PM? Another place, PM? Yet another... I have not found. They would not tell that it is not SCRUM before interview. And oh, they failed so miserably, I knew how it works but couldn't do anything. It is regress. So often it is PM who destroys project. I've seen good PMs. Two. Great guys. Great mana…

That's just it though: the fact that Scrum only works given this perfect "no management" ideal. It might work as a lightweight set of guide-rails in a self-motivated, experienced team which has 100% hands-off trust from management, but I'd argue that in that perfect-unicorn case Scrum is not the key to success but rather the fact that you have a good team and good management. In practice - as you are finding - this c…

Yes, but not works but is. Scrum requires trust and autonomy. Otherwise it is a set of non applicable tools, jumping with parachute under water. I argue Scrum with PM is oxymoron, like round square. I know it is rare, earlier it was easier to find.

Why discussion is about Scrum, not Scrum tools application and awful project management? The language is subverted, why do you help it?

Re: Does scrum ruin great engineers or are you doing it wrong?

#184

Post by mindcrime » Tue, Jun 30, 2020, 2:19 PM UTC

Yhippa wrote: post #7

How about letting developers pick or come up with their preferred way of working instead of mandating Scrum?

Scrum prescribes very little. What parts would you want to change?

Re: Does scrum ruin great engineers or are you doing it wrong?

#185

Post by mindcrime » Tue, Jun 30, 2020, 2:24 PM UTC

JoeAltmaier wrote: post #178

mindcrime wrote: post #176

Earlier quoted context omitted.

Scrum as defined in The Scrums Guide is a very specifically defined process with a few degrees of freedom, not a process design framework. Scrum as defined in the Scrum Guide prescribes very little. It's not much more than "Have a development team, a scrum master, and a product owner, have a product backlog, have developers plan their work, and work in time-boxed increments." Nearly every other aspect of how work get…

They are certainly part of Scrum-master training. They're a widespread practice. At this point, they can be grouped as 'part of Scrum' with fair confidence, in any implementation you can point to. Resorting to definitions is not helpful, when you work in a dysfunctional organization, and instituting Scrum was the root of the disfunction.

They are certainly part of Scrum-master training.

I am certified as a Professional Scrummaster, and none of those things were taught as part of any training I went through, nor were they mentioned on the certification test.

Referring to definitions is useful, when many people are misunderstanding the definition. If anything, we should be screaming from the hilltops "For the love of FSM, go read the Scrum Guide, and the Agile Manifesto, and show your managers and shitty Scrummasters what they're doing wrong." If we, as developers, are not willing to draw a line in the sand and take a stand sometimes, then what right do we have to complain? And if management won't listen to us on this, they aren't going to listen to us on anything else and we're back to "toxic management is the problem, not scrum."

Re: Does scrum ruin great engineers or are you doing it wrong?

#186

Post by JoeAltmaier » Tue, Jun 30, 2020, 2:46 PM UTC

mindcrime wrote: post #185

JoeAltmaier wrote: post #178

Earlier quoted context omitted.

They are certainly part of Scrum-master training. They're a widespread practice. At this point, they can be grouped as 'part of Scrum' with fair confidence, in any implementation you can point to. Resorting to definitions is not helpful, when you work in a dysfunctional organization, and instituting Scrum was the root of the disfunction.

They are certainly part of Scrum-master training. I am certified as a Professional Scrummaster, and none of those things were taught as part of any training I went through, nor were they mentioned on the certification test. Referring to definitions is useful, when many people are misunderstanding the definition. If anything, we should be screaming from the hilltops "For the love of FSM, go read the Scrum Guide, and t…

Or, not do Scrum. Do another process, like having an experienced team that respects the other team members to plan their time and prioritize tasks, with good communications between members of the team.

Looking at 'scrum master certification test questions' online I don't see anything about technical debt, variable-length time boxes, re-prioritizing work during a sprint etc.

A real and reasonable criticism of Scrum or Agile is, the structure is not helpful to the actual work. Sure, making a list of tasks is quite useful. But the time-boxing and task atomizing can dissect the work to the point of dysfunction.

If nobody is doing Scrum right, we're right on the edge of a No True Scotsman argument.

Re: Does scrum ruin great engineers or are you doing it wrong?

#187

Post by KSteffensen » Tue, Jun 30, 2020, 2:55 PM UTC

aliante wrote: post #88

jay_kyburz wrote: post #68

Earlier quoted context omitted.

>idea that ideal software development is just a continuous production of small improvements to the code. Many of us do believe this. Absolutely. >It is highly discrete when it comes to output, because it takes time and experimentation to come up with the correct way to approach a problem, but if you do it right, you save yourself an incredible amount of time. But on the flip side, if you get it wrong you waste an inc…

I am fine with the small improvements to code part, but I at least want an idea of where I am going. Small improvements to solve the problem? Sure. But I at least want an idea of what the entire problem is, not just the two weeks of problem shards I am given.

If Product Owner is not providing you with the bigger picture he is not doing his job. Product Owner should make sure the end result is crystal clear at all times.

Re: Does scrum ruin great engineers or are you doing it wrong?

#188

Post by KSteffensen » Tue, Jun 30, 2020, 3:09 PM UTC

sergeykish wrote: post #130

js8 wrote: post #34

We use Scrum at work and I have to say, I am pretty annoyed by it. I think it is fundamentally rooted in the idea that ideal software development is just a continuous production of small improvements to the code. And from this come all its micromanagement failure modes (which there are plenty). I think in reality, SW development done right is nothing like that. It is highly discrete when it comes to output, because i…

Agile builds on the premise that developers like to build. That we self organize our teams and don't like slackers. Bring transparency for business so it can trust us. Give estimates and accept priorities. Ship from time to time so all can see that process works. It is really easy to screw. I've seen far to many broken versions. Community building is harder than management. And for management there is no benefit besi…

You'd think products shipped on time as agreed with the customer was a benefit for management.

Re: Does scrum ruin great engineers or are you doing it wrong?

#189

Post by watwut » Tue, Jun 30, 2020, 3:41 PM UTC

mindcrime wrote: post #179

watwut wrote: post #110

Earlier quoted context omitted.

All the control and all the autonomy I would say. There is nothing I would be responsible for where I can make own decision and have them right or wrong. In the teams where I liked to work, I felt control over order in which I do tasks and general shape of something I was responsible for. So I could make my own decisions, decisions that would be really mine. So when there was mess or something was late, it was my fau…

So what process are you advocating for over scrum, that would restore this control and autonomy to you?

Compared to scrum, pretty much any other, quite honestly. The majority of teams I was in did not used named process and for the most part I was alright. Usually there were bigger tasks assigned to people or smaller areas of responsibilities.

For the record, I did not liked when leader had micromanagement/dictatorship tendencies either.

Re: Does scrum ruin great engineers or are you doing it wrong?

#190

Post by woutr_be » Tue, Jun 30, 2020, 3:41 PM UTC

xtracto wrote: post #168

woutr_be wrote: post #158

Earlier quoted context omitted.

The amount of hours our team has wasted on estimating, re-estimating, splitting up stories, simply to make our burn down chart look great is amazing. We would often be forced to split up stories the day before a sprint review, just so that the chart would look like things have progressed, while in reality nothing was completed. Our sprint planning sessions were a FULL DAY, yes, an entire 8 hours of planning. Because…

I have suffered through those sprint sessions of hell. What has worked for me is the following: - let the most sr tech person ("the architect ") refine the stories maybe with the PM. Then, the same person will point the stories. - The sprint planning is only for presenting the stories to devs and giving some minor adjustments to the points if necessary - The architect may deep dive with a dev for a certain task while…

Sadly because of the way our organisation works, the scrum master pretty much takes ownership of the whole process, he also sells agile to the business side. So if you go against what he says, the business will know that you’re a trouble maker, even if you had the best intentions.

Trust me, our team has tried, sadly the whole business wants to move to agile, and it’s shoved down your throat, wether you like it or not, or even regardless if it’s working for the team.

Eventually I gave up, the amount of energy wasted on these discussions is just not worth it. After a while you learn to say the right things, while also making sure you keep your technical freedom. Sometimes that meant not bringing up certain technical tasks, and overestimating others so that you have time for those other technical tasks.