Scrum seems to be mostly about having better alibis • Hacker News Board

Re: Scrum seems to be mostly about having better alibis

#61

Post by dreamfactory2 » Mon, Mar 16, 2015, 4:26 AM UTC

RalfR wrote: post #27

quanticle wrote: post #21

Like committing to a sprint target. And literally doing everything to fulfill it. Like not waiting for a manager to step in and ask for overtime and weekend shifts. Remember? Scrum teams take all the necessary steps themselves. Always! Isn't the entire point of scrum to enforce a sustainable pace of development? One that doesn't require heroics like having programmers come in on nights and weekends to finish? The ent…

Well, as far as I understood, Scrum's fundamental principle dictates that the team delivers working software at the end of every Sprint. This has partially to do with not over committing at the beginning, but if the team fails to judge correctly, it has to do what needs to be done to fulfil its promises. Unfortunately, this clear obligation gets forgotten to often – as I pointed out in the original post. You seem to…

There is an obligation to deliver working software but there is no commitment to deliver specific features, just a target.

Re: Scrum seems to be mostly about having better alibis

#62

Post by dreamfactory2 » Mon, Mar 16, 2015, 4:34 AM UTC

RalfR wrote: post #25

matthewmacleod wrote: post #24

I actually started writing a point-by-point response to this, but it mutated into a thousand words and will be better suited to a blog post at some point in the future. In the meantime, I think these are generally the same shallow straw-man arguments against Scrum that we all see pretty frequently. I guess the key points to bear in mind will be: - Scrum is not a be-all and end-all solution to all product development.…

I value your opinion, even if I do not agree with it. The argument of "Scrum being poorly implemented" is brought again and again. It's just another one of these go-to killer arguments. If Scrum is so mega simple, why do we see endless cases of it failing to being implemented correctly? Maybe we should start thinking of a framework, that people can actually implement and make successful, without requiring an entire a…

It's a great point. To my mind scrum is actually a compromise aimed at selling agile into waterfall organisations. Apart from the flaws of scrum itself (too much process/waste), the two really big blockers are that it requires organisational change but is applied at a project level, and that good agile project leads/TPM's are way rarer than the good developers everybody says are impossible to find.

Re: Scrum seems to be mostly about having better alibis

#63

Post by Domenic_S » Mon, Mar 16, 2015, 5:22 AM UTC

quanticle wrote: post #59

einrealist wrote: post #48

Earlier quoted context omitted.

Why can research and prototyping not happen in Scrum? I don't see any limitation.

The problem is that research and prototyping is difficult to estimate even when you have a history of estimates. The advantages of scrum really kick in around sprint #4 or 5, when your team has a history of estimates that you can refer to when you're estimating future work items. In a research setting, this breaks down because the work for sprint N is totally different than the work for sprint N-1, which means that y…

> which means that you can't use the work logs from your previous sprints to estimate the next sprint's work.

But you're not supposed to do that anyway. Story points are always relative, so your tasks (in sprint) are relative to one another.

We always "effortbox" our research tasks into a set number of story points.

Re: Scrum seems to be mostly about having better alibis

#64

Post by Domenic_S » Mon, Mar 16, 2015, 5:28 AM UTC

RalfR wrote: post #25

matthewmacleod wrote: post #24

I actually started writing a point-by-point response to this, but it mutated into a thousand words and will be better suited to a blog post at some point in the future. In the meantime, I think these are generally the same shallow straw-man arguments against Scrum that we all see pretty frequently. I guess the key points to bear in mind will be: - Scrum is not a be-all and end-all solution to all product development.…

I value your opinion, even if I do not agree with it. The argument of "Scrum being poorly implemented" is brought again and again. It's just another one of these go-to killer arguments. If Scrum is so mega simple, why do we see endless cases of it failing to being implemented correctly? Maybe we should start thinking of a framework, that people can actually implement and make successful, without requiring an entire a…

> If Scrum is so mega simple, why do we see endless cases of it failing to being implemented correctly?

