Live data from Hacker News

Why I'm done with Scrum

lostechies.com

61–70 of 163 posts

Re: Why I'm done with Scrum

#61
post #57

The problem with SCRUM is that it is not agile. That's why we see most of the pragmatic companies adopting a kanban or scrumban approach and they see good results. I would argue that just having a kanban board during stand-up meetings and "walking the board" instead of interrogation-like status reporting is going to do wonders to team collaboration atmosphere, morale and actual productivity. You start to see and talk…

Can you elaborate on why Scrum is not agile? You are the first I read claiming this.

Re: Why I'm done with Scrum

#62
post #45

I work at Webs and we also recently abandoned scrum for a more kanban approach. While all points in the article resonated with our company, the biggest problem we had was not delivering projects on time. We focused too much on fitting as much work into a sprint as possible for maximized throughput. The problem with that, especially when you have alot of projects going on at the same time, is that alot of work was bei…

I very much agree with the last point. Objective evaluation of a developer is much more than burned down points.

I worked at Amazon and could see evidently that Scrum was turning good developers into mediocre ones. But not many raised a finger against it as Scrum was seen as the norm. And there was no scientific way to establish this fact.

Re: Why I'm done with Scrum

#63
I've done a bunch of reading about Scrum. If you read between the lines, you realize that Scrum was created and popularized by consultants who go into dysfunctional teams/organizations, and tries to fix the worse problems. For example, the idea of a sprint is for a team to be able to work for at least a couple weeks on a single thing, without people being asked to work on other "small" projects, or without the entire direction of development changing every week.

Once the team is functioning well, you can usefully relax a lot of the aspects of Scrum.

Re: Why I'm done with Scrum

#64
post #9

Earlier quoted context omitted.

True. My last project started each day with 2 hours of scrum.

> started each day with 2 hours of scrum. What? Was your 15-minute stand-up 2 hours long? If so, are you sure you were doing it right? Were you scrum-master, and doing 2 hours of admin per day? What were you doing for the rest of the working day? I'm not really sure what you are describing here.

We were doing it wrong, for sure. It was a largish team with lots of drill-down done into each person's status. I had no power to change it.

Re: Why I'm done with Scrum

#65
post #61
post #57

The problem with SCRUM is that it is not agile. That's why we see most of the pragmatic companies adopting a kanban or scrumban approach and they see good results. I would argue that just having a kanban board during stand-up meetings and "walking the board" instead of interrogation-like status reporting is going to do wonders to team collaboration atmosphere, morale and actual productivity. You start to see and talk…

Can you elaborate on why Scrum is not agile? You are the first I read claiming this.

Great question.

I might have a harsh tone in my previous comment but I've got really frustrated with scrum (or implementations of it) over the last few years.

Scrum in my eyes is a process and from what I've seen it makes teams very process oriented. The whole idea of scrum master certification and the success it had in enterprise adoption might have something to do with that.

