
Salmon-ladder development is not the way to do agile - pottereric
http://blog.apterainc.com/salmon-ladder-development-is-not-the-way-to-do-agile
======
wvenable
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.

~~~
pottereric
> 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
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
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
This is not a software development process issue. If management is bad,
doesn't understand the process, and there isn't buy in then the project will
fail. Take that same team and same management and do it waterfall and I doubt
the outcome would be any different.

But it is not just management that is at fault. Those developers did not have
enough backbone to push back. Instead of educating management about the
process or telling them it can't be done they just sulked back to their
cubicles and coded. There is no surprise it turned out wrong.

I see where you're coming from on this; you cannot build any product without
communicating with the stakeholders. That communication can be rough scribble
diagrams, notes, detailed requirements, meetings showing off prototypes --
really anything. All software development processes are about communication.

~~~
mannykannot
> this is not a software development process issue... [followed by a list of
> software development process issues.]

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

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

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

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

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

