Working with non-existing specs. Just have to pick a guess what arguments and columns that will be needed. Right now it feels like I'm up to a very fuzzy task, that will need to be done over and over again until it gets right, instead of doing it right once and for all. If this is agile, then agile is a waste of time!

Why would it be better if someone else guessed what the specification should be ?

If someone else has information you don't you need to talk to them, it is when the path is unclear that agile shines, you get something (a MVP) done quickly, test it out and then scrap, improve or change direction based on feedback (preferably feedback from real users).

Non agile methods tend to result in bad or overly complex specifications (because no one really knew what was needed when it was written) and then a bad or far too expensive product is built based on the specification.

@ItsNotMyFault Because if that someone else specified what data that is needed it wouldn't be a *guess*, he -*knows* what is needed.

Yeah, I would also like to talk to that someone, but he is busy all day. Agile only works if the system owner is available.

@illusion466 and @ItsNotMyFault This is a common misconception, that agile would equal no documentation at all. This is exactly one of the reasons why so many turn against agile.

Don't get me wrong. I like agile. I'm absolutely pro agile, but you have to do it right, otherwise it just becomes a buzzword rectifying any poor processes as long as they are "agile".

Of course you shall not *over*-document or be *too detailed*, and in its best form, agile means just enough documentation to get you going.

In this case we have *no freaking documentation at all, not even a stub of a requirement spec*. That quite frankly doesn't work. I think that we're doing agile the wrong way.

@TerriToniAX I never said no documentation, i said that you should never be handed a specification.

If you get a specification then its not agile, that is waterfall. (sprints, standups, kanban boards, etc don't make you agile)

Optimally management only sets goals in terms of achieved effect.
"Enable the company to sell its products on the web",
"Increase conversion rate by X%"
etc.

The team should decide how to reach those goals and document those decisions, if the team doesn't understand the business well enough to make good decisions then the team needs to add that competence.

@ItsNotMyFault OK, yes it's a difference. All that sounds very nice in theory, but in practice I need some sort of requirements, otherwise the functions I'm implementing will be rather thin.