Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scrum seems to be mostly about having better alibis

agileoverflow.com

Post reply on HN
Print view View original

71–80 of 87 posts

Re: Scrum seems to be mostly about having better alibis

#71

Post by asgard1024 »

DanielBMarkham wrote: post #10

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…

> 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 was most productive under well managed waterfall - where we had one longer status meeting each week, and instead of grooming interrupting work on the problem every week or so, we had time to think about the problem complexity at the beginning of the project.

In my view, the key to productivity in programming is focus. Whether you focus as a team or as a person doesn't matter. What is needed though is someone reliable who can shield you from all the distractions, and can do that without actually distracting you. In my experience with SCRUM, all the distractions are dumped onto developers (all of them in fact, via standup).

I am not against Agile development (in particular, just like author, I am not against iterative development or Agile manifesto), but the SCRUM I found rather silly. It's an attempt to do one-size fits all.

Not every feature requires exactly the number of people in the team. Not every feature requires one sprint of time. Some require less, some require more. If your work is managed correctly, you don't have worry about these arbitrary boundaries (which will always exist because time-boxing and standups, no matter how long the sprint or how big the team, are the key features of SCRUM).

Re: Scrum seems to be mostly about having better alibis

#72

Post by lmm »

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…

> Well, as far as I understood, Scrum's fundamental principle dictates that the team delivers working software at the end of every Sprint.

Working software yes. If you break the build the minute before the end of Sprint then yeah you better fix it. Sensible teams resolve this by not committing at the last minute, and by having the Sprint end at, say, midday Thursday, not 9AM on Monday.

> if the team fails to judge correctly, it has to do what needs to be done to fulfil its promises.

Nope. There are no promises, no "clear obligation". Half the point of the daily standups is that if a feature is not going to be deliverable in its original form within the sprint, you catch this early, and then you talk about it, you have contact with the product owner, and you decide something sensible.

Re: Scrum seems to be mostly about having better alibis

#73

Post by asgard1024 »

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…

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

I always have to wonder, if your problem was already solved, why don't you just buy off-the-shelf solution? If you aren't doing anything new, what is the point? It seems like you cannot organize the work correctly already! Frankly, if you have failed to use what was already done, no amount of management methods will help cover _that_ productivity screw up. :-)

Re: Scrum seems to be mostly about having better alibis

#74

Post by lmm »

drisco wrote: 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…

The reality is a lot of us are cogs in a machine. Anyone can make a CRUD webapp, and maybe I can do it 20% faster than someone else, with better craftsmanship that will make it easier to maintain, but fundamentally we're substitutable. Self-deception would upset me much more. I see standups as the opposite of micromanagement; they give me the opportunity to ask for what I need, and the format almost forces my manager to shut up and listen.

It does put a lot of emphasis on a single Product Owner, and there are downsides to that. For my money you get better products if one person takes responsibility for the decisions and you follow them consistently, even when on a local scale you have a better idea.

Re: Scrum seems to be mostly about having better alibis

#75

Post by einrealist »

asgard1024 wrote: post #71
DanielBMarkham wrote: post #10

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…

> 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 (put a signal on the board). Meetings have a single goal and having it as a ritual (culture) helps to accept it. My team is not always the exact amount of people. People get sick or have holidays or just migrate into other teams. If my team needs a specialist for something, we bring someone on board for the required time. But we also try to share knowledge and not to specialize, because that would be a risk (sickness, holidays, termination etc). We also learned to break down requirements into stories that are small enough, so we can reason about it. We understand Scrum as a foundation that we can agree on. And if we disagree, we figure out how to change the boundaries of Scrum so we can move on.

Re: Scrum seems to be mostly about having better alibis

#76

Post by UK-AL »

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…

Working software =! All the features committed. It means it should be useable, even if only half the features were complete.

Also next time you plan a sprint, you reduce the commitment.

Re: Scrum seems to be mostly about having better alibis

#77

Post by UK-AL »

RalfR wrote: post #30
einrealist wrote: post #26

Earlier quoted context omitted.

If you feel degraded by the version of Scrum your team is doing, then the team is doing it wrong or at least the retrospectives are not working. And if you want to make your own decisions, then you are probably better off alone. But that is not the fault of Scrum.

If almost everybody "is doing Scrum wrong", is it maybe because of its fundamentally bad design?

You only hear about that bad ones, there's plenty of good ones.

Re: Scrum seems to be mostly about having better alibis

#78

Post by cmdkeen »

asgard1024 wrote: post #73
quanticle wrote: post #45

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…

> Scrum is designed for software teams working in a well-known problem space I always have to wonder, if your problem was already solved, why don't you just buy off-the-shelf solution? If you aren't doing anything new, what is the point? It seems like you cannot organize the work correctly already! Frankly, if you have failed to use what was already done, no amount of management methods will help cover _that_ product…

Well known != well solved. It's the difference between "we need to build a web application to do X" and "we're going to redefine how people do X".

Secondly have you seen Salesforce? The COTS solution isn't zero configuration in many cases. Plus many businesses decide their unique selling point can be having bespoke software that has a feature that the COTS version can't do, or do as well.

I've just spent 3 years using SCRUM to build a CRM system after my employer decided not to go with Salesforce because they wanted everything to match up to how we do things. Plenty of other firms in our industry are extremely jealous of what we've produced because it is domain specific rather than over generalised.

Re: Scrum seems to be mostly about having better alibis

#79

Post by cmdkeen »

flurdy wrote: post #50
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…

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.

It also masks the problem in the retrospective - in my view the most important part of scrum. Developers put down positives for going above and beyond rather than being forced to admit, and therefore analyse, that the team failed.

I've found, though perhaps it is a British cultural thing, that there are plenty of things people sit on and don't mention out of politeness - they only come out after a particularly bad failure.

Re: Scrum seems to be mostly about having better alibis

#80

Post by br3w5 »

jghn wrote: post #7
br3w5 wrote: post #4

I think the OP's mindset is flawed and perhaps had some bad experiences/coaches with Scrum and possibly only one go at it? I'm not sure why anyone would say "Scrum doesn't want to solve this". When I've worked with teams new to Scrum and the question "how does this fit into Scrum?" comes up, I'll discuss with the team and we come to a pragmatic agreement that is right for the situation and context. Similar to TDD, I…

"but I definitely prefer it to waterfall" I pretty sure you're not doing this here, but there's a lot of options outside of the set of Waterfall & Scrum. All too often when scrum is debated it's often set up in the "well, at least it's better than waterfall!" argument. Great, that might be the case - I'd rather a kick in the ass than the nuts but really I'd prefer neither :) "the methodology too literally" As the say…

I think my statement about waterfall is misplaced - really I mean the benefits of scrum in my experience outweigh the negatives but I can't say the same for waterfall.

I'm well aware of alternatives to Scrum and if I could choose I would prefer a kanban approach supporting continuous delivery/deployment; rather than be bound by all the constraints of the scrum ceremonies and sprint timelines. Hopefully I'll get to put this into practice in the next couple of months with my team.

Post reply on HN