Salmon-ladder development is not the way to do agile
blog.apterainc.com
Salmon-ladder development is not the way to do agile
1–10 of 23 posts
Re: Salmon-ladder development is not the way to do agile
#2Re: Salmon-ladder development is not the way to do agile
#3Re: Salmon-ladder development is not the way to do agile
#4It's possible to start agile projects without requirements but with loads of user research and prototyping instead.
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
#5In 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
#6Why 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
#7I 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…
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
#8"Don't start without requirements"
Depends on if you even know what the requirements are, some projects are just an idea.
Re: Salmon-ladder development is not the way to do agile
#9I 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…
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
#10I 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…
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