Live data from Hacker News

Scrum seems to be mostly about having better alibis

agileoverflow.com

51–60 of 87 posts

Re: Scrum seems to be mostly about having better alibis

#51
post #20

My experience with scrum is that it is degrading to developers - it tries to turn developers into interchangeable cogs in the machine, filled with micromanagement (aka 'daily standups') and puts to much decision making power into the hands of the 'Product Owners'. I'm a grown up, i can make my own decisions, i can talk to clients (in fact, i want to - no that, is not a distraction), and I don't need anyone looking ov…

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 team consensus that scrum produces, others are choked by the religious/dogmatic nature of the system.

I guess the more creative types are struggling most with scrum, because they feel like they are not working at their full potential and hence feel like 'cogs' in the system.

Re: Scrum seems to be mostly about having better alibis

#52
post #20

My experience with scrum is that it is degrading to developers - it tries to turn developers into interchangeable cogs in the machine, filled with micromanagement (aka 'daily standups') and puts to much decision making power into the hands of the 'Product Owners'. I'm a grown up, i can make my own decisions, i can talk to clients (in fact, i want to - no that, is not a distraction), and I don't need anyone looking ov…

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.

Re: Scrum seems to be mostly about having better alibis

#53
post #27

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…

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 base is actually being damaged.

"doing what needs to be done to fulfil the promise" is actually alerting the team that you've made a poor estimate of the effort required for this feature and need to recalibrate. It is absolutely not sticking with your poor estimate and delivering shoddy code to the project.

Re: Scrum seems to be mostly about having better alibis

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

"I don't care what methodology you're using, if it includes crunch then it's broken."

Rather than saying it is broken, it needs to be said that the team needs to improve. Continuous Improvement, it's where it's at.

Re: Scrum seems to be mostly about having better alibis

#56

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…

Can you recommend any good books on kabuki-scrum?

Re: Scrum seems to be mostly about having better alibis

#57

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 painfully slow.

This was all for a 5 person dev team. I was consistently billing more hours for meetings than actual coding work. At one point, the owner decided to have a meeting every Friday to just "hangout" where we would either tell a joke or a story..to "get to know each other" (this was another hour). I was the only American working for the company. The rest of the team was from India, Mexico, and Egypt.

To give you an idea of the work environment, one of the other remote employees kept overwriting all of our git checkins. They never figured out who it was (I'm not sure why), but I had to re-do all of my checkins for 3 weeks. It was complete chaos.

I finally quit when my business started making enough for me to survive without it.

The icing on the cake was when the owner changed the name of the LLC a few months ago, so all of my shares became worthless.

Re: Scrum seems to be mostly about having better alibis

#58

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…

"Scrum is designed for software teams working in a well-known problem space"

More narrowly, it's for problems which can be broken down into more or less independent "features". It's not too helpful if you're building something which doesn't do anything useful until all the parts are working. The Scrum mindset is to first build a flashlight app, then add features.

(If only that were a joke.)

    Flashlight app with an EULA, a privacy policy, and ads.[1]
    Flashlight app with in-app purchases.[2]
    Flashlight app with spyware.[3]
[1] https://play.google.com/store/apps/details?id=goldenshoreste...

[2]https://itunes.apple.com/us/app/light-led-flashlight/id37975...

[2]http://www.komando.com/apps/3112/turn-your-phone-into-a-flas...

Re: Scrum seems to be mostly about having better alibis

#59

Earlier quoted context omitted.

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

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 you can't use the work logs from your previous sprints to estimate the next sprint's work.

Re: Scrum seems to be mostly about having better alibis

#60

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…

Much as I dislike scrum and find it anti-agile, the author seems unaware that official scrum docs removed the word 'commitment' years ago because it was misunderstood as more than a target and misapplied just about everywhere.
Post reply on HN