You'd love this https://medium.com/modern-agile
Why I'm not a big fan of Scrum
291–300 of 387 posts
Re: Why I'm not a big fan of Scrum
#292Scrum proponents (a label I would tentatively apply to myself) would tell you that 'you're doing it wrong' but unfortunately a point-by-point reply to this article would detract from the general problem here: Scrum is intended to be the straightest line towards measuring your real progress on a project, and not much else If youre working on a project where it is important that you have as-accurate-as-is-realistic an…
I've seen the "you're doing it wrong" argument so many times (I applied it myself a few times). Scrum is complex and not always possible to follow exactly, so this is to be expected but it makes me wonder, how many successful projects are out there that are following the true Scrum methodology? My guess is that it's a few more than the classic waterfall but I still seem to see far more failure than success stories.
Successful big waterfall engineering projects where waterfall is actually applied exist. Want to construct a bridge or a rocket, design a microprocessor? You are not going to do that with "stories".
It remains to be seen if big Scrum engineering projects where Scrum is actually applied even exist. I can't even think about one on the top of my head. I'm not even sure Scrum is that well defined for us to be able to judge if is correctly applied or not. And it's yet another story to judge if they are successful or not.
In the end it does not matter much. The theoretical vision that nobody ever uses has almost no interest if you are concerned with real world efficiencies.
Re: Why I'm not a big fan of Scrum
#293I'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…
> the stories are always articulated in terms of user facing features
Reminder: the "User" doesn't have to be an external person to the team. It can be internal for tools, or a tech debt task for internal issues like the ones you mention.
Thinking Scrum is just about end/paying User stories is mistake #2 I see when people do Scrum (#1 is the classic "We're going to not actually do Scrum but call it Scrum" that leads to a lot of "Scrum doesn't work" articles itself).
Re: Why I'm not a big fan of Scrum
#294I'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…
It's a long time since I've had to deal with "strict" Scrummers. But I do remember being utterly baffled as to the insistence on user features being ready by the end of a sprint, even for quite complex, technical components. Why can't we make some sub-component this sprint then the UI bit the next? I tried various ways of reframing it such that the developer of the UI be the "user" but it didn't wash.
> I tried various ways of reframing it such that the developer of the UI be the "user" but it didn't wash.
Are you surprised? The developer isn't the user of the UI, product wise, so no wonder it didn't get very far.
The trick in this case is to break the story down. So the original story isn't do-able in one sprint? Ok, so what is actually the MVP of that Story? What's the first block that builds the overall feature? Take a 5 point Story and make it three 2 point Stories or something. That's what the refinement step is for in Scrum.
Unless you're doing abnormally short sprints there should be some part of that Story that can be abstracted into a smaller Story that fits into a sprint.
Re: Why I'm not a big fan of Scrum
#295Earlier quoted context omitted.
Modularize by functionality, not by layer. Start with a simple end-to-end path and grow outwards, rather than trying to go top-down or bottom-up, and don't split into distinct layers until you're actually deriving value from doing so. Writing code when you don't have the use case yet is always a bad idea.
I disagree. This is how you end up with messy code that needs constant refactoring. Making time to come up with a composable design shouldn't be that difficult. It usually isn't.
All code should be constantly refactored. This way your code gets refactored as the design changes (which... it will) rather than having to shoehorn an architecture that worked great originally into a set or requirements that have moved on.
Re: Why I'm not a big fan of Scrum
#296Earlier quoted context omitted.
I've seen the "you're doing it wrong" argument so many times (I applied it myself a few times). Scrum is complex and not always possible to follow exactly, so this is to be expected but it makes me wonder, how many successful projects are out there that are following the true Scrum methodology? My guess is that it's a few more than the classic waterfall but I still seem to see far more failure than success stories.
Successful big waterfall engineering projects where waterfall is actually applied exist. Want to construct a bridge or a rocket, design a microprocessor? You are not going to do that with "stories". It remains to be seen if big Scrum engineering projects where Scrum is actually applied even exist. I can't even think about one on the top of my head. I'm not even sure Scrum is that well defined for us to be able to jud…
> Successful big waterfall engineering projects where waterfall is actually applied exist.
You are engaging in equivocation.
> Want to construct a bridge or a rocket, design a microprocessor? You are not going to do that with "stories".
Nor are you going to use the software development methodology described as the waterfall method (you may use a physical engineering methodology that was among the inspirations for that software development methodology, but those are distinctly different things, with different specific practices, and different domains.)
> I'm not even sure Scrum is that well defined for us to be able to judge if is correctly applied or not.
Scrum is exquisitely well-defined, both as to what it involves, what it specifically excludes, and what it is neutral to, in the Scrum Guide. (There's lots of confusion between Agile, a broad approach which is not a specific methodology, and Scrum, a very-specifically-defined -- though by itself fairly incomplete, in that any implementation of Scrum needs lots of decisions on the things to which Scrum is neutral -- methodology.)
Re: Why I'm not a big fan of Scrum
#297Earlier quoted context omitted.
I disagree. Even among those who routinely write good code (all of us in our own minds) the schedule tends to pressure you to solve the problem before you, the one in the story, without checking if anyone else has solved similar problems already. What tends to happen is you write your own solution instead of finding the similar solution and generalizing it. Then, after a year you have have a dozen related tasks perfo…
This sounds like a bad organization of the team, bad process or bad design. Clearly team members don't communicate enough, or groups of similar features have not been foreseen during the design phase, and the same code has been rewritten again and again by different people. This is not contingent "technical debt", this is a serious problem that needs to be addressed with changes in the process.
organization of the team and process? You mean the scrum process? Indeed, my point. Of course one can argue that no true scrum process would have such problems...
Re: Why I'm not a big fan of Scrum
#298This was my favorite point out of them all: > What about contributing to open-source software? Reading the code of an important external dependency, such as the web framework your team uses, and working on bugs or feature requests to get a better understanding was not part of any Scrum backlog I've ever seen. Working at various startups, I have developed a methodology of contributing back to open-source projects we u…
[deleted]
Re: Why I'm not a big fan of Scrum
#299Earlier quoted context omitted.
I guess if you understand what is going on as a manager, then you might prefer the 10 points team? I know I do.
If you understand what is going on, you will get rid of points altogether, and look at the git log from time to time. If you are a leader, and not just a manager, you will help your programmers improve their skill, so over time you spend less and less time managing them. Your programmers will appreciate it because with greater self-management comes greater happiness and job satisfaction.
Totally. Some teams want the points though So I let them have it.
But I just set the principles I explained above for the points to have an actual meaning.
Re: Why I'm not a big fan of Scrum
#300Earlier quoted context omitted.
Because that two weeks you spent writing excellent code is mostly useless unless you have a way to get feedback on it. As a customer, you've given me no value. What if you finally hook up UI to the sub-component and the customer/stakeholder decides they don't like any of it? You could have known about it earlier.
The problem with this is that it imposes a membrane on the process that is only permeable to work that contains a shippable piece of user-facing software. It presupposes that all work can be divided into such pieces. And since that's not true, it leads to contorted stories to squeeze necessary work through that membrane.
> It presupposes that all work can be divided into such pieces.
No, it states the reasonable conclusion that all valuable features can be broken down into such (because otherwise if it adds no value to the product).
There are also Scrum tasks around Research, Tech Debt, etc that are perfectly fine to create and work on but they have an affect on your overall time to build new features and that's ok. Because it needs to be done, so they'll get prioritized accordingly.