Live data from Hacker News

Why I'm done with Scrum

lostechies.com

131–140 of 163 posts

Re: Why I'm done with Scrum

#131

Earlier quoted context omitted.

Substitute one for the other. The people depending on your delivery don't understand (or care) that you're doing a x-point sprint, they care that their feature is delivered.

If they "don't understand (or care) that you're doing a x-point sprint", then you have big problems, since they have to choose 'x' points worth of stories to put into a sprint, and that's one of their two key responsibilities. Also, you cannot substitute points for stories - that's the whole point of the estimation process. (and also a large part of why software projects fail. "Doing 'A' is 10x harder than doing 'B'"…

I find this thread fascinating as Scrum actually says nothing about stories, or points, or hours. It also says nothing about the estimation process that the team should use. It also says nothing about the process to be used to select the sprint goal and the PBIs to be completed in the sprint.

All Scrum says is that:

1) there are things on the backlog (it doesn't specific what product backlog items are or should be - they could be user stories, they could be old-fashioned requirements docs, they could be use cases - Scrum doesn't care).

2) there is a Sprint Planning Meeting where the team and the product owner agree what the sprint goal is and the team forecasts the Product Backlog items it will deliver to meet that sprint goal.

The rest is up to the team.

Teams decide to track hours or points or story counting. Teams decide whether an estimation process is useful.

Also, you cannot substitute points for stories - that's the whole point of the estimation process. (and also a large part of why software projects fail. "Doing 'A' is 10x harder than doing 'B'" seems to be hard to understand until you have points to spend

Many teams can and do just count stories. Folk like Ron Jeffries who invented the point counting / velocity concept now prefer and recommend story counting. There's a whole group of folk who eschew estimating entirely (See stuff like naked planning for example http://aaron.sanders.name/agile-fashion/naked-planning-expla...).

Re: Why I'm done with Scrum

#132
post #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.

The author has a point. Scrum is costly.

I would prefer Scrum can be costly... it will also remain costly if people don't actually do the inspect and adapt bits of scrum and aim to improve the process.

I say this as somebody who is actually not a huge fan of Scrum :-)

Obviously it is more productive to silo specific knowledge to specific people, generally the expert (or more motivated) in that field.

Actually - I often find that isn't true. If you silo knowledge then those people become bottlenecks in the process. Since their the only people everything has to flow through them that relates to that topic.

For example I find that teams improve if the "UX Expert" switches from being the person who does all of the UX work, to being the person who facilitates UX work among the whole team.

That way the easy stuff gets done by the whole team, and the UX person is freed up to focus on the tricky stuff and stops being a bottleneck for general progress on the UX front.

Re: Why I'm done with Scrum

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

>It requires the kind of buy in that, if you've got it, you probably don't need Scrum anyway. I agreed up until this. I worked for a company that was doing waterfall and miserable. Things were getting done, but it was a sloppy mess. Clearly we didn't have our stuff together. Our manager went and took scrum classes, and then we spent a few months trying it out. There was no day-one benefit, but over those months we ma…

> After that, [...] Management was actually planning things out

The company probably would have worked just fine using the waterfall method if the management had bothered to work at all, I guess.

It improved not because of your manager took scrum classes, but because your manager took any classes.

Re: Why I'm done with Scrum

#134
post #65
post #61

Earlier quoted context omitted.

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…

Disclaimer: I actually use a kanbanish leanish approach myself myself. It's my preferred process for my current working context. I'm also very much not a fan of the Scrum certification process and what that has tended to produce in the industry. However:

I see no feedback loop for the process itself

Is just nonsense :-)

Scrum has only five events - and two of those are retrospectives (one on the increment, one on the process used). If you aren't inspecting and adapting the process then you are not doing Scrum.

Now I freely admit that one of the most common ways that people don't do Scrum is by skipping those steps. Then again it's also the most common way I see people do kanban/lean badly as well.

Re: Why I'm done with Scrum

#135
post #121
post #61

Earlier quoted context omitted.

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.

That's certainly not the intent behind Scrum though. The intent behind Scrum is to let the team within the sprint be pretty much completely free to implement whatever process they like to deliver the sprint goal. It's whole focus is to remove management interference from the main body of work the team does. PO figures out what needs doing. Team figures out the best way of doing it. Scrum provides a framework for accountability on both sides.

Scrum - done well - should be a tool to let the team figure out the best way to deliver.

Re: Why I'm done with Scrum

#136

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?

