Everything in Scrum…
- is a time box (aka sprint), so things don’t go on forever
- is done with cross functional teams who don’t need to be managed
- has a constrained team size ( under 8 people )
- has to achieve some form of a shippable product at the end of each time box / sprint
- assumes that you are intelligent enough to come up with a solution to the problem at hand
- requires minimal or no interruptions while sprinting
Additional points
- Scrum goes hand in hand with Extreme Programming practices.
- Working more hours does not equal better code quality. Code will likely become exponentially worse as a result of quick fixes and ideas that haven’t been adequately thought through. The cost to fix these issues even outweigh the cost that would have been saved by keeping normal work hours. As a result, overworking is not a good way to increase project velocity.
- Unexpected features can harm project velocity in such a way that if not adjusted in time for quality control will cause future iterations to gradually worsen as you build upon a flawed code base. This continues until eventually you have a “design dead” product.
- Over 65% of all functionality that is delivered (which must be maintained) is rarely or never used.
- 35% of all requirements change during the life of a project.
- Using a prioritized list of features, overtime the items will begin to loose value and at some point the time may be better spent elsewhere.
Resources