Earlier quoted context omitted.
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…
However, many companies face similar issues. For a moment I thought the OP worked for my company because we face the same issues (that's not possible however because in person stand ups are banned at our company due to the distributed nature). 1) While I agree that 20 people seems like too large a team in general, I have a fundamental problem with the idea that scrum can determine what size team is right. What seems…
Scrum is fragile, not Agile
91–100 of 329 posts
Re: Scrum is fragile, not Agile
#92Earlier quoted context omitted.
Scrum won out because it was waterfall in disguise. Commitments and sprints become terribly destructive over time.
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…
"Fortunately," hardly anyone in Silicon Valley plans to be working on the same codebase in a few years. There's a good chance the problem space won't be relevant anymore by then, and on the off chance it's still funded, the new team will rewrite it whether or not it's good.
>sprints are too short for devs to sneak refactoring into the schedule.
As I've gotten more senior, I've just gotten more brazen about doing this less sneakily.
Re: Scrum is fragile, not Agile
#93There's a set of practices here in Seattle that I've come to call Skragile, which evinces the veneer of of Scrum, Kanban, and Agile, but embraces very little of the fundamental philosophies. The most distinctive characteristics: - daily standups (often one per day per team so multiple per person) - sprint based development cycles, often with retrospectives - fondness for the "as an X I want to Y" story - story points…
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 circle to where the new generations of programmers have delegated (or lost) all discipline to managers' Scrum plannings.
Managers and "product owners" aren't engineers or programmers. They shouldn't be expected to "manage" a developer's day-to-day, and yet them presiding over sit-down-stand-up meetings and demanding points and determining deadlines and features is precisely what it has come to. We are right back where we were when the manifesto was drafted.
Re: Scrum is fragile, not Agile
#94Earlier quoted context omitted.
> Daily standup, nobody wants to be at. We have multiple teams arrive, with roughly 20 people in a small room It is central to the idea of the daily standup is that it is one team . > Its limited to 15 minutes, so nobody says much of importance, and just parrots what is already on the Jira board. If you have another mechanism for sharing what each person has done and is doing, then the standup should just be for shar…
> As long as you are also doing backlog grooming and have items groomed beyond the current sprint commitments, you can take additional items opportunistically, if there is excess capacity after doing the committed items properly. The powers that be at my work decided that “sprint predictability” is the most important metric here. This means that if we pull in stuff near the end of the sprint but don’t finish, predict…
I also think speculative future make-believe planning junk should be kept out of the real getting-shit-done tool. Put it in there when it actually matters. There should be no "on ice" or "phase 3" (when in "phase 1") crap in the tool the devs use. It may or may not make sense to have them involved in planning stuff that early, but keep the output of that planning away from the real-work trackers until it's closer to time to do it.
I think that's part of why Jira (and similar, heavy, report-focused tools) is so god-awful. It not only tries to have features for teams to get stuff done and for five other roles to dig around in tasks and reports for whatever reason, it enables and encourages that, and I'm fairly sure, at this point, that it's fundamentally a bad idea.
Re: Scrum is fragile, not Agile
#95At 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…
If your daily stand-ups are just repeating the JIRA board, then just give people back their time. If your features are coming out badly designed, then stick a designer in the engineering pods, or call out the design phase in project lifecycle.
If your projects are consistently late, then... slow down the estimates!
Of course teams that do it right tend to know this, but the bad implementations of scrum I've seen consistently lack attentive iteration on the process itself.
Re: Scrum is fragile, not Agile
#96Earlier quoted context omitted.
Managers need to justify their jobs. Reading off a slack report every day seems too simple and not worthy the salary they're paid. Compare that to a large meeting and live status updates, everyone stands, etc. Now that is some "serious work" happening. Think of it from the point of view that managers have mangers they report to. When shit goes wrong they have to cover their asses. "So it's late. But did you check on…
It's not like it's a requirement that "managers" be at a standup meeting. Some of the best teams I've worked on have done daily standups without managers, and I dare to say most of us enjoyed them and found them productive!
Re: Scrum is fragile, not Agile
#97Re: Scrum is fragile, not Agile
#98Earlier 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…
>I think it works well enough, for a few years. "Fortunately," hardly anyone in Silicon Valley plans to be working on the same codebase in a few years. There's a good chance the problem space won't be relevant anymore by then, and on the off chance it's still funded, the new team will rewrite it whether or not it's good. >sprints are too short for devs to sneak refactoring into the schedule. As I've gotten more senio…
Re: Scrum is fragile, not Agile
#99I don't really have that much industry experience but have been reading a lot about development processes and practices. It seems there just isn't one development process that will solve all your problems and allow you always create successful software. To me it seems you just need to find what works for your team and continuously work on improving on it. What might work today, probably won't work for your team tomor…
> find what works for your team
For the combination of team and project. Different software projects need to take very different tradeoffs in how they managed. Use scrum in aerospace for flight control, and people will die. Use scrum for system software, and you'll have hard time delivering quality and performance, system software often requires non-trivial amount of engineering. Implement NASA's best practices when working on videogame or web app, and you'll blow budget.
This article is from 2002 but still good: https://www.joelonsoftware.com/2002/05/06/five-worlds/
Re: Scrum is fragile, not Agile
#100Earlier quoted context omitted.
And scrum? TPS is explicitly an influence on scrum.
Scrum is just an instance of the agile manifesto. TPS/Lean > Agile > Scrum. Kanban for example is another instance of the agile manifesto.