Earlier quoted context omitted.
Real Scrum has never been tried.
True Scrumunism? :)
Scrum is a cancer
361–370 of 486 posts
Re: Scrum is a cancer
#362I must live in some kind of alternative reality where 80% of teams that I worked with liked Scrum (and I lead tens of teams). The remaining teams just needed Kanban. Not sure what everybody else is doing here, but I have seen teams where before we started doing scrum+jira all tasks were coming on Skype and discord, and stakeholders were either micromanaging (programmers managed by non-programmers) or either would for…
I'm one that prefers Kanban myself. List each task, be able to group those tasks, move those tasks to whoever needs them, move those tasks to QA or wherever finished tasks go. So, I prefer Trello over Jira any day
Re: Scrum is a cancer
#363For me scrum is daily 10min meeting and that's it
and I like it, I don't have problem with one quick meeting to sync.
But when I hear stories about estimations in some imaginary units, then it sounds bad.
Re: Scrum is a cancer
#364In one of my previous projects I lead a team of 5 talented and creative people and we did truly agile programming: everyone helped each other, asynchronous meets as needed, spontaneous pair programming, direct access to the customer (who also happened to be technical people with a clear picture in mind)... Truly a joy of a team to lead, because they really lead themselves :) However, the management insisted that we a…
> Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master Well, if there was a distinct Product Owner and they delegated this to the Scrum Master, it may have been by-the-Guide Scrum, but just extraordinarily poor judgement. But it sounds like you had a dev team that wasn’t using Scrum, got a Scrum Master…
In the same way, I don't particularly care if Scrum fails because people consistently fail to implement it "right" or if it fails because it's a flawed concept at its heart. Either way, odds are that my team will suffer if we introduce Scrum: if Scrum isn't fundamentally flawed, it's still hubris to assume that we'll be the team that finally gets it right.
[0]
> “Listen, if tomorrow we pulled into Biren and someone told you there were shamble-men in the woods, would you believe them?” My father shook his head.
> “What if two people told you?” Another shake.
> Ben leaned forward on his stump. “What if a dozen people told you, with perfect earnestness, that shamble-men were out in the fields, eating—”
> “Of course I wouldn’t believe them,” my father said, irritated. “It’s ridiculous.”
> “Of course it is,” Ben agreed, raising a finger. “But the real question is this: Would you go into the woods?”
Re: Scrum is a cancer
#365I still chuckle a bit when people get anti-scrum, because I've been around long enough when agile/scrum was the disruptive thing. Of course in practice agile/scrum/whatever has turned into the same cargo-cult nonsense that the original promoters of the ideals were fighting against. One thing I thought was interesting was: > First, the most common jobs among the people who told me I was wrong were "Agile Coach" and "S…
Re: Scrum is a cancer
#366Earlier quoted context omitted.
Ah yes the defence: "The process failed because you didn't have enough project managers on board" No the process failed because it was fucking shit and everyone went somewhere else. The only good thing heavy processes are for are propping up employment statistics.
Have you ever seen the movie Office Space? There’s a bit about “TPS reports” where multiple managers individually correct the main character on a new cover sheet. I’ve experienced that myself. The movie portrays it comedically but IRL it’s kind of a demoralizing experience. A bit soul crushing actually.
Re: Scrum is a cancer
#367Earlier quoted context omitted.
This "waterfall had all this effort go into a product only to get feedback at the end" was Winston Royce's own diagnosis of the problem with the waterfall model he formalized. That's part of it. In more practical terms, assigning people to tasks tactically as a project progresses is probably 80% of the advantage of Agile. You are also spot on that you can start an Agile project and find your architecture is a pile of…
Here is Royce's statement on his own waterfall model's risks: I believe in this concept, but the implementation… is risky and invites failure. … The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the stan…
Re: Scrum is a cancer
#368I've seen (and managed) plenty of Scrum, good and bad. In general I prefer Kanban approaches, but I don't think it's the deciding factor in team performance by itself.
I'm interested to see when we reach the point where it's no longer the default methodology everyone reaches for because "Scrum is how you do agile".
Re: Scrum is a cancer
#369I still chuckle a bit when people get anti-scrum, because I've been around long enough when agile/scrum was the disruptive thing. Of course in practice agile/scrum/whatever has turned into the same cargo-cult nonsense that the original promoters of the ideals were fighting against. One thing I thought was interesting was: > First, the most common jobs among the people who told me I was wrong were "Agile Coach" and "S…
I'll say this: I worked in XP (and then "agile") teams ~20 years ago a couple times with varying success, but the one good thing was it got people thinking and agitating against the delusions that went along with waterfall.
Then I got stuck at Google for 10 years, where "agile" isn't really a thing. (There are teams that are sorta doing scrum... ish stuff. And there's a wide diversity of how things are done there. But on the whole Google has effectively unlimited budgets and headcount so things sorta just ... broken down waterfall ... until they're "done" whenever). When I got out... Scrum or some variant had taken over.
And I don't recognize this as the "agile" I worked with before. It's just a mess of pointless routines and shiboleths without the meat of what made things "agile".
Agile was: developers do their own estimates. Short iterations. "Stories" are 2-3 days and tied directly to a customer's business request. Intense involvement with the "customer" letting them know the trade-offs for every decision. Ship the prototype. "You ain't gonna need it." Informal daily standup just for the purpose of making sure everyone is on the same page. At the end of the iteration, go over the "cards" and triage and discuss why some estimates were off.
What I see now is just going through the motions of some of these, but in the end it's either chaos, or waterfall in disguise and some PM with a hard-on for configuring JIRA in some convoluted fashion so they can pass on reports to their superiors and make people jump through hoops so it looks like progress.
I just wanna code, get things done, fix things and ship things. Agile was the recognition that (good) engineers want to get work done and the upfront design process was often just getting in the way of problem solving and the creative process. The ones who don't? Get them off your team.
Somewhere along the line that message was lost.
Re: Scrum is a cancer
#370Earlier quoted context omitted.
I'm one that prefers Kanban myself. List each task, be able to group those tasks, move those tasks to whoever needs them, move those tasks to QA or wherever finished tasks go. So, I prefer Trello over Jira any day
How do you "prefer kanban"? Don't all these methodologies use kanban boards?
1. Be pull based - someone only picks something new up when they have the capacity to do so. There's no "finish this set of tasks by the end of the sprint" because there are no sprints, just priorities
2. Manage work-in-process, either explicitly or implicitly. This prevents the team working on too many things at once, which leads to any given piece of work taking a long time to get to production