Skip to main content
added 287 characters in body
Source Link

IMHO, Waterfall doesn't suit any development, it comes from the construction industry, where redoing something is impossible (or at least, extremely expensive). But to software, redesigning and rewriting is cheap, and it is extremely preferable to review the specs continuously.

OTOH, Agile requires all team members to have approximately the same experience, and teams should be small, otherwise it adds considerable communication overhead. When the experience levels are disparate, it wastes a lot of time for the most experienced.

The approach I've used most, and which I have experienced as more effective, is to have no defined structure at all.

At first, projects require the most talented and skilled ones you can get, to have good foundations. You generally have nothing else to do, just put this people on the project and wait a few days, soon they will start organizing everything; it's the power of nature.

Just having the right people on the right place does the trick. Look for natural leaders (those everyone hates, yet loves). Once the thing starts to move they will switch into guardian-mode to keep things sane, and it will catch speed.

(Well, I admit there is an implicit structure, but it's highly dynamic)

The point is: development consists almost entirely (from this point of view) in social interactions, something extremely complex and resilient to careless intervention, so any attempt to design social interaction is doomed. The only thing we can do about it is to influence, slightly.

IMHO, Waterfall doesn't suit any development, it comes from the construction industry, where redoing something is impossible (or at least, extremely expensive). But to software, redesigning and rewriting is cheap, and it is extremely preferable to review the specs continuously.

OTOH, Agile requires all team members to have approximately the same experience, and teams should be small, otherwise it adds considerable communication overhead. When the experience levels are disparate, it wastes a lot of time for the most experienced.

The approach I've used most, and which I have experienced as more effective, is to have no defined structure at all.

At first, projects require the most talented and skilled ones you can get, to have good foundations. You generally have nothing else to do, just put this people on the project and wait a few days, soon they will start organizing everything; it's the power of nature.

Just having the right people on the right place does the trick. Look for natural leaders (those everyone hates, yet loves). Once the thing starts to move they will switch into guardian-mode to keep things sane, and it will catch speed.

(Well, I admit there is an implicit structure, but it's highly dynamic)

IMHO, Waterfall doesn't suit any development, it comes from the construction industry, where redoing something is impossible (or at least, extremely expensive). But to software, redesigning and rewriting is cheap, and it is extremely preferable to review the specs continuously.

OTOH, Agile requires all team members to have approximately the same experience, and teams should be small, otherwise it adds considerable communication overhead. When the experience levels are disparate, it wastes a lot of time for the most experienced.

The approach I've used most, and which I have experienced as more effective, is to have no defined structure at all.

At first, projects require the most talented and skilled ones you can get, to have good foundations. You generally have nothing else to do, just put this people on the project and wait a few days, soon they will start organizing everything; it's the power of nature.

Just having the right people on the right place does the trick. Look for natural leaders (those everyone hates, yet loves). Once the thing starts to move they will switch into guardian-mode to keep things sane, and it will catch speed.

(Well, I admit there is an implicit structure, but it's highly dynamic)

The point is: development consists almost entirely (from this point of view) in social interactions, something extremely complex and resilient to careless intervention, so any attempt to design social interaction is doomed. The only thing we can do about it is to influence, slightly.

Source Link

IMHO, Waterfall doesn't suit any development, it comes from the construction industry, where redoing something is impossible (or at least, extremely expensive). But to software, redesigning and rewriting is cheap, and it is extremely preferable to review the specs continuously.

OTOH, Agile requires all team members to have approximately the same experience, and teams should be small, otherwise it adds considerable communication overhead. When the experience levels are disparate, it wastes a lot of time for the most experienced.

The approach I've used most, and which I have experienced as more effective, is to have no defined structure at all.

At first, projects require the most talented and skilled ones you can get, to have good foundations. You generally have nothing else to do, just put this people on the project and wait a few days, soon they will start organizing everything; it's the power of nature.

Just having the right people on the right place does the trick. Look for natural leaders (those everyone hates, yet loves). Once the thing starts to move they will switch into guardian-mode to keep things sane, and it will catch speed.

(Well, I admit there is an implicit structure, but it's highly dynamic)