Why I'm not a big fan of Scrum • Hacker News Board

Re: Why I'm not a big fan of Scrum

#251

Post by JoeAltmaier » Mon, Aug 08, 2016, 4:47 PM UTC

vpeters25 wrote: post #235

JoeAltmaier wrote: post #179

Earlier quoted context omitted.

For some engineering tasks, the work and the planning are almost the same thing. Once you've explored the problem, the code is the small part. When asked to estimate, the answer is "I'll let you know when I'm getting into it". Then you're made to do a 'spike', which is indistinguishable from doing the task. Except do it in a day now. So the Engineer thrashes around trying to figure it all out in a day, and comes up w…

In agile, the estimates should be decided by consensus of the whole team. Requiring a single engineer to come up with an estimate is a smell. Here is a quick 4 step planning meeting process based on planning poker: 1. Pick story from backlog, explain in a couple minutes what do you think would take to implement it. 2. Team members pick an estimate of the effort. 3. If there is consensus, note estimate on story, pick…

And that's where the 'incremental tasks with no architecture' part comes in. When the scheduler needs rewritten to support whatever robustness; when the server feeds need to be redundant; maybe only 1 team member has any real idea what it takes. Coding isn't always about putting up another web widget or making another database entry.

Re: Why I'm not a big fan of Scrum

#252

Post by specialist » Mon, Aug 08, 2016, 4:49 PM UTC

UK-AL wrote: post #189

specialist wrote: post #126

Earlier quoted context omitted.

"Scrum is intended to be the straightest line towards measuring your real progress on a project, and not much else." More like wandering in the desert, hoping you find the promised land. Been thru scrum master training 3 times, been on many "agile" teams. I've never heard this rationalization. Rather, a common justification for "agile" was you always have a working product. Which might be nice if things worked out th…

Considering failure rate of PMI led projects is even higher then agile projects for software. I really wouldn't hold that up that as the way to go.

PMI (critical path) != waterfall. But then that's also said of "agile", which too often devolve to waterfall.

Project management is risk mitigation. In my experience, most "agile" projects have been risk amplifiers. Ironic.

Re: Why I'm not a big fan of Scrum

#253

Post by joe8756438 » Mon, Aug 08, 2016, 4:49 PM UTC

tootie wrote: post #232

joe8756438 wrote: post #142

I disagree with most of the major criticisms here. I think it is a valid description of an experience using scrum half-heartedly, but not an argument against its purpose or value. Points, for example, the argument is based on the premise that teams are obsessed with points. What if the teams use points as a framework to discuss complexity? I have worked in scrum groups where if something was given a large point value…

This is my experience also. Points are complexity and high complexity tasks are most definitely to be addressed by breaking down stories. Dependencies are also easily addressed by setting a Definition of Ready. Don't accept a story if the dependencies aren't met (be that APIs, environments, designs, whatever). Simple. Planning/grooming we do in one hour. You good story writers is all. I once had a planning last 12 ho…

Exactly. A good agile, and by extension SCRUM, process allows the developers to influence how things get done. If the way stories are written are leading the team to write unmaintainable code, change the way the stories are written. Or talk about why the problem exists in the first place and take action to fix it.

Again, it all comes down to communication. If nobody wants to talk to each other, SCRUM is not going to help.

As with all of these posts, they're extremely lacking in alternatives. Of course SCRUM won't work for every team, or even every project for the same team. But it provides a way for the team to evaluate and adjust how to best accomplish their goals in a straightforward and (if done right) low friction way.

I think it's taken for granted how much effort is alleviated by adopting SCRUM. Just think how difficult it would be to develop an alternative process for every team, every project, every new person to join one of those teams or projects. Everyone has their own way of doing things, standardizing on a few universal goals aint a bad thing.

Re: Why I'm not a big fan of Scrum

#254

Post by JoeAltmaier » Mon, Aug 08, 2016, 4:50 PM UTC

tootie wrote: post #225

JoeAltmaier wrote: post #184

Earlier quoted context omitted.

