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

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

#281

Post by Udik » Mon, Aug 08, 2016, 5:59 PM UTC

crdoconnor wrote: post #266

Udik wrote: post #246

Earlier quoted context omitted.

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. This is possibly the most wrongheaded comment you've made. 1) There is no such thing as "no technical debt". It asymptotically trends to zero but never, ever gets there. If you think that you oe an…

Ok for your first point - although I'd argue that technical debt is something that usually asks to be repayed within months. A two year old technical debt is just an improvable software - that is, it didn't yet show problems serious enough as to call for a refactor at unchanged requirements.

As for your second point, what should I do? Try to get it wrong? To get it working how? We're not talking of premature optimization here, we're talking about understanding the requirements, understanding the tools, understanding the big picture, understanding your time constraints, and pulling out the best job you can.

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

#282

Post by pjbster » Mon, Aug 08, 2016, 5:59 PM UTC

After working in Scrum for over a year, I find myself in violent agreement with every point in the article.

For me, Scrum has always been nothing more than an “Agile Bootstrap”. The core idea within it is very simple: try something and examine the results. Stick with what works and try alternatives for what doesn’t. Repeat. And, above all, learn.

So Scrum starts you off with a list of practices to get going with. The whole litany of backlogs, story points, sprints, daily stand ups and retrospectives is nothing more than a vocabulary - a pattern language for stakeholders. It’s got pros and cons - a good way to bring people together but it needs to be recognised as a crutch and ditched quickly before the team comes to treat it as an article of faith to be defended at all costs.

And this is where so many agile coaches fail in my (limited) experience. When I was undergoing scrum training, it was hugely disappointing to hear colleagues asking questions of the trainer along the lines of “Can a scrum master multi-task among teams like an anaesthetist in a hospital?”. Or “What does Scrum advocate when a production incident requires someone in the team to drop out and assist?”. Or “Can we have scrums of scrums?”.

The answer in every case is the same: try something - anything. See how it goes and decide whether to apply that approach again in future.

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

#283

Post by xorblurb » Mon, Aug 08, 2016, 6: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…

> A story can be written to encourage a developers to improve quality of a codebase, share knowledge with another team, or take time to learn themselves. A really good story would encourage these things and also deliver customer value.

Show that to a people unfamiliar with the Scrum church and it will say that sentence is meaningless. And well, it is, in an absolute way. A story is just that: a story. Maybe it can help to put your son to sleep, but I doubt you need to invent a brand new vocabulary to discuss about software architecture and technical debt, and I doubt you can do anything brillant by only using a few examples in a field that is even more driven by pure logic than maths.

We are grown up. I don't want to work anywhere where I'm told stories and must get some points done by the end of the week. And this is not anecdotal: Scrum is a derivative of a manufacturing framework. I'm doing engineering.

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

#284

Post by specialist » Mon, Aug 08, 2016, 6:01 PM UTC

cechner wrote: post #135

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…

If you're objecting to people who treat scrum (or any project management tool) as a one-stop-shop that will cure all ills I agree with you, but nobody here is saying that. If you are objecting to defining the scope as small tasks and measuring your progress through that over time, then continually re-evaluating this scope as requirements change, then I think you are not working in an environment that would benefit fr…

My goal is to ship products that people will buy and use. Scrum and "agile" has only been an impediment.

"with such ridiculous vitriol"

Emperor, little boy, no clothes. It's thankless work.

In opposition, defenders of Scrum et al use the No True Scotsman's fallacy. Because those of us who have tried and failed are just morons.

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

#285

Post by st3v3r » Mon, Aug 08, 2016, 6:02 PM UTC

lmm wrote: post #118

humanrebar wrote: post #105

Earlier quoted context omitted.

> You may end up never porting that subsystem, in which case refactoring the currently-stable implementation is wasted effort. I understand this approach, and it works many times. But when the porting is delayed until the last possible minute, it's more likely that hacks are put in because the requirement turned into a hard deadline. Instead of defining a sensible OS abstraction layer, the developers might find and r…

> I understand this approach, and it works many times. But when the porting is delayed until the last possible minute, it's more likely that hacks are put in because the requirement turned into a hard deadline. Instead of defining a sensible OS abstraction layer, the developers might find and replace "Windows XP" with "Windows 7". Which may well be the right choice for the business at that point. More generally, it's…

