I'm not sure I understand the first complaint; no where in the official guide is the word "points" or "story points" mentioned. I've worked on at least 2 Scrum teams that didn't use story points. All the stories were broken down until they were all of approximately the same effort and then we planned sprints based on number of PBIs.
Why I'm not a big fan of Scrum
71–80 of 387 posts
Re: Why I'm not a big fan of Scrum
#72For our dev team Scrum works fine, the key is to use it just as a framework, and not following every rule to the letter. For example: - Obsession with points We don't have that obsession, sometimes we even don't assign story points, just hour estimates - Meeting extravaganza - Again, for example remote people don't need to attend all meetings, sometimes we just clarify the work items outside the meetings. - The sprin…
"I just move new item from backlog to sprint and work on it." - This breaks traditional scrum estimating.
Yes and No. Scrum estimating is done with 2 independent metrics: Velocity and Task Hourly Estimate.
Obviously adding something to the Spring is going to hide the fact that you fucked up at Spring Planning. However, as the author said, very few people actually care about task estimate. ( and often team don't even care about breaking stories into task at all, using story == task ) And in any case, unless you are using postits and manual tracking, any tool will just track the estimate alright for you, the information is there if you want to process it.
Velocity is supposed to change from sprint to sprint, getting better as you are better at assigning story point. You can lose SP when you fuck up a story, you can gain extra when you put additional stuff from the backlog. Velocity once more or less stable is supposed to give an idea of a release date.
However considering that you don't break down big stories and epic into smaller stories until you are about ready to implement them, the uncertainty on the release date is more like 6 months vs 2 years vs 10 years. Management make a big deal of it but really that's how you budget most of the time anyway: I need "3 FTE for 6 months or 3 FTE for the year, to be reevaluated at budget cycle per budget cycle".
Most of OP problem actually started really when Scrum Master became a job. I remember something like 10 years ago being all exited how Jira could make very precise report of velocity and estimate and my very experimented coach looked at me as if she had seen the Demon. Scrum is about keeping a supertanker on track in a tempest and those amazing reports gives the illusion of a nimble sport car racing on a track.
Re: Why I'm not a big fan of Scrum
#73I've been doing Scrum-driven development for a few years now after working much more independently for most of my career. I understand why managers like it because it at least lends some structure and predictability to what is an inherently unpredictable enterprise. But the author's criticisms of the incentives of Scrum are on point I think. Because the stories are always articulated in terms of user facing features…
In my view the only way to handle this is to make constant refactoring part of the work without telling management. If you ask for permission for refactoring you will almost always get a "No".
Indeed. That's sometimes the case with other stuff like playability too. I've added simple animations which delighted users from time to time.
If I had asked beforehand to invest time for this, the response would be "let's postpone this (forever)".
Re: Why I'm not a big fan of Scrum
#74Scrum/Agile-English Dictionary http://reddragdiva.dreamwidth.org/594955.html
But with our new Silver-Bullet Development Methodology™, it's a completely new world where none of your decades of experience apply! This changes the nature of development forever!
p.s.: we sell certifications!
(repeat for a new Silver Bullet roughly each decade)
Re: Why I'm not a big fan of Scrum
#75Earlier quoted context omitted.
In my view the only way to handle this is to make constant refactoring part of the work without telling management. If you ask for permission for refactoring you will almost always get a "No".
This is mentioned in the article as possible only for small changes. When the refactoring involves more systemic problems, it becomes impossible to make the change in the course of making other client-facing changes. I'll add that some subsystems are a mess but stable. It's difficult to make refactorings with other changes when there aren't other changes to make. I see this in particular with old but stable subsystem…
> I see this in particular with old but stable subsystems that will need to be ported to new environments someday, but it's never a good day to lay the groundwork for that inevitable change.
I think it's correct to defer that work until you need it. You may end up never porting that subsystem, in which case refactoring the currently-stable implementation is wasted effort. As and when porting becomes an actual business requirement it can be prioritized appropriately.
Re: Why I'm not a big fan of Scrum
#76managers like it. control. results. evaluation. they get to treat programmers like laborers. programmers don't really have anything to gain with it. what surprises me, is that sometimes programmers ask for it. it illustrates how strong the desire is to follow the latest trend.
Re: Why I'm not a big fan of Scrum
#77I've been doing Scrum-driven development for a few years now after working much more independently for most of my career. I understand why managers like it because it at least lends some structure and predictability to what is an inherently unpredictable enterprise. But the author's criticisms of the incentives of Scrum are on point I think. Because the stories are always articulated in terms of user facing features…
In my view the only way to handle this is to make constant refactoring part of the work without telling management. If you ask for permission for refactoring you will almost always get a "No".
Can't do that for deep refactoring. You'll need QA involved and the boss will never sign off on that because, well, he's a boss not a proper manager.
Re: Why I'm not a big fan of Scrum
#78do we see bank analysts playing 'planning poker' when it comes to putting together pitch decks or research analyses? no. and they'd transfer out of any group where a manager tried to implement such a practice. if a software engineer is more than a couple years out of college, i don't think she/he should put up with it either.
> do we see bank analysts playing 'planning poker' when it comes to putting together pitch decks or research analyses? no. and they'd transfer out of any group where a manager tried to implement such a practice.
More fool them if so. I think pg said something along the lines of "unprofessional is what you say when you don't like something but don't have any real criticism".
Re: Why I'm not a big fan of Scrum
#79I've been doing Scrum-driven development for a few years now after working much more independently for most of my career. I understand why managers like it because it at least lends some structure and predictability to what is an inherently unpredictable enterprise. But the author's criticisms of the incentives of Scrum are on point I think. Because the stories are always articulated in terms of user facing features…
I've been in situations like this, and when I've brought up techdebt issues, I get "YAGNI". I've tried to frame technical debt issues in terms of how it will impact future feature requests, performance, etc, and YAGNI is what normally comes back. Until... they actually NI. Then it's a hair on fire crisis. Fortunately have not been in that type of situation for years, but I know they still happen.
Re: Why I'm not a big fan of Scrum
#80Earlier quoted context omitted.
In my view the only way to handle this is to make constant refactoring part of the work without telling management. If you ask for permission for refactoring you will almost always get a "No".
Why is management getting involved? The PO should try to balance this with feature impementation and the team + SM should make it clear when it's needed. This seems to work fine in an environment based on collaboration between PO,SM and dev team, but will probably fail in an adversarial one.
Because managers have to report to other managers and they don't want to report that the devs are working on something that already has been implemented and "works".