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

141–150 of 387 posts

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

#141

Post by [deleted] »

dasmoth wrote: post #123
timwaagh wrote: post #76

managers like it. control. results. evaluation. they get to treat programmers like laborers. programmers don't really have anything to gain with it. what surprises me, is that sometimes programmers ask for it. it illustrates how strong the desire is to follow the latest trend.

>>> what surprises me, is that sometimes programmers ask for it. it illustrates how strong the desire is to follow the latest trend. While I'm far from a Scrum fan, it's not necessarily the worst thing in the world. For instance, it's probably better than "just do what the project manager says", especially if he tends towards micromanagement. And double-especially for people who thrive in group discussions but have t…

[deleted]

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

#142

Post by joe8756438 »

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 it would be questioned and "split" to break the job into component tasks that could be done by separate people simultaneously (or some now some later).

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

Writing stories is the main art of scrum and without good stories it is pointless. 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.

Any system for managing software development hinges on good communication. SCRUM's main advantage to me is that it provides continuous opportunities for face to face communication. If you fail to take advantage or engage with those opportunities then it won't work, but I bet another "framework" wouldn't either.

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

#143

Post by gtirloni »

humanrebar wrote: post #21
mms1973 wrote: post #4

In my opinion, the good thing about Scrum is that you can tweak the rules to fit your needs, aka, "Scrum in name only". The daily standup, IMO, should be only to remove impediments, and if you have none, then a sentence or two will suffice. I see the DS as the most useful meeting, as you are aware of what your workmates are doing. And if Scrum is still a pain in the back, then you have Kanban, which is sort of Scrum…

> The daily standup, IMO, should be only to remove impediments, and if you have none, then a sentence or two will suffice. 100% this. The only thing a synchronous team-wide meeting is useful for is revealing a significant issue and getting a prompt and definite acknowledgement from the team. And then, if it's a priority, some help with the issue. But given the proper tool, even that feature can be made asynchronous.

IMHO, unfortunately standups tend to become status report meetings just for the sake of it (article talks about control, I think it nails it). I rarely see anyone bring a blocker. It's just "yesterday i did this, today i'll do this. Next!".

