Hacker News Reader

Comment by trickstra | Hacker News Reader

Agile is about reacting to changing requirements. If the requirements never change, then agile doesn't promise to be better than other methodologies. It came from a rapidly changing crashing markets in the .com bubble. How would the other methodologies fare if requirements changed two or three times in the middle of the project? That's when you need to be agile.

How did they even measure "success" if the requirements weren't given up front? What did they expect at the end?

View on HN

Agile means delivering very small increments to users at a frequent pace, allowing them to provide feedback early and often. When done correctly, this eliminates a significant amount of guesswork. However, if the client (or, indeed, your own team or management) does not fully understand the process, things can go spectacularly wrong in many different ways.

We still need to explain what "agile" is. Ask yourself why do we "need" to deliver small increments at frequent pace? Isn't it to be able to react to changes?

I thought I said it. Its main purpose is to eliminate guesswork.

It's main purpose is to react to changes, and make the whole process sustainable. It's literally one of the 4 main lines of the manifesto and the second of the 12 principles, and included in the meaning of the term "agile" itself, while guesswork isn't mentioned. But I can see how trying to predict what the markets will look like in 6 months involves a lot of guesswork, which is eliminated. I hope you can see that the only reason why guesswork is tricky is that there are a lot of changes in the meantime, so the ability to react to them is the deeper, actual main purpose.

I mean you are entirely discounting that it also allows engineers to pick their tasks and pace them as they see fit, as well as have input into the creation and prioritization of those tasks.

Everytime I hear an engineer complain about this, I ask them if you wish the PM would just write a PRD full of guesswork tasks and you execute on them unquestioningly.

Some engineers complain about having the ability to pick their tasks and have input in prioritization and planning? This has always been the most attractive part of agile for me. Self-organized team. Built around motivated individuals. Striving for technical excellence.

In forums almost every engineer that complains about agile to me then goes on to describe a deeply regimented waterfall system they are actually in.

The second common complaint is “I don’t want to do the hard work of giving input, just tell me what to code”.

This is why I hire students. I have to teach them my way before some other company ruins them forever.

I have never worked in an agile setup in which engineers pick tasks, we're given a queue and we take them in priority order with no room for choice.

How common is that really?

That sounds like Lean.

That's cargo scrum, very common disease. Teams without autonomy or self-organization. The queue should consist of higher level tasks, milestones, and the team should rework them into the small tasks that will actually go into sprints. Of course there is a motivation to pick the higher priority tasks first, but team members should be able to pick a task with which they can most efficiently contribute to the sprint goal, it's not always the top one.

Reply on news.ycombinator.com