Just because something's simple doesn't mean it's got buy-in. It fails because implementers fail to get buy-in from people with power, and those people insist on keeping their pet processes in place.

Re: Scrum seems to be mostly about having better alibis

#65

Post by pacala » Mon, Mar 16, 2015, 5:57 AM UTC

marcus_holmes wrote: post #53

RalfR wrote: post #27

Earlier quoted context omitted.

Well, as far as I understood, Scrum's fundamental principle dictates that the team delivers working software at the end of every Sprint. This has partially to do with not over committing at the beginning, but if the team fails to judge correctly, it has to do what needs to be done to fulfil its promises. Unfortunately, this clear obligation gets forgotten to often – as I pointed out in the original post. You seem to…

I don't care what methodology you're using, if it includes crunch then it's broken. Proper, grown-up coding on a business application is incredibly wearying on the mind, and results have shown time and time again through research studies and professional management that past 8 hours coding in a day the average programmer's code quality starts to deteriorate. Past 10 hours it goes negative - at this point the code bas…

The next time I hear "crunch" from a PM type, I'll publicly invite him/her to lead by example and deliver a bunch of features over his weekend.

Re: Scrum seems to be mostly about having better alibis

#66

Post by gchpaco » Mon, Mar 16, 2015, 6:50 AM UTC

RalfR wrote: post #25

matthewmacleod wrote: post #24

I actually started writing a point-by-point response to this, but it mutated into a thousand words and will be better suited to a blog post at some point in the future. In the meantime, I think these are generally the same shallow straw-man arguments against Scrum that we all see pretty frequently. I guess the key points to bear in mind will be: - Scrum is not a be-all and end-all solution to all product development.…

I value your opinion, even if I do not agree with it. The argument of "Scrum being poorly implemented" is brought again and again. It's just another one of these go-to killer arguments. If Scrum is so mega simple, why do we see endless cases of it failing to being implemented correctly? Maybe we should start thinking of a framework, that people can actually implement and make successful, without requiring an entire a…

I'm reminded of the discussions about XP when it was newer. Lotta folks thought XP meant "cowboy away" and then got excited when it invariably didn't work--the original folks said "well, look, you're not doing the process; you can't blame it if you're not doing it".

Now the thing is this looks a hell of a lot like a No True Scotsman argument, especially if you're only glancing at it in passing. Yet, boundary setting is a legitimate thing to do; the XP folks had put up their lists of practices, etc. XP is/was very demanding, very tricky to do; it was an open question for a little while whether it was actually implementable by average organizations. The interface with the product owner was a particular issue, and is still in Scrum.

Put another way, when you say "Scrum says to do X" (say, very few meetings which should go quickly), and someone goes "Scrum sucks because we're constantly in meetings explaining why we're not getting any work done", and you say "You're not doing Scrum"... you have a point. Scrum teams are not supposed to be crunching; if the product has to ship by date X, then some of the features won't get in, and it's the product owner's _responsibility_ to say which ones those are. If the product owner says "I don't care these are all mission critical we can't discard any of them" then you're not doing Scrum, even if you have some highly educated boob with a certificate from some idiot making them a Scrum Ninja or whatever saying that you are!

Now, some of the practices are more important than others, and most of these frameworks say "you kinda need to be flexible, but try it first". So there are grey areas. And sometimes (as with XP) the existence proof that it is even possible to do the process is nontrivial. But kabuki-scrum (thank you, quanticle!) is a real thing.

Re: Scrum seems to be mostly about having better alibis

#67

Post by asgard1024 » Mon, Mar 16, 2015, 7:53 AM UTC

cc2 wrote: post #37

If you have no control over requirements and a bunch of people who can't work together towards a common goal, I'm not sure what, if any, methodology will work. The main complaints against Agile by developers are: 1) I want to hide in my technology rathole and never come out. 2) I'm allergic to accountability and can't take people asking me once per day what I'm up to. 3) I don't want to have to talk to other people.…

