Qualitative decisions often lose out to quantitative decisions. Every one of us lives this every day, quite often without realizing that we are doing it. It's not enough to define our process or methodology and let it settle in. Yes, we absolutely need to have a clearly defined and adopted set of processes and procedures. But at the same time, it's important to never let it become too rote.
Most project leaders have been there before: The hero saves the day, yet again. Everyone is grateful because, obviously, if not for the hero the project would have crashed and burned. It seems so lucky that the team can benefit from this all-star who pulls the project out of the fire time and again. So, what exactly would we do without him (or her)?
Scrum can be remarkably beneficial in many kinds of software projects. But, as with any process, methodology or management technique, when used inappropriately it can cause more problems that it solves. In this article I'll discuss some of the common misconceptions and "lessons learned" as related to Scrum.
Rational Scrum is about software methodology and process improvement: Based in core principles of Scrum, borrowing elements from the Rational process, and never losing sight of Total Quality Assurance.