Live data from Hacker News

Scrum seems to be mostly about having better alibis

agileoverflow.com

41–50 of 87 posts

Re: Scrum seems to be mostly about having better alibis

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

>it has to do what needs to be done to fulfil its promises.

No. Scrum is explicitly open to renegotiation. This is where burn-down charts come in to play. This is where having the product-owner be part of the team comes into play. If a feature is costing a lot more hours than anticipated due to unforeseen problems, it is expected that the team gets the product owner involved early so that a decision can be made: do we drop other work to deliver this feature, or do we drop other features to deliver this?

The core premise of scrum and other agile methodologies is that given the uncertainties inherent in software development, it is impossible to fix both the featureset and the schedule. Scrum fixes the schedule and explicitly allows for flexibility in the featureset. Other methodologies (like spiral, for example) fix the featureset and allow for flexibility in the schedule. Waterfall attempts to fix both, and fails as a methodology.

Re: Scrum seems to be mostly about having better alibis

#42
post #35

Earlier quoted context omitted.

We fail because it is about people interacting with each other. We fail, because we were trained to work on our own and competitively. We fail, because we have trouble to change our mindset and have even more trouble to change the minds of others. This is why we will fail at alternatives to Scrum, too. Scrum requires a different mindset. It requires us to work in a team with honesty and jointly in order to be success…

In other words: Scrum would work in Utopia?

Do you live in Utopia? How do you get around in your environment?

Scrum is not a solution that you buy off the shelf and just run in your company. It is a framework to manage work and scope in a team. And it acknowledges that we are individuals who have to interact with each other in order to achieve success. Both aspects are equally important and have to be addressed. Scrum will not make problems disappear. But it helps you to manage them in a transparent and controlled fashion.

Don't you live in an environment with rules (law) and frameworks (social culture)? Is that environment perfect? I guess not. That's why we deal with imperfections on a daily basis. Like we have to do when living Scrum.

Re: Scrum seems to be mostly about having better alibis

#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. If you are are doing the rituals, and fail to achieve those two things, I can see how it would seem worse than useless.

Here is what they don't tell you, it doesn't make software development easier. In fact, it can make it harder. What it does for me is make it sustainable and sane.

Re: Scrum seems to be mostly about having better alibis

#44

I love collecting these rants. For a long time, I've been convinced that various techniques may be fine and dandy, but the way we implement change in organizations sucks . Fair disclosure: 1) I teach/coach Agile/Lean/Kanban/Scrum, and 2) I couldn't care less about brand names and religious dogma. I'm a developer first. If it works, do it. Having said that, this author does not know what he is talking about. Apologies…

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…

A good friend of mine exclusively helps embedded teams. I just got through doing cloud with some folks. Big data is its own thing, but certainly not a show stopper.

If you're serious, email me. Happy to explain to any depth you find adequate.

Re: Scrum seems to be mostly about having better alibis

#45

I love collecting these rants. For a long time, I've been convinced that various techniques may be fine and dandy, but the way we implement change in organizations sucks . Fair disclosure: 1) I teach/coach Agile/Lean/Kanban/Scrum, and 2) I couldn't care less about brand names and religious dogma. I'm a developer first. If it works, do it. Having said that, this author does not know what he is talking about. Apologies…

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 designed for software teams working in a well-known problem space (e.g. line-of-business web applications) where the challenges are organizational (getting a clear set of requirements and managing requirements churn) rather than technical.

I certainly wouldn't expect a scrum team to deliver software for a brand new problem domain. For something like that, I'd expect better results from something like spiral, which explicitly includes room for research, experimentation and prototyping at each stage.

Re: Scrum seems to be mostly about having better alibis

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

Turning developers into interchangeable cogs is the holy grail of project management. It's the motivator behind most methodologies and also a large part of the motivation for many development frameworks (J2EE comes to mind, for one).

Unfortunately this has about as much chance of working as trying to develop an assembly line manufacturing process where every product is unique. It's not possible. People keep trying though.

Re: Scrum seems to be mostly about having better alibis

#47
Slightly off-topic. Does anyone know the origin of this (frankly weird) terminology of scrum "master and "coach"?

Merits of the actual methodology aside, I just have to admit that it rubs me the wrong way. Is it really that necessary to indicate that most places don't have scrum-like qualities in their processes, and require someone certified to "teach" or "coach" it to them?

Re: Scrum seems to be mostly about having better alibis

#48

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…

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

Re: Scrum seems to be mostly about having better alibis

#49
post #47

Slightly off-topic. Does anyone know the origin of this (frankly weird) terminology of scrum "master and "coach"? Merits of the actual methodology aside, I just have to admit that it rubs me the wrong way. Is it really that necessary to indicate that most places don't have scrum-like qualities in their processes, and require someone certified to "teach" or "coach" it to them?

I think they were trying to come up with new words for the role of "Project Manager" and "Process Consultant" that didn't sound so waterfall-y.

Re: Scrum seems to be mostly about having better alibis

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

Once a team starts to work overtime and weekends to finish stories (on its own accord or by instruction) then the value of your velocity measurement is shot to pieces. Predicting and committing to future sprints is then a complete guesswork (or rather even more of a guesswork..) when bad committal is masqueraded with pulling a rabbit out of hat.
Post reply on HN