There are a bunch of folk (me included) who spend a lot of time thinking about getting UX and Agile folk to play nice together. You can find some of my rantings via lanyrd http://lanyrd.com/profile/adrianh/.

You'll likely find Jeff Patton's work of interest - this might be a good starting point http://agileproductdesign.com/blog/emerging_best_agile_ux_pr....

There's a stack of stuff under https://pinboard.in/u:adrianh/t:agile/t:ux that you may find interesting. Some of it may need filtering through my brain before you see the agile/ux connection though :-)

The UX track at Agile 2012 had a bunch of great sessions around getting UX and agile running well together (bias warning - I produced the track :-) http://agile2012.sched.org/overview/type/user+experience - I think all the sessions have slides now. Nag me if not.

There are also the sessions from Agile UX NYC earlier this year http://agileuxnyc.com/presentations/

Personally I'm finding UX works better outside of an iteration context with a more lean/kanban approach. The stuff Janice Fraser is doing at LUXr for example http://www.slideshare.net/clevergirl/. Google around the "Lean UX" topic. Ignore the folk who talk about it as if it's just about less deliverables. It's more than that.

Finally the agile usability mailing list http://tech.groups.yahoo.com/group/agile-usability/ is a useful place to chat about this sort of stuff.

Re: Why I'm done with Scrum

#137

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…

    I've done a bunch of reading about Scrum
Without trying to be inflammatory, this is no way qualifies you to speak with any authority on Scrum, or indeed any topic where your experience amounts to nothing more than a bunch of reading.

That is not to say that you don't make any valid points. I think the fundamental tenets could be relaxed over time, but I guess with some organisations when you start removing some of the restrictions you'll eventually remove more and more until you're back where you started.

Re: Why I'm done with Scrum

#138

Several comments about the notion that at some point you outgrow Scrum. For those who have reached this point, I'm curious what you've switched to? Or has it been more of simply relaxing some of the constraints/procedures? Asking because I've recently started to wonder if/when we'll need to modify our mostly-Scrum process.

The most common (productive) change I've seen is a move to something that's closer to the pull/kanban/lean approaches.

For example a pattern I've seen a few times goes something like this:

* Teams get good at breaking down and estimating backlog items, they tend to all become the same "size" and need about the same amount of "work"

* Product Owners get good at prioritising the work so that the most valuable stories are at the top of the queue

* Dev team and product owner turn have a collaborative relationship rather than a boss-minions relationship.

* The combination of those three factors means that the planning meeting basically turns into "we do the next N stories" where N is the number of stories you get done every sprint. So the utility of this meeting disappears.

* The process of work flowing through the team starts resembling single-piece flow. Everybody works on the next most important thing.

* People start continually delivering, rather that just being able to deliver at the end of the sprint.

* The last two points mean the utility of breaking work into sprints kind of vanishes.

* Everybody notices that they're doing flow-ish things rather than batch sprint-ish things and starts looking to the lean / kanban world for ways to optimise the process further.

Re: Why I'm done with Scrum

#139
post #31
post #25

just code. code well.

You can code, code well, and then discover that the feature you just implemented was something that the upper management actually didn’t consider to be very important, or that they wanted something completely different from what you thought they wanted. That’s the sort of failure mode that Scrum and other development methodologies are trying to protect you against.

I tend to think bringing in agile specialists and installing scrum process to save the project is a bit dogmatic. If you worked on a project for sometime and wrote/rewrote a lot, you probably know what's needed to be written. It's fairly unlikely the scrum process actually helps at that point. What keeps you going at it is probably "faith" you built through out the year since the onset of scrum installment... and, just a habit.

If you are afraid of writing unneeded, unimportant, and unpopular things enough to label them as a "failure", your focus may be to find needed and important things for your audiences.

Your focus may be to read the draft to a select sample audiences everyday, every week, continuously, and apply various analytical techniques to different statistical models you built from the feedbacks to overcome your fear of rejection, and "manage" direction, completion, and shipment of your writing.

Or just write. A lot. And read. A lot. You'll "get" trends. You'll "get" what works and what doesn't. Of course you need feedbacks. Of course you need plans and management especially if you are co-writing with many authors.

But my focus is still to write.

Re: Why I'm done with Scrum

#140

Earlier quoted context omitted.

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?

Because communication and planning also have value, even according to you, as long as they aren't 'imposed'. But what is really being imposed here? Simply the timing, the regularity of the events. Just like eating or paying the rent.
Post reply on HN