It gets worse if the team is actually 2-4 different teams with not much overlap (because companies tend to adopt these agile methodologies without much thought and it just keeps growing and including more people because.. it's nice, right?). Then you're ignoring (or not having a clue) about 90% of the meeting, and it's _daily_.

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

#144

Post by maxxxxx »

blub wrote: post #46
maxxxxx wrote: post #22

Earlier quoted context omitted.

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".

Why is management getting involved? The PO should try to balance this with feature impementation and the team + SM should make it clear when it's needed. This seems to work fine in an environment based on collaboration between PO,SM and dev team, but will probably fail in an adversarial one.

I have rarely seen a PO as the single contact to the "business". Most of the time there are multiple project managers, product mangers and line managers who have a say and put pressure on the dev team.

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

#145

Post by Spooky23 »

discreteevent wrote: post #112
afroisalreadyin wrote: post #70

Earlier quoted context omitted.

Author of the post here, thanks for your comment. As you said, the fact that you have to stick out your neck and fight for code quality is very annoying, and after some time, one just stops doing it, and starts flowing with the "add the one more line of crap to get things working and collect the points".

"Lean" is supposed to address quality and habitability more. 2 of the 7 tenets of lean focus on it: Build Quality In Optimize the Whole I've never practiced it and my only exposure has been reading some of the book "Lean Architecture". But it certainly seems like an improvement over Scrum which seems blind to some of the most critical things in developing complex innovative systems. In fact I'm convinced that Scrum w…

Remember that "Lean" (SCRUM is really a subset of those practices) is at it's core a manufacturing process. Manufacturing isn't engineering. The author of the original post captured this very well:

> ...one can claim that this is not the job of Scrum, which is a software management methodology, and not a software engineering methodology, that it's only concerned with organizing the teams' time and workload

A manufacturing process can only drive quality if both the primitives and end system have gone through some sort of engineering process. Web developers love this stuff because they have components, frameworks and clients where the engineering details are taken care of in MANY scenarios.

Using a contrived scenario involving LEGO -- you cannot expect kids and parents to design new LEGO parts. The components are designed and engineered to work together in a completely different context. Carrying this further, if you want kids to assemble a consistent, specific artifact (Say a Star Wars X-Wing fighter), someone at LEGO needs to design that and produce documentation. Designing on the fly with sprints ("ok, kids, today figure out how to make a wing") isn't going to be a productive exercise.

Most SCRUM projects that I have personally seen fail are projects where "agile" is a codeword for "we didn't think this through, so we'll figure it out as we go". Then the "sprints" become a real joke as the team repeatedly runs into a wall.

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

#146

Post by maxxxxx »

fsloth wrote: post #111
maxxxxx wrote: post #22

Earlier quoted context omitted.

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".

In a non-broken organization technical leads (or equivalent) have same level of authority to guide development as feature driven personnel and the necessity of features vs. quality can be triaged in bright daylight. If the organization is not sane, that's another thing of course (and often the case, sadly).

True, but don't forget that non-broken organizations are very rare :-)

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

#147

Post by neo2006 »

Both devs and managers are attracted to scrum for two different reasons: - devs like scrum because of the agility of it and the though that they will have more control on how to evolve the product and the code base and have the freedom to architect and develop the way they see it right. - managers like it because it gives them an oversight on how the team is performing and a possibility to have a more accurate estimate the a rule of a thumb. In my opinion scrum stop working when devs think that it's complete freedom and control over the product and/or managers think it is a magical spell to increase team productivity. Another reason that make scrum goes wrong is that religious believe that every rule in scrum manifesto needs to be applied as is so magic can happen, scrum is not a recipe but a guide that need to be adapted to each team, organization and context. Trying to follow the rules religiously will always fail.

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

#148

Post by ozmbie »

thackerhacker wrote: post #52
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…

It's a long time since I've had to deal with "strict" Scrummers. But I do remember being utterly baffled as to the insistence on user features being ready by the end of a sprint, even for quite complex, technical components. Why can't we make some sub-component this sprint then the UI bit the next? I tried various ways of reframing it such that the developer of the UI be the "user" but it didn't wash.

Because that two weeks you spent writing excellent code is mostly useless unless you have a way to get feedback on it. As a customer, you've given me no value.

What if you finally hook up UI to the sub-component and the customer/stakeholder decides they don't like any of it? You could have known about it earlier.

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

#149

Post by lmm »

humanrebar wrote: post #128
lmm wrote: post #118

Earlier quoted context omitted.

> 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…

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 do it now.

> The 'business people' are not qualified by themselves to say that the cost-benefit analysis of the refactoring is worth the effort.

Yes they are. Cost-benefit analysis is their job. It's your job to give them an accurate picture of the costs and the benefits.

> Because while they may have a good idea of the customer benefits, they generally have little insight into what the future costs of technical debt are. You see this obviously demonstrated by 'business people' who are shocked that there is work to do on five-year-old code that has been working fine for years. Any reasonably experienced developer, any many junior developers besides, can tell you that code rots if it's not maintained properly.

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.

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

#150

Post by s_kilk »

bmj wrote: post #140
s_kilk wrote: post #82

Earlier quoted context omitted.

This is how we ended up with the "Shadow Sprint" at a previous workplace. A whole bunch of utterly essential engineering work was left out of the sprint process, so many of us would just go ahead and do what needed to be done anyway while working on whatever tickets we'd picked up frome the "real" sprint. Utterly dysfunctional of course, but if it's do-or-die, I'd prefer to 'do'.

How did you handle regression testing of the refactored functionality? That's our biggest hurdle. QC is swamped with "regular" sprint work, so there's no way they manage any additional load during the sprint.

We had pretty good (but not amazing) unit and integration tests in many of those systems, and a willingness to manually test the systems where we didn't have tests.

If we had to lean on a QA department to get this stuff done, I'm not convinced we would have been able to actually deliver that project.

Post reply on HN