Except most of the 'stakeholders' don't give a fig for what the Engineers value. Like technical debt, robustness of the solutions, relieving bottlenecks both in code and in development. So Engineers get herded into little incremental projects that management can swallow as having 'business value'. And the herd marches toward the cliff as the code base wanders around the solution space but never gets fundamentally sou…

No process will solve the lack of understanding. Also, this goes both ways since engineers frequently don't give a fig about business priorities. Sometimes your refactor isn't really that valuable and is costing the company money. If you have a culture of trust between departments, you should be able to have honest conversations.

That's exactly the call that gets made again and again, by managers. They rarely value code quality; so easy to dismiss with "that's just a refactor". Converse all you want. Business folk are not going to believe that Engineering isn't foolish and just "costing the company money".

Re: Why I'm not a big fan of Scrum

#255

Post by Udik » Mon, Aug 08, 2016, 4:51 PM UTC

crdoconnor wrote: post #220

Udik wrote: post #163

Earlier quoted context omitted.

I often have the impression that the term "technical debt" is just an euphemism to avoid admitting that someone in the team has produced poorly thought and poorly written code. I'm not sure I ever found myself in the position of writing bad code just for the sake of speed - I surely wrote tons of bad code because I didn't know how to do it better, or because I didn't have the requirements clear from the start, or bec…

>I often have the impression that the term "technical debt" is just an euphemism to avoid admitting that someone in the team has produced poorly thought and poorly written code. It's absolutely not that. Technical debt is a natural by-product of working even with the best coders. There's nobody out there who doesn't create it. Better coders just produce it more slowly and clean it up more often. >I'm not sure I ever…

Of course. Some developers (or product owners, architects, managers) generate technical debt slower, some other generate it faster. Some generate a substantial amount of it for a task in which others would generate very little - in the same time frame. Then why don't we call it lack of skills? Sounds the same to me.

Re: Why I'm not a big fan of Scrum

#256

Post by gmarx » Mon, Aug 08, 2016, 4:55 PM UTC

Udik wrote: post #163

crdoconnor wrote: post #63

Earlier quoted context omitted.

One amendment I always wanted to make was to have a "technical debt dial". You could stick it on the wall next to the scrum board. The debt dial should be from 0% (spend all the time refactoring) to 100% (spend zero time refactoring, get it out at all costs). Management should have complete control over the dial. Developers should have control over what kind of refactoring they do (ideally the retro should have a que…

I often have the impression that the term "technical debt" is just an euphemism to avoid admitting that someone in the team has produced poorly thought and poorly written code. I'm not sure I ever found myself in the position of writing bad code just for the sake of speed - I surely wrote tons of bad code because I didn't know how to do it better, or because I didn't have the requirements clear from the start, or bec…

I disagree. Even among those who routinely write good code (all of us in our own minds) the schedule tends to pressure you to solve the problem before you, the one in the story, without checking if anyone else has solved similar problems already. What tends to happen is you write your own solution instead of finding the similar solution and generalizing it. Then, after a year you have have a dozen related tasks performed in slightly different ways. If the underlying (e.g.) data structure change, now you need to alter each of the dozen different ways

Re: Why I'm not a big fan of Scrum

#257

Post by gmarx » Mon, Aug 08, 2016, 5:00 PM UTC

joe8756438 wrote: post #142

I disagree with most of the major criticisms here. I think it is a valid description of an experience using scrum half-heartedly, but not an argument against its purpose or value. Points, for example, the argument is based on the premise that teams are obsessed with points. What if the teams use points as a framework to discuss complexity? I have worked in scrum groups where if something was given a large point value…

Perhaps but this could be viewed as the "no true scotsman" thing. My main objections to Scrum are a) you need to shoehorn things into user stories that are not naturally expressed that way (as a user I would like all relevant data in the database associated with standard ontology?) b) In a special domain (healthcare) it requires good developers with some level of domain expertise and I find this rare c) (and this is a management issue) people think you can remove important aspects of the methodology (e.g. colocation of resources) and have it still work

