Live data from Hacker News

Salmon-ladder development is not the way to do agile

blog.apterainc.com

1–10 of 23 posts

Re: Salmon-ladder development is not the way to do agile

#4
post #3

It's possible to start agile projects without requirements but with loads of user research and prototyping instead.

From the linked post:

  Before you start writing software, have at least one
  clear objective. You might call this a requirement, a
  user story, or a specification. Give the developers a
  target to shoot at. Otherwise, you will be swimming
  upstream.
Prototypes and research give you a target, even though they aren't "formal" (by some definition) requirements.

Even producing the prototypes meant you probably had some objectives unless someone just typed something out one day entirely on a whim.

Re: Salmon-ladder development is not the way to do agile

#5
I start all kinds of projects with minimal requirements. You obviously have to have something to start but I'll go into a meeting with a notepad and suss out what's need enough to get started.

In my opinion, true agile is rapidly getting code in the hands of users as quickly as possible. Then iterating on that. You don't need a lot of requirements to get started. But need to be not afraid of change! Things will change (maybe everything will change) and that's ok -- plan for change. This author starts with the implicit premise that change is bad and all conclusions are the result of that.

I've been involved in a few "Agile" projects implemented in hard-to-change platforms. And ultimately it's just disguised waterfall -- if you can't change the product then you're doing big planning up front.

Re: Salmon-ladder development is not the way to do agile

#6
I hate the term "requirements" with passion. It is almost always used by people without any vision or passion.

Why is it so unimaginable to create something without being able to articulate it beforehand? Or why wouldn't it be possible to start with something and letting it evolve by discovering new insights while building it?

How many successful things are really built by first writing down requirements?

Sometimes it is just an personal itch or curiosity. Other times it is actually total epiphany that brings success...

Re: Salmon-ladder development is not the way to do agile

#7
post #5

I start all kinds of projects with minimal requirements. You obviously have to have something to start but I'll go into a meeting with a notepad and suss out what's need enough to get started. In my opinion, true agile is rapidly getting code in the hands of users as quickly as possible. Then iterating on that. You don't need a lot of requirements to get started. But need to be not afraid of change! Things will chang…

> This author starts with the implicit premise that change is bad and all conclusions are the result of that.

Where in the article do you draw this conclusion from?

Change isn't bad. The article doesn't say change is bad. Change introduces complexities. And unclear or ill-defined objectives (aka, requirements) make change more likely.

Re: Salmon-ladder development is not the way to do agile

#9
post #5

I start all kinds of projects with minimal requirements. You obviously have to have something to start but I'll go into a meeting with a notepad and suss out what's need enough to get started. In my opinion, true agile is rapidly getting code in the hands of users as quickly as possible. Then iterating on that. You don't need a lot of requirements to get started. But need to be not afraid of change! Things will chang…

> This author starts with the implicit premise that change is bad and all conclusions are the result of that.

How did you come to that conclusion? The theme of what I was saying is that projects to be given direction from the stakeholders. I never said anything to suggest that the direction couldn't change.

Re: Salmon-ladder development is not the way to do agile

#10
post #6

I hate the term "requirements" with passion. It is almost always used by people without any vision or passion. Why is it so unimaginable to create something without being able to articulate it beforehand? Or why wouldn't it be possible to start with something and letting it evolve by discovering new insights while building it? How many successful things are really built by first writing down requirements? Sometimes i…

Let's get 50 people to all start writing a complex payroll system, or critical embedded medical device software, on the basis of their "personal itch" or "epiphany".

When a project or task is individual or trivial, then who cares. When not, a "hack it 'till it (hopefully) works" approach doesn't cut it.

Edit: grammar

Post reply on HN