Earlier quoted context omitted.
Scrum is iterated waterfall. By iterating faster, inaccurate estimation is shown up sooner. On the other hand, developers are treated like cogs in a feature factory, munching through backlog items fed to them by product managers. I think it works well enough, for a few years. I don't think it's sustainable - the blinkers of "sprints" encourage growth of tech debt because nobody has an eye on the future and Product wo…
> Scrum is iterated waterfall. No, it isn't. Iterated waterfall is at least as old as the first paper discussing waterfall, but while scrum mandates interations, it doesn't mandate much about how work is done in the iterations, and specifically does not mandate the process steps associated with waterfall; further, it emphatically rejects the role separations and handoffs associated with waterfall during the iteration…
Scrum is fragile, not Agile
141–150 of 329 posts
Re: Scrum is fragile, not Agile
#142Earlier quoted context omitted.
Scrum won out because it was waterfall in disguise. Commitments and sprints become terribly destructive over time.
> Commitments and sprints become terribly destructive over time. Could you elaborate?
Re: Scrum is fragile, not Agile
#143Earlier quoted context omitted.
Scrum is iterated waterfall. By iterating faster, inaccurate estimation is shown up sooner. On the other hand, developers are treated like cogs in a feature factory, munching through backlog items fed to them by product managers. I think it works well enough, for a few years. I don't think it's sustainable - the blinkers of "sprints" encourage growth of tech debt because nobody has an eye on the future and Product wo…
The biggest problem with Scrum is it lacks any sort of design phase. You do the minimum. Oh, it doesn't work quite right? We'll fix it in the next sprint... The "spiral" model is closer to a true iterated waterfall. I've seen it used successfully in more mature companies.
Re: Scrum is fragile, not Agile
#144Re: Scrum is fragile, not Agile
#145Earlier quoted context omitted.
Scrum is iterated waterfall. By iterating faster, inaccurate estimation is shown up sooner. On the other hand, developers are treated like cogs in a feature factory, munching through backlog items fed to them by product managers. I think it works well enough, for a few years. I don't think it's sustainable - the blinkers of "sprints" encourage growth of tech debt because nobody has an eye on the future and Product wo…
> Scrum is iterated waterfall. No, it isn't. Iterated waterfall is at least as old as the first paper discussing waterfall, but while scrum mandates interations, it doesn't mandate much about how work is done in the iterations, and specifically does not mandate the process steps associated with waterfall; further, it emphatically rejects the role separations and handoffs associated with waterfall during the iteration…
Re: Scrum is fragile, not Agile
#146In the early 1990s, Ken Schwaber used what would become Scrum at his company, Advanced Development Methods; while Jeff Sutherland, John Scumniotales and Jeff McKenna developed a similar approach at Easel Corporation, referring to it using the single word Scrum.
Re: Scrum is fragile, not Agile
#147He's not wrong. Having been involved in the Agile movement since before the term Agile was coined, I think of Scrum as the least interesting of Agile processes, but also the most successful in terms of adoption. I used to think that was a contradiction. Now I think it's almost inevitable. I wrote more about it elsewhere [1], but the basic deal is that most companies have other priorities than being effective, so the…
yes, I too was involved with XP before it was under umbrella of Agile which got consumed by the Scrum borg. I feel we kind of lost something where creating code/designs using strong feedback loops was a "first class citizen with royal honors" of the software development process. Scrum kind of makes it a sideline issue, a peon of middle management
My dad started developing in the late 1960s. He did a lot of in-house software, mainly manufacturing and insurance systems. His approach was to go out and see something in use, talk to the people using it, go back to his office, write something, release it, and go talk to the people again. He'd do that loop in as little as a couple of days.
Today we'd call that obviously agile. But both back then and now, higher-ups wanted more "control", by which they meant feelings and appearance of control. Which caused longer feedback loops. Which made things more out of control, which required more process and even longer feedback loops.
I think we have the same struggle today, and I have no idea how to get out of it.
Re: Scrum is fragile, not Agile
#148At the company I work at, we have the following scrum anti-patterns. I wish I knew, whether we could "do scrum right" or just move onto something simpler (fta; priority queue) * Daily standup, nobody wants to be at. We have multiple teams arrive, with roughly 20 people in a small room. Some people stand, some people sit. Sometimes the front-end team goes, sometimes the back-end team goes. Its limited to 15 minutes, s…
First of all, most issues with process issues are more a reflection of the organization and what drives them than the process. I would say you should start talking about, 'Our process' instead of 'Scrum'. >These things combined have dragged down the happiness of the people I work with, but we all feel imprisoned by it. I have a stack of scrum books here I plan on reading, I figure this process isn't going away and I…
I don't agree. For us the scrum master is a fixed position who has as a responsibility to advise the teams on how to fix problems with their processes or to help build these processes in the first place. This works very well for us, because the scrum master is explicitly only an adviser.
Meaning I, as a team lead, do not have to do what the scrum master says, but I always have someone experienced with scrum who I can ask when problems arise or when the team wants to change the processes.
Re: Scrum is fragile, not Agile
#149Earlier quoted context omitted.
This is pretty typical elsewhere too (midwest US as a data point). Its popular because managers can implement it. Agile- the manifesto version- was intended as a way to re-introduce the notion of discipline that newer generations of programmers had lost (where previously they were engineers and scientists who wrote code, now people who code exclusively eithout other backgrounds). It feels like we have come full circl…
The irony is, when I first saw Agile/Scrum, I thought of it mostly as a tool to provide discipline further up the chain rather than down. User stories? Oh, a neat way to keep requirements general and open-ended so we can properly address how we're actually going to solve a user's problem. Surely it'll prevent PMs from over-specifying requirements that lose sense of true objectives. 2 week Sprints? Cool, estimates are…
Probject managers and product owners were kept at arms length in the sense that they didn't dictate how, what or when we did what we did. They translated the business requirements and timelines into something we could understand and react to.
Somehow, all of that turned into two week sprints that felt sustainable... At least until the company bought out another company, and everything went downhill. That, however, is a story for another time.
Re: Scrum is fragile, not Agile
#150In my current team, we post our daily status on a slack channel: what we do yesterday and we are going to do today. We try to keep to one or two points. We have remote people so that works out well. Standup is optional. On Monday meetings, each person tell one thing that we are going to do. Sometimes it is two things but the point is to focus.
Meetings should only be between business / leads to get scope onto canvas.
If I'm blocked I'll seek out the person who can most help me. I can easily find 5-10 minutes to write out a summary, but on my terms when I'm not in coding mode.
Now, I'm freelancing, likely to be team lead for the company assuming they get financing - and I keep taking notes and reading ways to organize better. We have a ton of work to do, it's a financial mobile app that has 0 tests on the api (I'm single-handedly running the API development Laravel + vue (for some web views)). Money is tight so I'm the only dev on web side and we have 1 ios dev.
The hope is to be full-time at this by Christmas w/ a 6 figure salary (my first +6 figures).