XP/xp/guidances/practices/sustainable_pace.xmi

<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:PracticeDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" epf:version="1.0.0" xmi:id="-AS84xtg2NOXfrqA6eVRzMQ" name="new_practice,_ycm9gGZBEdqvwYzpSSc2Nw" guid="-AS84xtg2NOXfrqA6eVRzMQ" changeDate="2005-12-06T02:20:39.800-0800">
  <mainDescription>&lt;h3&gt;
    Description
&lt;/h3&gt;
&lt;p&gt;
    The assumption in XP is that software development is not a sprint but a marathon. While a sprinter will easily beat a
    marathon runner over a very short distance, the marathon runner will always win in the long run. Consistently working
    overtime will destroy the team, the design, and eventually the product. It creates an environment that makes it
    impossible to do high quality work. People make more mistakes because they are tired (not to mention their low morale),
    causing bugs that require a lot of time to fix down the line. The end result is that it slows everything and everyone
    down.
&lt;/p&gt;
&lt;p&gt;
    Continuous overtime can be a symptom of a deeper problem that is not being addressed. Perhaps the process is too broken
    to be fixed by working more. The rule in XP is that, if the team has to do more than one consecutive week of overtime,
    it should reassess the situation and start rethinking the plan. Overtime is OK if you need to get to the end of an
    iteration or a release, but it should always be an exception rather than the rule.
&lt;/p&gt;
&lt;p&gt;
    Sustainable pace is about fostering a team that can produce a consistent amount of work over a long period of time.
&lt;/p&gt;
&lt;h3&gt;
    Benefits
&lt;/h3&gt;
&lt;ul&gt;
    &lt;li&gt;
        &lt;b&gt;Improved predictability&lt;/b&gt;: plans become more accurate.
    &lt;/li&gt;
    &lt;li&gt;
        &lt;b&gt;Improved product quality&lt;/b&gt;: programmers have the time to do the right thing.
    &lt;/li&gt;
    &lt;li&gt;
        &lt;b&gt;Improved job satisfaction&lt;/b&gt;: programmers can enjoy their work with as little stress as possible.
    &lt;/li&gt;
    &lt;li&gt;
        &lt;b&gt;Reduced time to market&lt;/b&gt;: less time required to fix bad code and rotting design.
    &lt;/li&gt;
&lt;/ul&gt;</mainDescription>
</org.eclipse.epf.uma:PracticeDescription>