[PaulHoule]

Remember the triple constraints of cost, scope and time. If you are going to commit to releasing at a certain time you are going to have to let the scope slide. (Sometimes you can add more people on a 2 week basis but the ramp up time makes it usually impractical.)

[T-hawk]

And this is exactly the difference between Scrum and Kanban. Scrum fixes the time periods and allows for adjusting scope, by cutting stories and features. Kanban fixes the scope while allowing the time period to be open-ended. Which methodology is more appropriate depends on which constraint a business wants or needs to optimize for.

[PaulHoule]

It is even better to do something hybrid that is tuned to the application.

A bad thing about scrum is that it introduces a lot of phony deadlines that have nothing to do with the business; this is like the common practice of the boss setting a short deadline on the hope that they can control the cost (total hours) by controlling calendar time.

On the other hand having a release every two weeks means you actually need a release. There are so many projects where a few programmers spend say 1.5 years building a components and hypothetically the application is feature complete, but they are nowhere near running it on a real server or packing it up for the customer with an installer and all that and it takes another 0.5-1 yr to figure out how to make a release.

Then there is a stressful process of making a few more releases to fix the inevitable problems, then they go off and work another 2 yrs on the next release and then find they've forgotten how to make a release. The best thing about scrum is that it avoids that.

The idea that the phony deadline is fixed is another problem. If you can slip the schedule by 2 or 3 days in scrum to address critical things in the scope there that is no problem but many agilists will fight that.

Another failure mode is the project that is hitting the goals for milestones well (estimating things about 10% accurately) and that makes people feel good, but somehow you never get to the last milestone.

I came in late and helped finish one of those severely troubled projects where there was a huge amount of blame to go around. Scrum and Kanban concepts were being used by teams involved, but a lot of people on my team including the boss and star programmer would not do what scrum required. My boss would bitch me out for making "rediculous" estimates of 4 hours to do something that involved a 45 minute build process and I wondered how the other people on the team didn't have this and I found I was the only one who was serious about estimating and that the star programmer did not do it at all.

In the end we gave up on scrum and got heavy on checklists. We made a checklist with about 300 steps for a release process and it a was a stressful process but we learned how to do it reliably. Also we had a checklist of things to have done before the final release.

It was not pretty but we did cross the finish line and get the product in front of customers and they liked it, so I felt I did my part and felt free to move on when it was done.

[Drdrdrq]

There is a fourth one - quality. It is important to acknowledge its existence, otherwise you can find yourself in a position where you can alter "all 3" constraints for the better at the cost of a hidden fourth one.