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

Re: Scrum seems to be mostly about having better alibis

#81

Post by asgard1024 » Mon, Mar 16, 2015, 10:48 AM UTC

einrealist wrote: post #75

asgard1024 wrote: post #71

Earlier quoted context omitted.

> It's that you need to realize that the enemy of productivity has been siloing people and specialists that want to hand-off their work to others. I think you're wrong. What you should realize that there are many enemies of productivity, and different for different people. For instance, for me, having useless meetings (like standups or groomings) is mentally exhausting, and it kills a lot of motivation for the day. I…

For me it is exactly the other way around. I hated those weekly 3hr status meetings. Sometimes, I fell asleep. And I hated that all the specifications had to be upfront, without flexibility for the team or the stakeholder. Nothing was more counterproductive than implementing a solution, that when I knew half-way in that it was flawed. With Scrum, if something bugs me, I bring it up. We do standups only if required (p…

Well, if my math is correct, 15 minute meeting every day still beats 3hr status meeting every week. Our status meeting was only about 0.5-1hr long, and we actually got a bit more done, because you're not supposed to go into detail during the standup.

Anyway, what you seem to praise is Agile (as per the manifesto), not SCRUM, and I agree (although some problems are actually suitable for upfront specification). Still, distractions can be a problem on the other extreme that needs to be managed too.

Re: Scrum seems to be mostly about having better alibis

#82

Post by brianfitz » Mon, Mar 16, 2015, 11:57 AM UTC

quanticle wrote: post #45

edwinnathaniel wrote: post #39

Earlier quoted context omitted.

This is an interesting remark: "Technology development is certainly tough. It's that you need to realize that the enemy of productivity has been siloing people and specialists that want to hand-off their work to others." What if the type of challenges that need to be solved involves: embedded device all the way up to cloud, big data, and devops automation where some of these things require specialties? Some sprints m…

>What if the type of challenges that need to be solved involves: embedded device all the way up to cloud, big data, and devops automation where some of these things require specialties? Then maybe Scrum isn't the best approach. Scrum (and agile methodologies more generally) are not designed to solve cutting-edge problems where it isn't even clear whether the product is possible, much less feasible, to build. Scrum is…

As a note, Scrum started outside of software development. It was created to deal with brand new problem domains with many unknowns.

Re: Scrum seems to be mostly about having better alibis

#83

Post by exelib » Mon, Mar 16, 2015, 3:41 PM UTC

Just my point of view:

I disagree with Ralf.

Scrum is here NOT to solving ANY of YOURS problems. It's like a car - it's give you ability to drive, but how you drive is up to you. If you can't drive - you drive nowhere. If the street is broken - you can't drive, too.

What Scrum do, based on it's pillars (Scrum Theory, http://www.scrumguides.org/scrum-guide.html), is ability (and force you) to solve your own problems. Not more. OK, there are some preventive things and some sort of problems just don't happen with Scrum (if you can drive, of course), but it's not goal of Scrum.

And because, I think, there is no alibis at all. It's just disability to drive.

/Scrum Master && Developer, who fight against large organization every f* day for ability to drive/

Re: Scrum seems to be mostly about having better alibis

#84

Post by quanticle » Mon, Mar 16, 2015, 10:13 PM UTC

einrealist wrote: post #70

quanticle wrote: post #59

Earlier quoted context omitted.

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

That actually sounds like a really neat process and I'm glad it works for you. One question I have is about how you measure velocity with variable length sprints. My understanding of scrum is that the point of having fixed length sprints is that it lets you easily estimate how much you can deliver in a sprint, since each sprint is the same length.

If you have different length research and implementation sprints, how would you estimate the amount of work (whether in story points or whatever else) that can be done in a given sprint? Is it a matter of making sure to compare "like to like"?

Re: Scrum seems to be mostly about having better alibis

#85

Post by GFischer » Mon, Mar 16, 2015, 11:59 PM UTC

pacala wrote: post #65

marcus_holmes wrote: post #53

Earlier quoted context omitted.

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.

Be careful what you wish for... I know several PM types that can match you insane hour per insane hour - some had skin in the game (part ownership), others were just overzealous and I know at least one burned out.

Re: Scrum seems to be mostly about having better alibis

#86

Post by lambeosaurus » Tue, Mar 17, 2015, 12:32 AM UTC

Hominem wrote: post #43

I am not a coach or trainer. I am just a developer trying to remain sane. I tend to believe that any thoughtful process can work as long as you stick to it. It just so happens I do agile/scrum. I believe that at its core, agile is about two things. Planning on a shorter time frame so you can react quickly as unknowns surface, and continuously improving your process. The ceremony is meant to achieve those two things.…

Thank you. I think you're correct. It's not about making our jobs easier - it's about making a better product.

Re: Scrum seems to be mostly about having better alibis

#87

Post by giaour » Tue, Mar 17, 2015, 1:24 AM UTC

asgard1024 wrote: post #81

einrealist wrote: post #75

Earlier quoted context omitted.

For me it is exactly the other way around. I hated those weekly 3hr status meetings. Sometimes, I fell asleep. And I hated that all the specifications had to be upfront, without flexibility for the team or the stakeholder. Nothing was more counterproductive than implementing a solution, that when I knew half-way in that it was flawed. With Scrum, if something bugs me, I bring it up. We do standups only if required (p…

Well, if my math is correct, 15 minute meeting every day still beats 3hr status meeting every week. Our status meeting was only about 0.5-1hr long, and we actually got a bit more done, because you're not supposed to go into detail during the standup. Anyway, what you seem to praise is Agile (as per the manifesto), not SCRUM, and I agree (although some problems are actually suitable for upfront specification). Still,…

That assumes a 15 minute meeting only steals 15 minutes from your day. It's usually closer to an hour once you factor in the work-free buffer zones surrounding it. (Cf http://www.paulgraham.com/makersschedule.html)