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

Why I'm not a big fan of Scrum

okigiveup.net

Post reply on HN
Print view View original

261–270 of 387 posts

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

#261

Post by apeace »

This was my favorite point out of them all:

> What about contributing to open-source software? Reading the code of an important external dependency, such as the web framework your team uses, and working on bugs or feature requests to get a better understanding was not part of any Scrum backlog I've ever seen.

Working at various startups, I have developed a methodology of contributing back to open-source projects we use without accounting for it in sprints or the ticketing system. It involves getting to the office an hour early, over-estimating on my other tasks so I have time for something extra, and a sprinkle of office politics.

And yet, it is some of the most valuable work I have done. Not for me, but for the companies I've worked for.

To get an in-depth understanding of that one Django or Express.js feature you use, or even better, to find and fix a bug that affected the business or may have affected it in the future, just gives you that much more of an edge over your competitors. Say goodbye to that nasty workaround you had to use to get around the bug--now it Just Works exactly how you need it to!

What's more, it's attractive to engineering candidates when you get to tell them the story of when you fixed a big bug in Socket.io.

The best engineering managers I have had have been receptive to the idea that this type of research and/or contribution to other projects should be considered "work" that provides value to the business.

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

#262

Post by crdoconnor »

daemin wrote: post #133
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…

One question I have is how does one actually objectively measure technical debt? I mean by anything more than a guess or intuition. Does every singleton/global variable count? Does every comment with a HACK count? What other factors contribute to technical debt, and by how much?

I've pondered this problem for a while and I think I narrowed it down to the following:

* Tight coupling (this would include global variables, among many other things)

* Lack of code cohesion

* Code duplication

* Code that doesn't fail fast (e.g. weak typing).

* Variable/class/method naming that is either not sufficiently disambiguated or is wrong.

* Lack of tools to run and debug code

* Lack of test coverage

Whenever I go looking for code to clean up this is what I keep an eye out for.

I'm pretty sure that each of these could be measured empirically somehow (I've read papers to that effect for a few), but we're not quite there yet in terms of tooling, or even in agreement over what technical debt actually is. Give it 5-10 years.

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

#263

Post by nawitus »

Meegul wrote: post #43
dudifordMann wrote: post #30

I agree that there are individuals and companies who have defined such ridged structure and expectation into their Scrum method that they can no longer be considered an agile approach missing two of the key purposes of agile approaches: * Individuals and interactions over processes and tools * Responding to change over following a plan Now, I cannot say that Scum abstractly is a bad approach to attempting to be more…

His complaint about the standups interrupting productive work rings a bell with me though. I see no reason why a daily status update over the general channel on slack doesn't serve the same purpose as a standup meeting. In fact, make it so there's a loose timeframe, say 30 minutes, and you wouldn't be interrupting people, nor forcing them to stare at a wall. My team hasn't tried anything like that, but I think it cou…

We've tried that using Slack (and also IRC in previous projects, perhaps even email at some point). It works well, and I don't remember when I did a face-to-face daily standup the last time.

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

#264

Post by Zigurd »

maxxxxx wrote: post #22
cageface wrote: post #7

I've been doing Scrum-driven development for a few years now after working much more independently for most of my career. I understand why managers like it because it at least lends some structure and predictability to what is an inherently unpredictable enterprise. But the author's criticisms of the incentives of Scrum are on point I think. Because the stories are always articulated in terms of user facing features…

In my view the only way to handle this is to make constant refactoring part of the work without telling management. If you ask for permission for refactoring you will almost always get a "No".

This is a typical way that agile and related approaches become a barrier between implementers and management.

The fault is almost all on the management side because, ipso facto, they're the ones making the decisions that drive this outcome.

In the real world, there are outcomes that are much worse than this. But this does have the effect of neutralizing the value of scrum: Management gets what implementers decide they get, and scrum is just the way middle management is told the story that they pass up the chain.

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

#265

Post by Udik »

gmarx wrote: post #256
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 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 perfo…

This sounds like a bad organization of the team, bad process or bad design. Clearly team members don't communicate enough, or groups of similar features have not been foreseen during the design phase, and the same code has been rewritten again and again by different people. This is not contingent "technical debt", this is a serious problem that needs to be addressed with changes in the process.

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

