@redezem @virtualwolf none of those complaints are about Agile: https://www.atlassian.com/agile/manifesto

> Manifesto for Agile Software Development
>
> We are uncovering better ways of developing software by doing it and helping others do it.
>
> Through this work we have come to value:
>
> Individuals and interactions over processes and tools
>
> Working software over comprehensive documentation
>
> Customer collaboration over contract negotiation
>
> Responding to change over following a plan
>
> That is, while there is value in the items on the right, we value the items on the left more.

Seems more like legitimate complaints about Scrum :🤷

@redezem

Yup!

@redezem What a load of shit.

1: Requirements change all the time because customers don't know what they want, because analysis is hard, and because people gain more insight as the project progresses.

2, 4, 5, 6: Only incompetent managers put too much stock in estimations. It's useful for a team to have an idea of complexity, but only for deciding a very rough planning.

3: That's not a thing. Go home, you're drunk.

7, 8: This is just retarded high school humour.

@redezem @basbebe This is a rambling opinion & not arguments.

I was working in a functional and very much reflected #Scrum process for four years and it worked really good although a #waterfall process would have been possible as well. Each team had its own way.

You need to have an #agile expert who doesn't follow religious spells but really understands the core of agile to come up with a customized process that fits the situation. Mostly that is the issue at hand. 🤷

#softwaredevelopment #xp

@redezem All I can say is that it works for us.

The point of agile isn't to get it done faster, its to get it done right with faster feedback. The military have this concept of the OODA loop, which needs to be as short as possible to let you react to new information. Agile has the same idea.

No, requirements are not meant to change, but the reality is that users cannot envisage the new software and how they will work with it. Waterfall blames the user for that. Agile works with the reality.

@redezem

The team I worked on tried to introduce Scrum. The main problem was that the guy who got appointed as Scrum leader (coordinator - head honcho or whatever) never turned up much before midday and the daily meetings were held at 09:00. So the guy who was supposed to be hosting them was never there!

He should have been fired for abysmal timekeeping but that didn't actually happen until 2 years later when the management finally realised he wasn't actually doing the hours he was claiming!

@redezem I quite like Agile (per the manifesto), but Scrum is awful.

Edit: Software estimation is a fool's game.

https://agilemanifesto.org/

@redezem
I actually really like an agile-lite process where every team has:

* one 45+ minute weekly meeting to plan and discuss work
* 3 - 5 short meetings each week to stay in touch and get support
* one retrospective every 2 weeks

That said, everything in the meme is accurate. Point estimates are sooth saying. Velocity is nonsense. A well-organized team can mostly stay operational with async chats and occasional ad-hoc meetings to do design and solve problems. When devs drive the process it can work. When product or project managers try to run things it becomes an exercise in management.

@redezem That’s too easy. Scrum is a /tool/. Tools don’t solve your problems, they just empower /you/ to do so.

If you don’t get your planned stories done, then that’s an information Scrum provides you with. So you gain transparency, but also the responsibility to act.

Use your retros. Start experiments. Plan less. Try out swarming.

Introducing Scrum doesn’t magically relieve you from your pain. It puts the finger into the wound and makes you scream.