None of these complaints is in the original post, which I agree with - the things he talks about are problems of SCRUM. Also, AFAIK the standup is not about accountability, it's about communication.

Re: Scrum seems to be mostly about having better alibis

#68

Post by EdwardDiego » Mon, Mar 16, 2015, 8:04 AM UTC

paulhauggis wrote: post #57

EdwardDiego wrote: post #8

Scrum works well for my organisation. > While they just try to focus on building software, Scrum dragged them into seemingly endless series of meetings called Reviews, Retrospectives, Plannings and Dailies. This just caught my eye. The Scrum process as originally described had three meetings - one planning meeting per sprint, one retrospective per sprint, and one daily stand-up. It's a stand-up, as opposed to a sit-d…

I worked a remote job last year which used Scrum. We typically would have 2 hour stand-up meetings per day, A 3 hour retrospective meeting every week (usually Friday) and 4-5 hour meetings at the end of each sprint for figuring out what we were going to be doing for the next sprint (every 2 weeks). The business owner would many times be figuring things out as we went along during these 5 hour meetings..sometimes pain…

Yep, that sounds pretty terrible. To give you a contrast, our stand-ups take 10 minutes at worst, and our retrospectives take 3 hours every third Friday, and plannings are about 3 hours also, again once per three week sprint.

Re: Scrum seems to be mostly about having better alibis

#69

Post by asgard1024 » Mon, Mar 16, 2015, 8:07 AM UTC

killface wrote: post #52

codeshaman wrote: post #51

Earlier quoted context omitted.

Exactly my experience. Scrum is, above all, a system of controlling people. Although it's defined as 'an iterative and incremental software development methodology for managing product development', in reality it's a system for managing power distribution within an organisation and managing dissent. That is both a good and bad thing, depending on which perspective you want to take. Some people love the structure and…

yes, of course it's always the "creative types" -- they can't work in a team, they can't work anywhere except their own sound isolation booth, and they demand 22 continuous hours for 1 hour of flow, but they're somehow more productive... I'm so sick of everybody trying to cater to these crybabies. They can go work for the government or something.

Ah, dammit, those creative types! Why can't they just follow orders like everybody else? :-) (I haven't downvoted you, I am just explaining it.)

Re: Scrum seems to be mostly about having better alibis

#70

Post by einrealist » Mon, Mar 16, 2015, 8:08 AM UTC

quanticle wrote: post #59

einrealist wrote: post #48

Earlier quoted context omitted.

Why can research and prototyping not happen in Scrum? I don't see any limitation.

The problem is that research and prototyping is difficult to estimate even when you have a history of estimates. The advantages of scrum really kick in around sprint #4 or 5, when your team has a history of estimates that you can refer to when you're estimating future work items. In a research setting, this breaks down because the work for sprint N is totally different than the work for sprint N-1, which means that y…

If you cannot estimate something, then you should do it in a timebox over and over again, until you are satisfied. If my project requires lots of research and prototyping, I still have valid and useful options in Scrum.

For research, my team will have short sprints with timeboxed backlog items. The result of a research item can be a presentation of the discoveries and a vote / discussion on what to research next (sprint review). If my team's research isn't done within that timebox, the findings are presented anyway and the team / stakeholder may decide to simply file a new backlog item on the same topic for the next sprint. Or the incomplete result is a sign of complexity which can be split into many backlog items. Such items can be that the team decided to get external consultancy or a product presentation by a vendor.

If the team has to mix research with prototyping, it could do two types of sprints: short research sprints as explained above and longer implementation sprints for the prototype that are based on the research results. For example, the team may require two, one week sprints for doing research and then a two week sprint for implementing or continuing a prototype. At the end of each sprint (sprint review) there is a decision on whether the next sprint will be a research or a prototyping one.

So Scrum is still a valid method that enables a team to even steer research and prototyping efforts. This is where Scrum actually shines, because it gives you flexibility and transparency (!) in an uncertain environment.