It incentivises teams (at least all the teams I've seen) to work for the process as good as possible. They focus on complying to the process, getting estimates right (or working in a way that makes the estimates right), they focus on the backlog instead of throughput or frequent re-prioritization …

If you can free yourself from viewing the 'process' as fundamental religion it's easier to apply agile & lean principles like focusing on delivering value and improving the framework, changing things, changing the process so it fits your needs, etc.

In a nutshell: I see scrum incentivising people to work in a way that is not agile but pseudo-agile/feel-good-agile. I see no feedback loop for the process itself (at least I see no one doing that, except teams that adopt kanban and scrumban or do scrum but …).

But I'm interested in learning from people who've made other experiences. It's an exciting topic.

Re: Why I'm done with Scrum

#66

Earlier quoted context omitted.

You can, however, strip it down even further and still be effective. Scrum encourages bundling stories into sets and delivering them all at once. I've been moving away from that, and continuously delivering discrete stories/features/changes/fixes/whatever as they are ready. Decoupling incrementalism from iterations has been a huge change for me.

What does QA look like with continuous delivery?

Different continuous delivery teams do it differently. I don't like having a dedicated QA team/department. QA is an effort, not a role.

The key part of continuous delivery is that the safest change to make to a stable system is the smallest change possible.

So instead of batching up lots and lots of stuff and throwing it over the wall to QA, you make one change, have humans and robots test it, and deploy that change. The mindset shifts from "features per release" to "releases per feature" so with truly friction-less automated deployments, you can release very small changes individually. You don't have to test everything in order to change anything.

As you may expect, multiple layers of test automation are necessary. Each change runs a gauntlet of different kinds of tests before release. A set of "safe to run in production" tests immediately after release. Rollbacks are trivial, but exceedingly rare.

Obviously, this only works in some contexts. If you're pressing things onto gold master DVDs and shipping them in boxes, the QA effort will be more traditional.

Re: Why I'm done with Scrum

#67

Earlier quoted context omitted.

You can, however, strip it down even further and still be effective. Scrum encourages bundling stories into sets and delivering them all at once. I've been moving away from that, and continuously delivering discrete stories/features/changes/fixes/whatever as they are ready. Decoupling incrementalism from iterations has been a huge change for me.

What does QA look like with continuous delivery?

Your automatic (unit, functional, system) tests assure stuff doesn't break (too much), and manual QA happens after deploying. If something is broken, you can fix it very fast, since you are deploying continuously.

Stuff might sometimes be broken on production, but you could argue this makes people think twice before pushing to master.

Also, you can deploy to production with a delay (e.g. 1h) and deploy to a QA server first to give the QA people some time to check before stuff goes to production.

Re: Why I'm done with Scrum

#68
post #48
post #30

Earlier quoted context omitted.

I completely disagree [1]. There's a difference between a cowboy programmer and a programmer that can go more than a day or two without checking in with his superior. In my personal opinion, based on the level of intelligence required to do good programming, the best programmers are self-managing. As a corollary to that, it's too expensive to hire development managers (in the traditional "management" sense) that can…

Actually, you completely agree with me. A Scrum Team very explicitly is self-managing. Agile processes ARE frameworks for coordinating self-management at the team level, and which have been found to work repeatably. That doesn't mean a given one will work everywhere. Specifically, Scrum is probably not ideal for startups doing something truly new, since it assumes there is someone who can prioritize features by their…

Why would you tell somebody that they completely agree with you when they just said that they disagreed? That's so rude. You say "That's cowboy programmer bullshit", he says "I completely disagree." Do you really think there's a chance he secretly agrees that his view is "cowboy programmer bullshit"?

Re: Why I'm done with Scrum

#69
post #27
post #16

Earlier quoted context omitted.

I think your last point is key. You can't use process to turn a bad programmer into a mediocre one - any process that does will also turn a great programmer into just a mediocre one.

That's cowboy programmer bullshit., the kind of thing mediocre but cocky programmers tell themselves to justify primadonna behaviour "having nothing and good developers you trust" is either a recipe for disaster, or a short prelude to those good developers coming up with a minimal ad hoc process that fits the project and most likely is remarkably similar to one established Agile methodology or another.

Here is another perfect examplee of what's wrong with SCRUM, it creates zealots. When someone starts talking about a need to give good, self-disciplined devs a little freedom instead of micromanaging them to death the scrum zombies start shouting about "cowboy programmers". When someone starts talking about long-term or strategic planning they start screaming about "waterfall".

The truth is that there is a lot of evidence from the field that having good developers and zero formal process is actually fairly workable, and often produces results. It's typically not the best system, but it's a strong antidote to the poisonous ideas of SCRUM, which holds that constant micromanaging at every level is strictly necessary otherwise puppies will die.

There are good elements within agile, such as iterative development, continuous integration, etc. but if you just choke down a whole ideology without exercising any degree of critical thought then you're going to make a lot of people miserable.

Re: Why I'm done with Scrum

#70
post #3

FTA: Scrum forces iterations, forces feedback, forces smaller iterations. These are all good things, which I loved about Scrum. And yet the author spends most of the article denying that these aspects of scrum are useful at all. Planning sessions are "highly inefficient," a "quick meeting between the architect and the developer" is better. What if someone else has an important piece of information that the dev and th…

The author has a point. Scrum is costly. Obviously it is more productive to silo specific knowledge to specific people, generally the expert (or more motivated) in that field.

At least it is in the beginning. People leave, experts become expert teams, silos widen and it soon become the good old planning nightmare we have all learned to "love" in enterprise development.

Post reply on HN