[crdoconnor]

I think methodologies could benefit by being treated like software, since that's effectively what they are - 'human' software to manage teams. That means:

* Frequent releases (i.e. do iterations or 'sprints' or whatever).

* Accept that your methodology has bugs and 'fix' those bugs between releases. Most software is horrible and buggy. Don't trust the "methodology gods" that they wrote a perfect piece of working software. It's probably half assed and worked semi-well for their specific use case so they 'released' it along with a reality distortion field.

* Accept that different use cases require different methodologies. Writing space shuttle code? You need vastly different team dynamics to a group of 10 people at a marketing agency running short lived campaigns.

* Follow the UNIX philosophy: don't have ONE methodology that you follow to a T - string together a bunch of small, self-contained rules and team processes that serve your purposes and iterate upon them.

tl;dr fuck scrum. it's the internet explorer of methodologies.

[deanCommie]

Scrum is great for non-software companies that need to write software.

They will not attract the most talented software developers (on average, not in all cases), and the business people for whom the software is a means to an end care more about consistency and predictability rather than quality.

As a result, fungible resources (humans), deeply regimented stories, regular delivery milestones (sprints), and consistent velocity IS the best possible outcome.

[crdoconnor]

Scrum is not 'great' in any sense of the word.

I don't think it really matters what kind of company you work for. I've worked for many software and non-software companies and the same issues crop up in both.

The main one is that scrum accelerates the accretion of technical debt, which "business people" can somehow not care about right up until the point where it drives them out of business.

It has some good ideas (retros, sprints, no deadlines) and some terrible ideas (treating team members as fungible, story pointing/velocity, too many meetings, PO has to make decisions about specific pieces of tech debt).

My main problem with it is the teachers, coaches and promoters who take an all or nothing view of it and who treat deviations from the official 'scrum' policy as, by default, problem with the team rather than, potentially, a bug in SCRUM.

I used to think that it was a good base to work from, but after arguing fruitlessly with the people who take a religious approach to it I've come to the opinion that it just needs to be trashed wherever possible, because the problems it does have will only be resolved by moving on to something else. Better to move on sooner rather than later.

So, fuck scrum.

[user5994461]

Scrum is just a todo list. The issue is the commercial services teaching and selling that todo list to make money on everyone.

https://thehftguy.com/2017/12/06/scrum-vs-kanban-arent-they-...

[GordonS]

What's the issue with story points and velocity? I've been using them for years and personally I think they're some of the best parts of agile!

[crdoconnor]

Your team's velocity going up can mean that:

* Your team did more work this week.

* Your team worked more efficiently this week.

* Your team inflated its story point estimations this week.

Any one or all of those things could have happened in varying degrees.

Given all of that, what useful knowledge is it actually supposed to impart?

The best part is the number of story points / velocity can vary wildly depending upon what the team believes the measure is being used for.

[GordonS]

In my experience, if you track velocity long enough, and 'categorise' the values based on things like team size, technology etc, you get values that are useful to predict how much work you should commit to in an iteration.

Yes, things change: productivity, moral, team members join and leave, some teams are shit at estimating etc - but at least in my experience if you take an average you do arrive at a useful figure.

[crdoconnor]

In my experience if you have some sort of measure that looks a bit like productivity then senior management will latch on to it and treat it as a proxy for productivity.

That inevitably means that developers have an incentive to inflate their estimates, which means story point inflation.

Averaging does not fix this dynamic.