#266

Post by crdoconnor »

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.

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 anybody else is the kind of developer who magically creates debt-free code all the time then you're deluded.

2) The "right first try" argument is wrong. You shouldn't even try to get it right first try - that's the whole point of red/green/refactor. You're supposed to get it working and then clean it up because prematurely 'cleaning up code' is an inefficient way to work.

It's not called red/green/refactor-if-you're-too-shit-to-get-it-right-first-try.

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

#267

Post by superuser2 »

draz wrote: post #106
cageface wrote: post #7

I've been doing Scrum-driven development for a few years now after working much more independently for most of my career. I understand why managers like it because it at least lends some structure and predictability to what is an inherently unpredictable enterprise. But the author's criticisms of the incentives of Scrum are on point I think. Because the stories are always articulated in terms of user facing features…

I am Product in a large corporation, and it's a certainly a fine balance. In a previous life, I was a developer, and I dealt with similar issues. I have a lot of respect and empathy for the the Tech team. Therefore, I asked my Tech team to inform me when things are getting out of hand -- that's the responsible Product thing to do . I instituted that technical debt is part of our KPIs. If it's not captured, it's not a…

> technical debt is part of our KPIs. If it's not captured, it's not actionable

This is where I suspect manager-types and developers have a vigorous divergence in values.

Professionals routinely encounter situations where something is wrong and needs to be "actioned" but its wrongness isn't effectively measured by any metric (other than the opinions of the experienced people looking at it).

There is a certain species of manager who has taken Taylorism a bit too far and says that anything not reflected in the KPIs is not real and not getting acted upon. I hope this isn't what you're expressing here, but oh man is that mindset frustrating.

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

#268

Post by Zigurd »

matthewmacleod wrote: post #101
nutheracc wrote: post #69

NoEstimates: http://ronjeffries.com/xprog/articles/the-noestimates-moveme...

That's a great idea if you don't have any customers or constraints. In the real world, there are externalities that have an impact and require some estimation. Maybe we have to provide new support materials to customers, or finish a contract with a third-party data provider, or change our infrastructure. It's exceptionally hard to do some of these things without being able to make commitments of some kind. Estimates…

This is exactly why waterfall works for building a building, and why it doesn't work for building software: You can directly observe progress.

Some of the better aspects of Agile are aimed at providing an analogous level of obviousness: E.g. don't move on until a story is completely implemented. This means you see schedule risk as it happens. This also avoids the way waterfall projects used to die, like the one I saw at Lotus while consulting on Mac porting, back when using conventional project management tools for software was a progressive management practice: A GANTT chart with hundreds of lines corresponding to tasks. Each progress bar partly filled, most of them 70-80%. Yet the project was dead because it was obvious it would not be completed in a relevant time-frame.

It is far too easy to game completion tracking in big, complex projects if you don't decompose them into small sequential projects. BUT, even though each smaller project has schedule risk that is reasonable, when you add up the schedule risk across all the sub-projects, if you are honest, it will be large enough that an estimate is going to have low reliability.

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

#269

Post by jorge-fundido »

Bartweiss wrote: post #245
taneq wrote: post #49

Earlier quoted context omitted.

You, because the moment you leave you become that-guy-who-we-can-safely-blame. Mostly joking but plenty of places do work like that.

Isn't there a name for this pattern? I swear I remember reading a piece on how having a team member leave can be good for cohesion and efficiency, because everyone is free to vent about old, bad decisions without targeting anyone still at the company. I think it was part of a story about a team clearing their technical debt by convincing a reluctant manager that they needed to undo the last guy's mistakes.

"Blame Canada". PM: "We can't blame Canada for missing our targets 4 sprints in a row."

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

#270

Post by akvadrako »

wott wrote: post #199
cechner wrote: post #3

Earlier quoted context omitted.

oh and I have attended some of those expensive Scrum 1-week courses and saw the darker side of that community - it definitely has a cult following that give it a bad name, but I've been to similar conventions around design patterns, object-oriented and (to a lesser degree) functional programming so I think that the community problem is not particular to Scrum.

The problem is communities.

interesting. Do you have an alternative in mind?
Post reply on HN