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

The Innovators Delima
Scrumalliance.org

Over the last few days I've been getting into some of the Extreme programming concepts in the book eXtreme .NET.  The first chapter gives a concise overview of how XP fits into common day business needs.  Here are some key concepts that I took from it:

1. Whole Team: the customer is always available to discuss and resolve issues.
2. Planning Game: where developers sit down with the customer to discuss features of the software which are brainstormed and given priorities.
3. Pair Programming: is the practice of having two developers working alongside one another solving a single problem.  Both programmers learn from each other and send along the knowledge to the next person who they pair with.
4. Test-Driven Development: writing your test cases before beginning to code your solution not only helps you stay focused on the task at hand, it essentially acts as a safety net against breaking existing logic.
5. Constant Refactoring: the process of optimizing your code without loosing functionality.
6. Spiking: making the effort to experiment and drive your efforts in such a way to learn a new skill which pertains to the project development.  It is often done by solo developers who need a break from pairing.
7. Continuous Integration: code gets integrated with the solution after each tasks allowing for the team to ship early and often.
8. Stand-Up Meetings: team members meet every day to discuss progress made as well as spread knowledge to the team.

The Four Five Key Values of XP

Communication

A person's work environment can persuade his or her empowerment to communicate freely.  It is likely there there will be problems if communication is not done properly and frequently.  Even worse, a newcomer to the project could be left out on some important piece of information that would cause a delay in development.

Simplicity

Doing the simplest thing possible to move the project forward.  By writing simple code, it is more likely to work.  Only begin to rewrite a more complex solution when the business need calls for it.

Feedback

Constant feedback from the customer is essential so you can understand exactly what needs to be done and should be done in small iterations.  This is especially true when priorities change while deadlines need to be met.  Your unit tests provide immediate feedback if your test fails when modifying code.

Courage

By working more intensely for a shorter length of time, you are using your time more efficiently as well as allowing yourself more time to be out enjoying life.  Additionally, you must also have the courage to throw away unneeded parts of your code as needs change.

Respect

Having respect for fellow team members by not doing anything which will break the XP practices put in place.  Always striving to produce high quality code throughout the project lifecycle.