Hacker News new | past | comments | ask | show | jobs | submit login

Care to elaborate a bit? I think it would be very helpful for me and some others.



matt_s gets it right.

you need to produce requirements, make a design, create plans, implement code, test, deploy and all that -- it's the same if you're doing waterfall or agile, you're just sequencing these activities in time differently.

if you look at the project management body of knowledge (PMBOK) you find a comprehensive list of things that have to be done to make a project happen and this list isn't any different for agile or waterfall... it's just the answers for how certain things are done (communications in the team) for instance are different.

One advantage of agile is that all phases of project management are going on in each cycle, so you don't run into the problem that now you're testing after five years of doing everything else and now you don't have any idea how to do it.

On the other hand, you can screw everything up in an agile project the same way you can in a waterfall, although the symptoms show up differently. Since you're testing every phase of the process, problems will show up earlier. However, it's easy for people to miss them.

In an agile process, for instance, you can plan a sprint and accomplish the goals you set for the sprint and feel like you're doing a great job. However, the sprints might never end and the product never gets delivered. All your PM tools tell you're winning all the battles but you're still losing the war.


The key difference, IMO, is that true agile doesn't require overt project management or more importantly, project managers. the usual response to the "wining battles, losing war" is to introduce someone who's keeping track. unless that someone is "everyone on the team", you tend to move away from agile because:

a)its not everyone's problem, so its not going to be fixed, or

b)the pm guy becomes the fountain head of knowledge from the pmbok that guide the "one true way"


if a project goes beyond a certain size, somebody has to be in charge. you could build, say, the Dallas Cowboys stadium, without a project manager who heads a project management office.

if your project is small enough that "everybody is in charge" and you've got the consensus to work that way you're not talking agile, you're talking magic... and you're going to be 3-10x as productive as a conventional "team"




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: