5 ms·

Salmon-ladder development is not the way to do agile

19 points by pottereric 9y ago

coldcode 9y ago
Also don't start a project with a highly detailed list of requirements and estimates and a hard deadline and call it agile either. Sadly we do.
benilov 9y ago
It's possible to start agile projects without requirements but with loads of user research and prototyping instead.
- Jtsummers 9y ago
  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.
wvenable 9y ago
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.
- Jtsummers 9y ago
  > 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.
- pottereric 9y ago
  > 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.
  - wvenable 9y ago
    Is it actually a problem that you've seen in real life where programmers write code without any direction? That seems impossible. A program exists to solve a problem. You might have a pretty vague idea of the details of that problem but ultimately you know what it is. If programmers are coding whatever they want based on wildly unfounded assumptions then they're not doing Salmon Ladder development -- they're just terrible developers. If they're given some direction, coding, and iterating on that result then that's great. Even if they make some wrong assumptions at first, I don't see anything wrong with that.
    - pottereric 9y ago
      It is a problem I've seen in the real world. For example, I've seen a project where upper management tasked a team of developers with writing software and didn't give the team specific direction nor did they communicate clear goals for the software. The team asked for more details, and the management told them to "do it agile". The team wrote good software, but they solved the wrong problem.
      - wvenable 9y ago
cateye 9y ago
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...
- aryehof 9y ago
  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
- bsg75 9y ago
  If its a "personal itch or curiosity", sure. If its a business process, lack of any form of requirements is how technical debt is guaranteed from the start.
graphememes 9y ago
Needs an example and some diagrams, otherwise, it's just words. "Don't start without requirements" Depends on if you even know what the requirements are, some projects are just an idea.

19 points by pottereric 9y ago

Also don't start a project with a highly detailed list of requirements and estimates and a hard deadline and call it agile either. Sadly we do.

benilov 9y ago

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

Jtsummers 9y ago
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.

wvenable 9y ago

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.

Jtsummers 9y ago
> 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.
pottereric 9y ago
> 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.
- wvenable 9y ago
  Is it actually a problem that you've seen in real life where programmers write code without any direction? That seems impossible. A program exists to solve a problem. You might have a pretty vague idea of the details of that problem but ultimately you know what it is. If programmers are coding whatever they want based on wildly unfounded assumptions then they're not doing Salmon Ladder development -- they're just terrible developers. If they're given some direction, coding, and iterating on that result then that's great. Even if they make some wrong assumptions at first, I don't see anything wrong with that.
  - pottereric 9y ago
    It is a problem I've seen in the real world. For example, I've seen a project where upper management tasked a team of developers with writing software and didn't give the team specific direction nor did they communicate clear goals for the software. The team asked for more details, and the management told them to "do it agile". The team wrote good software, but they solved the wrong problem.
    - wvenable 9y ago

cateye 9y ago

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...

aryehof 9y ago
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
bsg75 9y ago
If its a "personal itch or curiosity", sure. If its a business process, lack of any form of requirements is how technical debt is guaranteed from the start.

graphememes 9y ago

Needs an example and some diagrams, otherwise, it's just words. "Don't start without requirements" Depends on if you even know what the requirements are, some projects are just an idea.