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

Why I'm done with Scrum

lostechies.com

Post reply on HN
Print view View original

121–130 of 163 posts

Re: Why I'm done with Scrum

#121

Post by YZF »

manmal wrote: post #61
tosh wrote: 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.

I've heard this before. I think the most simple reasoning there is that the Agile manifesto says: Individuals and interactions over processes and tools. In Scrum it is process over individuals. The process is what is important, not the individuals.

Re: Why I'm done with Scrum

#122

Post by jim-greer »

jt2190 wrote: post #47
at-fates-hands wrote: post #37

> Iteration planning meetings are seriously expensive. I completely agree on this one. I've worked in several corporate environments utilizing Srum and the planning meetings were always a huge waste of time. I would rather light my hair on fire than sit around a bunch of PM's trying to figure out what features to include/exclude. Also, most of the people (PM's,Dev's,IA's) I talk to always say, "Nobody does Scrum/Agil…

In my experience most teams do planning completely wrong. The goals of the planning meeting are simply: 1. Do a relative-size estimate the top n stories in the backlog. (Where n is some number slightly larger than the number of stories that usually fit in an iteration.) 2. Pick the stories to complete in the iteration. That's it. I often see teams: * doing one-by-one story estimation, and debating over how many point…

Do you really think one-by-one story estimation is that bad? At Kongregate it's about 8 people doing it, for 45 minutes or so every couple of weeks. It isn't the most fun thing in the world, but I do think it's helpful to spend between 30 seconds and a few minutes talking about how hard something's going to be. If it seems hard, easier ways are often suggested...

If you're not looking at them one by one, what are you really doing? Why not just say all stories are the same difficulty?

Re: Why I'm done with Scrum

#123

Post by adrianhoward »

InclinedPlane wrote: post #69
brazzy wrote: post #27

Earlier quoted context omitted.

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

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.

For certain kind of organisations yes. Take a look at the research Alistair Cockburn did and his various Crystal [colourname] methodologies. http://alistair.cockburn.us/Crystal+methodologies

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.

If you've got a team claiming their doing Scrum where you see constant micromanaging - that team is not doing Scrum. At the very core of Scrum is the idea that the team organise their own work (within the very few practices that Scrum enforces).

(Obniggle: Scrum is not an acronym you don't need to SHOUT :-)

Re: Why I'm done with Scrum

#124

Post by demian »

We need to drop the idea that there is THE methodology to organize software development. I like the approach of this post, but I would had prefered a little more context on the type of projects he manages.

A professional software manager should be able to identify the key aspects of a project, and with that define the methodology (borrowing from different aproaches and using different tools). Some projects require centralized design with a top-down approach, and more of a "programming workforce" self-coordinated with some progress metric. Other projects require more sophisticated engineering design, technical expertise imbued in a creative enviroment by a relatively small team of engineers/developers.

In my opinion, iteration is all about exploration. Scrum basically discards the role of a "designer" for the systems. But sometimes you need a designer.

Re: Why I'm done with Scrum

#125

Post by adrianhoward »

ajross wrote: post #71
brazzy wrote: post #27

Earlier quoted context omitted.

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.

Isn't that just a No True Scotsman argument? You're saying that Agile is good because it's isomorphic to any successful, minimal ad hoc process that fits the project . Well, OK, if that's your defintion of "Agile". But the "Agile" (rather "Scrum") described in books and web videos and blog posts isn't like that at all. It has become a decidedly "heavy" process with all sorts of jargon behind it. My guess is that this…

I know - it does come across as the one-true-scotsman argument at times.

Disclaimer: I'm a fan of agile. I even seem to be turning into one of those evil consultant people in my old age (but only just recently - and I still code :-)

I'd urge agile sceptics to put aside some of the crap they see in the real world. Go take a look at the original sources (e.g. both of Beck's books on XP are fun reads - and short :-). Take a look at the Scrum guide (http://www.scrum.org/Scrum-Guides) - it's only 16 pages long. Does that look like a heavy process?

Agile got popular in the early 00's coz it helped many teams get better. It then suffered the curse of getting popular. Everybody and their dog started doing it badly, or relabelling what they were doing already as agile. Pretty much every agile method came from developers. XP in particular was process that came from developers observing what worked well for them. Ditto Cockburn's Crystal methods. Scrum worked so well because it kept management out of the loop during sprint development (and that's also one of it's failings... but that's a different argument :-)

To pick a pure development analogy. Large chunks of the OO code I see isn't really OO code. It's some procedural code and some pure data structures wrapped up into classes and methods. Because of this it doesn't reap the benefits that good OO code provides.

Because I've seen good OO code, and because I can write vaguely decent OO code, I can see that. I can see the difference between the surface artefacts (classes and methods) and the underlying philosophy of an OO breakdown.

It's the same deal with agile a the moment. There are lots of places that are "doing agile" that are only touching upon a couple of the surface artefacts, but not actually making any of the philosophical changes that mean they build better code.

For me this doesn't mean agile sucks, any more than it means object-orientation sucks.

Re: Why I'm done with Scrum

#126

Post by adrianhoward »

shaunxcode wrote: post #60
fingerprinter wrote: post #4

When I took over development of a extremely dysfunctional engeering team at an established startup with 100 people, the first thing I did (after watching for a bit to learn) was put in scrum. It worked. And it worked really, really well. 2 years later, it didn't work anymore. The team had matured, the organization itself had adapted to the leaner processes and mindset and, in time, the actual scrum process was too mu…

Agile should also be subject to Agile. I like to think of it in terms of the Viable System Model in which the system has the potential to change itself based upon feedback. Put another way - make sure your implementation of Agile/Scrum supports tail call optimization and macro expansion or face the reality of being stuck in BlubScrum.

Agile should also be subject to Agile

It is (or should be).

For example:

* XP folk very explicitly state that you shouldn't be "doing XP" N months down the road. You should be optimising your process

* The Kanban/Lean folks whole method is about having a process for process improvement

* Scrum very explicitly has Sprint retrospective and reviews aimed at looking what happened and changing the process to improve results next time.

* Crystal is all about aligning the amount of process you do to the working context you're in.

Of all the agile processes Scrum is really the only one that says you must do certain things in a certain way - and even there it's a very light framework of five events and three artefacts) that gives you a space to figure out your own process in.

Re: Why I'm done with Scrum

#127

Post by adrianhoward »

debacle wrote: post #13

> With Scrum, there is an explicit commitment ... on what stories are going to be delivered within the sprint, No, there isn't. You adhere to your burn-down, not to your feature set. Scrum is time driven, not task driven. The whole idea is to become better at estimation so that Scrum appears task driven, when really it's just because your team is that good at estimating. > Iteration planning meetings are seriously ex…

No, there isn't. You adhere to your burn-down, not to your feature set. Scrum is time driven, not task driven. The whole idea is to become better at estimation so that Scrum appears task driven, when really it's just because your team is that good at estimating.

Erm. There is an explicit commitment by the Scrum team to complete the stories selected to produce the next increment in the sprint. To quote from http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scru...

"The two parts of the Sprint Planning Meeting answer the following questions, respectively:  What will be delivered in the Increment resulting from the upcoming Sprint?  How will the work needed to deliver the Increment be achieved?"

The commitment on delivering a certain chunk of work has been one of the more controversial elements of Scrum. Many people who say they're doing Scrum don't do this. But it is very definitely part of the Scrum process as defined.

Re: Why I'm done with Scrum

#128

Post by quicksilver03 »

vannevar wrote: post #116
quicksilver03 wrote: post #80

Earlier quoted context omitted.

tosh has replied already, but I'll offer my explanation as well: Scrum is not Agile because it's all about ceremonies (the planning meeting, the daily standup). The only ceremony that brings some value to the project is the retrospective.

Just because something happens routinely doesn't make it ceremonial. You turn on your computer every day as you begin work. Is that a ceremony? You eat a meal every day. Is that a ceremony? Pay rent or make a house payment every month? More ceremony? What you mean, I think, is that you don't see the value in the activity, or have some other aversion to it, so it's purely ceremonial to you. I assume (maybe incorrectly…

You have a good point in that I don't see the value of imposing communication and forcing people into meetings, however why the straw man? Eating and paying rent definitely have a value, so why bring up the comparison?

Re: Why I'm done with Scrum

#129

Post by adrianhoward »

sethg wrote: post #34
debacle wrote: post #13

> With Scrum, there is an explicit commitment ... on what stories are going to be delivered within the sprint, No, there isn't. You adhere to your burn-down, not to your feature set. Scrum is time driven, not task driven. The whole idea is to become better at estimation so that Scrum appears task driven, when really it's just because your team is that good at estimating. > Iteration planning meetings are seriously ex…

In my experience (six months at a job that does Scrum and, I think, does it very well), the thing that slows down iteration planning meetings is when the product manager hands down a one-sentence feature description, the engineers say “we can’t size that, it’s too vague”, and then you need a five-to-fifteen-minute discussion in order to expand that one sentence into something resembling a spec.

I've seen that happen.

These are exactly the sort of problems that should show up in sprint retrospectives. Hopefully folk then generate ideas for solving them (e.g. PO breaking down stories further before the planning meeting, or devs getting more up to speed in the problem domain so they can grok brief feature descriptions more easily).

So - what's happening in your sprint retrospectives?

Re: Why I'm done with Scrum

#130

Post by JoelMarsh »

There seems to be some very scrum-savvy people here. I have used it many times, but I am interested in your thoughts about how designers typically work within that framework. In my experience design and scrum don't play very nicely together. Thoughts?
Post reply on HN