Forced to take a "course" on agile. "Course" meaning 6-7 150 minutes sessions of uselss blabber. Fucking hell this is exactly like the worst of college courses.

Such a massive waste of time.

Giving my honest, somewhat filtered opinion in the dev group, I am in the minority it seems.

"But it's such a great opportunity!"
"<MANAGEMENT GUY> really pulled some strings to get us this course and I am fully confident in <MANAGEMENT GUY>'s criteria."

FFS, he's not in this chat. You won't get a raise by brown nosing him this hard you twit.

  • 3
    anything agile is hell, mostly because people have no clue what they're doing
  • 2
    @darksideofyay Just management having the wool pooled over their heads by "scrum masters speakers" (bunch of snake oil salesmen), leading to developpers having to spend an inordinate amount of time in these useless talks.

    Give me a break with this "It's a culture thing" BS. I'll work with Agile if the company is doing Agile. I'll work with SCRUM if the company does SCRUM. I have no say in this. So fuck off with these courses that won't be implemented.
  • 0
    @nitnip i mean, agile is worse if people don't learn it properly, but some of those courses are a bunch of nonsense
  • 1
    @darksideofyay This course is a bunch of nonsense. The fact people from very different department (sales, it and others) are made to take the SAME course in the SAME conference call already spells disaster...
  • 1
    Well it's good that you have an open mind
  • 3
    Agile is what’s supposed to make working relations between tech people and non tech people go smoothly; so it’s not totally surprising that the courses are taken by both audiences on the same call. The real problem is when agile is entirely controlled (held hostage) by non tech people.
  • 1
    @black-kite I sometimes feel agile takes the workply as an assembly line for code
  • 0
    Nobody, and I mean nobody follows true agile.

    It can empower or enslave a dev team though.

    Sounds like the latter in your case.

    Make sure your takeaways are:

    Points are determined by the dev team, not management.

    Points are NOT a performance metric because they are constantly evolving with the dev team. (Just because story A will take 5 points and story B will take 2 points for the same technical results doesn't mean that B was easier.)

    Management does not set the development agenda, they set the deliverable expectation. "We need feature A done by x date is this possible?"

    Good luck.
  • 1
    I don't have anything against Agile, or any other methodology, except that I've never seen any of them yield better results than just working out what needs to be done and divvying the tasks out. They're great at first, give you a real sense of working to a process, until the first time they collide with reality, at which point it goes to shit.

    Devs are generally really difficult to manage, about the worst thing you can do is make them feel that people who don't really understand their jobs are telling them how to do it, and Agile just formalises that into a process.
  • 1
    @sariel Points? Points?! Well yeah, you make a fair point. Too bad that in 150 minutes "points" never even came up. It's gonna be a long course, eating away at my monday afternoons.

    Fuck it, I'll just use the wireless headphones, unplug my camera and do something else while this agile man prattles on about the History of Agile next monday.
  • 0
    @eo2875 well, it is based on a cards system used in japanese factories to have control over the product
  • 0
    Agile was introduced with 'senior professionals'

    .. in the founding times of computer science.

    (e.g. a professional software engineer had a background in physics math or another field.)

    If such a person commited to a deadline a whole lot of experience and knowledge was behind this commitment.

    If you try to do push people with a lose focus and not enough experience (e.g. about hidden costs as increased maintenance through missing tests) to use agile, they will not be able to achieve the desired results.

    I believe the main requirement for working agile is, that the team is able

    - to act responsible

    - manage time (e.g. the same job a management would do)

    - deliver quality work/software (= giving space to non-functional requirements beside new features)
  • 1
    As an update, the course is now over. The last session had us playacting a sprint.

    It wasn't only useless, it was absolutely cringe-worthy.
Add Comment