But the major issues I have with waterfall is this – requirements change – you will never have 100% perfection and clarity up-front. Plus, most smaller companies can't afford such large overhead at the outset of a project. In addition, people need to talk regularly. Some developers in the waterfall mindset just want everything spelled out for them so they don't have to think; that's a bad sign. You want developers thinking – they are very smart people.

And, more importantly – you need people talking and discussing things. Asking questions instead of assuming what the requirements say is right, even if they think it's wrong or misplaced. The people writing requirements are not always right, and the rest of the organization can't expect them to be. In heavy waterfall organizations, you can inevitably end-up with perpetual finger-pointing in that scenario.

If a developer feels a “crystal, crisp, and clear” requirement sucks and is wrong, many times they will implement it anyway. Why? Because when it comes back to them as being a bug, it's easier to say, “I coded this to spec – that's a requirements bug” then it is for them to get up, ask the question, engage in the discussion, and maybe alter the requirement if necessary.

Conversely, the person writing requirements can argue, “well just because I made a typo or overlooked something that's common sense doesn't mean the developer doesn't have a responsibility to ask. That's a coding bug.”

It's much easier to just foster communication and teamwork than writing huge amounts of requirements documentation and throwing it over a wall.

But the major issues I have with waterfall is this – requirements change – you will never have 100% perfection and clarity up-front. Plus, most smaller companies can't afford such large overhead at the outset of a project. In addition, people need to talk regularly. Some developers in the waterfall mindset just want everything spelled out for them so they don't have to think; that's a bad sign. You want developers thinking – they are very smart people.

And, more importantly – you need people talking and discussing things. Asking questions instead of assuming what the requirements say is right, even if they think it's wrong or misplaced. The people writing requirements are not always right, and the rest of the organization can't expect them to be. In heavy waterfall organizations, you can inevitably end-up with perpetual finger-pointing in that scenario.

If a developer feels a “crystal, crisp, and clear” requirement sucks and is wrong, many times they will implement it anyway. Why? Because when it comes back to them as being a bug, it's easier to say, “I coded this to spec – that's a requirements bug” then it is for them to get up, ask the question, engage in the discussion, and maybe alter the requirement if necessary.

Conversely, the person writing requirements can argue, “well just because I made a typo or overlooked something that's common sense doesn't mean the developer doesn't have a responsibility to ask. That's a coding bug.”

It's much easier to just foster communication and teamwork than writing huge amounts of requirements documentation and throwing it over a wall.

But the major issues I have with waterfall is this – requirements change – you will never have 100% perfection and clarity up-front. Plus, most smaller companies can't afford such large overhead at the outset of a project. In addition, people need to talk regularly. Some developers in the waterfall mindset just want everything spelled out for them so they don't have to think; that's a bad sign. You want developers thinking – they are very smart people.

And, more importantly – you need people talking and discussing things. Asking questions instead of assuming what the requirements say is right, even if they think it's wrong or misplaced. The people writing requirements are not always right, and the rest of the organization can't expect them to be. In heavy waterfall organizations, you can inevitably end-up with perpetual finger-pointing in that scenario.

If a developer feels a “crystal, crisp, and clear” requirement sucks and is wrong, many times they will implement it anyway. Why? Because when it comes back to them as being a bug, it's easier to say, “I coded this to spec – that's a requirements bug” then it is for them to get up, ask the question, engage in the discussion, and maybe alter the requirement if necessary.

Conversely, the person writing requirements can argue, “well just because I made a typo or overlooked something that's common sense doesn't mean the developer doesn't have a responsibility to ask. That's a coding bug.”

It's much easier to just foster communication and teamwork than writing huge amounts of requirements documentation and throwing it over a wall.

But the major issues I have with waterfall is this – requirements change – you will never have 100% perfection and clarity up-front. Plus, most smaller companies can't afford such large overhead at the outset of a project. In addition, people need to talk regularly. Some developers in the waterfall mindset just want everything spelled out for them so they don't have to think; that's a bad sign. You want developers thinking – they are very smart people.

And, more importantly – you need people talking and discussing things. Asking questions instead of assuming what the requirements say is right, even if they think it's wrong or misplaced. The people writing requirements are not always right, and the rest of the organization can't expect them to be. In heavy waterfall organizations, you can inevitably end-up with perpetual finger-pointing in that scenario.

If a developer feels a “crystal, crisp, and clear” requirement sucks and is wrong, many times they will implement it anyway. Why? Because when it comes back to them as being a bug, it's easier to say, “I coded this to spec – that's a requirements bug” then it is for them to get up, ask the question, engage in the discussion, and maybe alter the requirement if necessary.

Conversely, the person writing requirements can argue, “well just because I made a typo or overlooked something that's common sense doesn't mean the developer doesn't have a responsibility to ask. That's a coding bug.”

It's much easier to just foster communication and teamwork than writing huge amounts of requirements documentation and throwing it over a wall.