"More generally, it's not like doing it now makes it faster than doing it later"

No, but "faster" isn't necessarily the point. Doing it correctly leads to it being "faster" because you don't have to constantly go back and fix bugs because you used ugly hacks to get stuff done in the short timeframe you had because the company decided to wait until the last minute.

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

#286

Post by st3v3r » Mon, Aug 08, 2016, 6:06 PM UTC

lmm wrote: post #149

humanrebar wrote: post #128

Earlier quoted context omitted.

You misunderstand. If more than a small minority of your code cares what OS it's running on (beyond obvious excepted), you have a large amount of technical debt. Cleaning that up, either by refactoring or replacing the offending code, is in the business's best interest because it keeps costs down and keeps more options available to the business. The 'business people' are not qualified by themselves to say that the co…

> Cleaning that up, either by refactoring or replacing the offending code, is in the business's best interest because it keeps costs down and keeps more options available to the business. IME that's very rarely the highest-value thing you can be doing for the business. It's not worth paying for flexibility that you're never going to use, and it's not like it's going to take longer to refactor later than it would to d…

"Yes and no. If you don't need to make changes to a given system then it's fine for it to "rot". Presumably there is a business reason they want to make changes, in which case bringing the code up to a point where you can make those changes is part of the cost of that business-level deliverable."

Except at that point, there's likely a hard (usually arbitrary) deadline, meaning you don't have the time. So you end up hacking stuff up again, and the tech debt doesn't get addressed. Your best people end up getting frustrated that they're not being listened to, and that they constantly have to explain this stuff to the business people, and eventually they leave.

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

#287

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

crdoconnor wrote: post #259

Udik wrote: post #255

Earlier quoted context omitted.

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…

True. The amount of technical debt produced is a function of the time constraints and the person skills. In turn, the time constraints can depend on the skills of other people in the organization at planning, designing, figuring out requirements, managing the team and the process, etc. Saying "ah sorry, we'll have to work one more week/ month on this because, you know, technical debt" is sweeping all these possible issues under one big carpet.

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

#288

Post by patothon » Mon, Aug 08, 2016, 6:10 PM UTC

ktRolster wrote: post #272

patothon wrote: post #238

Earlier quoted context omitted.

I don't like scrum myself, but let me try to defend it because I think the problem of most of the people who don't have a good experience with scrum is a misunderstanding of the underlying principles behind it. Let's just remember that Scrum is just a tool that is trying to replicate some practices of the toyota production system (TPS), and an important principle of the TPS is continuous improvement, and Scrum has th…

Your team ships an arbitrarily 10 points per sprint by doing what they think is right. The same team could ship an arbitrarily 20 points per week. 10 is the _true_ cost of building a healthy system. There is not a lot more to do for good team, honestly, at that point. Management can't say anything This sort of thing is only useful for managers who don't understand what is going on. Since they are unable to look at co…

I guess if you understand what is going on as a manager, then you might prefer the 10 points team?

I know I do.

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

#289

Post by st3v3r » Mon, Aug 08, 2016, 6:11 PM UTC

tener wrote: post #93

lmm wrote: post #68

Earlier quoted context omitted.

> Why can't we make some sub-component this sprint then the UI bit the next? Because that's how you get bad UI. The user-facing design needs to drive the API interface, not the other way around.

Not true. If you have design ready before the implementation starts (as you should unless it is very simple) then you are free to implementation things separately. Just have the interface well specified.

But if you design things ahead of time, then you're not "agile"!

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

#290

Post by ktRolster » Mon, Aug 08, 2016, 6:15 PM UTC

patothon wrote: post #288

ktRolster wrote: post #272

Earlier quoted context omitted.

Your team ships an arbitrarily 10 points per sprint by doing what they think is right. The same team could ship an arbitrarily 20 points per week. 10 is the _true_ cost of building a healthy system. There is not a lot more to do for good team, honestly, at that point. Management can't say anything This sort of thing is only useful for managers who don't understand what is going on. Since they are unable to look at co…

I guess if you understand what is going on as a manager, then you might prefer the 10 points team? I know I do.

If you understand what is going on, you will get rid of points altogether, and look at the git log from time to time.

If you are a leader, and not just a manager, you will help your programmers improve their skill, so over time you spend less and less time managing them. Your programmers will appreciate it because with greater self-management comes greater happiness and job satisfaction.