<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore"
    xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="-5xbLr54QjpynnPU8ZJ3_fw"
    name="new_concept,_DI_tICNaEdyCq8v2ZO4QcA" guid="-5xbLr54QjpynnPU8ZJ3_fw" changeDate="2007-07-22T16:30:20.319-0700">
  <mainDescription>&lt;p>&#xD;
    Iterations in OpenUP keep the team focused on delivering incremental customer value every few weeks by delivering a&#xD;
    fully tested demo-able or shippable build (product increment). This creates a healthy focus on ensuring that whatever&#xD;
    is worked on is of value to the stakeholders. Decision making must happen faster since there is no time for endless&#xD;
    debate. Iterative development focuses on producing working code reducing the risk of analysis-paralysis. Frequent&#xD;
    demonstration of working code provides feedback mechanisms that allow course corrections to be taken as needed.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Iteration planning, estimation, and progress tracking are centered on work items. The iteration plan is created by&#xD;
    selecting the top-priority work items. Agile estimation techniques are used to understand how many work items can&#xD;
    safely fit within the time-boxed iteration, and work items are filtered to ensure that the chosen work items will allow&#xD;
    the team to deliver upon iteration objectives agreed to by stakeholders. Progress is demonstrated through continuous&#xD;
    completion of many small work items (see &lt;a class=&quot;elementLink&quot;&#xD;
    href=&quot;./../../../openup/guidances/concepts/micro_increments.html&quot; guid=&quot;_S80VwCNbEdyCq8v2ZO4QcA&quot;>Micro-Increments&lt;/a>).&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Just as a project goes through a lifecycle, iterations go through a lifecycle with a different focus for the team&#xD;
    depending on whether you are in the first versus the last week of the iteration, see Figure below and &lt;a&#xD;
    class=&quot;elementlinkwithusertext&quot; href=&quot;./../../../openup/guidances/supportingmaterials/references.html#JAZZ&quot;&#xD;
    guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;>[JAZZ]&lt;/a>. An iteration starts with an iteration planning meeting that is a few hours&#xD;
    long. The initial one or two days are typically focused on further planning and architecture to, among other things,&#xD;
    understand the dependencies and logical ordering of work items, and architectural impacts of the work to be done. Most&#xD;
    of the time during an iteration is spent on executing the micro increments. Each micro increment should deliver tested&#xD;
    code to a build, as well as validated artifacts. To give additional discipline, stable builds are produced at the end&#xD;
    of each week. More attention is spent on these builds to make sure that the quality is not eroding and issues are dealt&#xD;
    with early so the success of the iteration isn’t jeopardized. The last week or last few days of the iteration typically&#xD;
    have a stronger emphasis on polishing and bug fixing than earlier weeks, even though new features are added as&#xD;
    appropriate. The goal is to never let quality erode, thus ensuring&amp;nbsp;that a high-quality useful product increment is&#xD;
    produced at the end of the iteration. The iteration ends with an assessment (with stakeholders) of what was built, and&#xD;
    a retrospective to understand how to improve the process for next iteration.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;img&#xD;
    alt=&quot;Picture shows an iteration that starts with a planning meeting, has stable weekly builds, and ends with an iteration review.&quot;&#xD;
     src=&quot;./resources/iteration_lifecycle.jpg&quot; />&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;em>An iteration goes through a lifecycle with a stronger focus on planning and architecture early-on and a stronger&#xD;
    focus on bug-fixing and stabilization toward the end.&lt;/em>&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Team members work more effectively if they can influence what they do and how they do it, rather than operating in an&#xD;
    environment where they are told what to do. Giving the team the ability and responsibility to organize their work and&#xD;
    determine how to best meet their commitments motivates team members to do their best. This also helps them collaborate&#xD;
    to ensure that the right skills are applied to the appropriate tasks. Self organization impacts many areas, including&#xD;
    how planning and commitments are made (by a team, not by individuals), how work is assigned (you sign up versus get&#xD;
    assigned), and how team members view their role in the project (team member first, job function second).&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../../openup/guidances/guidelines/self_organize_work_assignments.html&quot;&#xD;
    guid=&quot;_rmBEkJjsEduad8I_c-ogIA&quot;>Self organization&lt;/a>&amp;nbsp;requires a few things to work:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Transparency and commitments are crucial to aid in team communication and to bring out the best in the team&#xD;
        members. Open communication about the team’s commitments related to the iteration lifecycle, and personal&#xD;
        commitments made relative to micro increments ensure that execution problems are vetted and the right people are&#xD;
        focused on solving them.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Coaching is required to help teams self organize and to remove barriers for success. The assumption is that the&#xD;
        project manager is the coach. This requires that the project manager avoid a command-and-control style of&#xD;
        management in favor of a coaching style. This has been a key recommendation in management books for the last two&#xD;
        decades, but some project managers may still not be able to make that transition.&#xD;
    &lt;/li>&#xD;
&lt;/ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>