Re: Why I'm not a big fan of Scrum

#258

Post by nilkn » Mon, Aug 08, 2016, 5:04 PM UTC

Udik wrote: post #246

nilkn wrote: post #187

Earlier quoted context omitted.

I have to disagree with this comment. Technical debt is sometimes the result of just one lone cowboy coder, but even then there's some responsibility across the team because that means his or her code passed all reviews, i.e., nobody took ownership for the overall team's code quality and vetoed the bad code. Time constraints can certainly be relevant too. It's not always an artificial shift of blame. For instance, ti…

but it presents problems months down the line when a new feature needs to be added or an existing one changed in a non-trivial way. I think I have yet to see any software to which this doesn't apply sooner or later. While the whole point of "technical debt" is that it is something you're supposed to knowingly acquire because of time constraints. You're basically saying "we knew it was wrong, but they forced us to do…

> And if I am under pressure by the management is because I spent time developing without understanding what I was doing; a better developer would have gotten it right at the first try, and there would be no technical debt.

While this reasoning is probably not technically wrong, I'm not sure if it's relevant to the real world.

You can always make an argument of form "there exists a developer who could have got this feature right on the first try, with very little time spent." This simply does not matter when you do not happen to have that developer on your team right at the moment. The nature of the work is that you will work on a variety of things, and you won't necessarily be the best in the world at every individual thing. You're inevitably going to encounter work that's challenging enough for you where you don't get it perfectly right on your first try.

> If the managers/ product owners didn't produce clear requirements, it's not a technical debt, it's a sloppy job on their part.

It's a sloppy job on their part, induced by time pressure, which produces technical debt. I feel like you're just playing with definitions here to avoid admitting that technical debt can come from poorly managed time pressure.

> if I realize I didn't know what I was doing, I always refactor the code.

All that tells me is that you've never been under a lot of time pressure. That's not a bad thing. It most likely means the management at your companies have been competent. But it doesn't mean that technical debt does not exist or cannot be induced from time pressure in other companies.

Re: Why I'm not a big fan of Scrum

#259

Post by crdoconnor » Mon, Aug 08, 2016, 5:07 PM UTC

Udik wrote: post #255

crdoconnor wrote: post #220

Earlier quoted context omitted.

>I often have the impression that the term "technical debt" is just an euphemism to avoid admitting that someone in the team has produced poorly thought and poorly written code. It's absolutely not that. Technical debt is a natural by-product of working even with the best coders. There's nobody out there who doesn't create it. Better coders just produce it more slowly and clean it up more often. >I'm not sure I ever…

Of course. Some developers (or product owners, architects, managers) generate technical debt slower, some other generate it faster. Some generate a substantial amount of it for a task in which others would generate very little - in the same time frame. Then why don't we call it lack of skills? Sounds the same to me.

Because the same developer with the same skills can often ramp up technical debt to get a feature out in half an hour instead of a day, and there aren't any developers who haven't felt the pressure to do exactly that.

Ramping up technical debt isn't always about speed, either. It's sometimes about risk - it's often less risky in the short term to copy and paste a block of code than it is to change a block of code and risk breaking something else.

Re: Why I'm not a big fan of Scrum

#260

Post by nawitus » Mon, Aug 08, 2016, 5:09 PM UTC

joe8756438 wrote: post #142

I disagree with most of the major criticisms here. I think it is a valid description of an experience using scrum half-heartedly, but not an argument against its purpose or value. Points, for example, the argument is based on the premise that teams are obsessed with points. What if the teams use points as a framework to discuss complexity? I have worked in scrum groups where if something was given a large point value…

> Long meeting times with the wrong people in the meeting? That's a managerial issue and has nothing to do with scrum.

If scrum tends to lead with long meeting times with the wrong people then scrum certainly should include safeguards against that. Otherwise we need "x+scrum" framework which includes these safeguards. I don't think scrum should fix every problem "in management", but "meeting management" should be a core scrum issue to deal with.