<?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:rmc="http://www.ibm.com/rmc" rmc:version="7.5.0" xmlns:epf="http://www.eclipse.org/epf"
    epf:version="1.5.0" xmi:id="-hWKKNia-vOmQZTZWO24u5w"
    name="how_to_adopt,_ERIDQOMPEdyM47cGD2jiaQ" guid="-hWKKNia-vOmQZTZWO24u5w" changeDate="2008-07-18T09:54:49.825-0700"
    version="7.2.0">
  <mainDescription>&lt;h3>&#xD;
    Getting started&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Iterative development is based on the idea that a software system is built iteratively in a series of increments. Each&#xD;
    increment adds a subset of the final system's functionality, and the system grows to become more and more complete over&#xD;
    the course of the project's iterations.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Consider making all of your iterations have the same duration. This is important for two reasons: it establishes the &quot;heart&#xD;
    beat&quot; of the project, and it helps understand the project team's performance. This supports the creation of successively&#xD;
    more accurate estimates of remaining work. Attack the hardest problems on the first iterations, but do not overload the&#xD;
    first iteration too much. Make sure that you can show progress at the end of each iteration. Do not extend an iteration in&#xD;
    order to finish work, but also do not finish an iteration without any software to be demonstrated. If needed, break the problem&#xD;
    into smaller, more manageable pieces so that this balance can be achieved.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Plan an iteration in detail only when it is due to start. Each iteration starts with an iteration planning&#xD;
    meeting with the whole project team. In this meeting, the objectives of the iteration are defined in terms of work&#xD;
    items, tasks are identified for these work items, and team members sign up for tasks and provide their estimates. At&#xD;
    the end of the iteration planning meeting, the iteration plan is comprised of a set of work items, decomposed into&#xD;
    tasks that individual team members sign up for. The iteration can be started. Once an iteration is under way, it should&#xD;
    be allowed to proceed according to its plan, with as little external interruption as possible.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    During the course of the iteration, team members provide frequent status of their tasks in focused meetings. The&#xD;
    frequency of these meetings is decided by team: it could be daily, a couple times a week, or weekly. Team members work&#xD;
    on the tasks they signed up for, following the appropriate priority. Allow detailed informal peer coordination to&#xD;
    happen, and mark completed work items in the iteration plan. The overall iteration status is hence readily available in&#xD;
    the iteration plan at all times. Any work items that have not been justifiably completed by the end of the iteration&#xD;
    are removed from the iteration and re-assigned to the next one (or just returned to the work items list).&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Make all iterations follow the same pattern. This helps the team to focus on activities that are specific to the&#xD;
    beginning, middle, and end of an iteration. For example, some common activities performed during an iteration are:&lt;/p>&#xD;
&lt;ul>&#xD;
&lt;li>Iteration planning&lt;/li>&#xD;
&lt;li>Iteration architecture work&lt;/li>&#xD;
&lt;li>Continuous development of micro-increments&lt;/li>&#xD;
&lt;li>Creation of stable weekly builds&lt;/li>&#xD;
&lt;li>Bug fixing&lt;/li>&#xD;
&lt;li>Iteration review and Retrospective&lt;/li>&#xD;
&lt;/ul>	&#xD;
	&lt;p>See &lt;a class=&quot;elementLink&quot; href=&quot;./../../../practice.mgmt.iterative_dev.base/guidances/concepts/iteration_lifecycle_B16552E2.html&quot; guid=&quot;_DI_tICNaEdyCq8v2ZO4QcA&quot;>Iteration Lifecycle&lt;/a> for more information.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Common Pitfalls&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    There are common pitfalls experienced when adopting an iterative approach, including the ones listed in the following&#xD;
    sections. Fore more information on challenges when transitioning from waterfall to an iterative development approach,&#xD;
    see &lt;a class=&quot;elementlinkwithusertext&quot; href=&quot;./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#KRU00&quot; guid=&quot;_JlTPUM6aEdyuBO4ZIzcyig&quot;>[KRU00]&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    What project managers should plan for&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    One of the most difficult situations for project managers is to transition from a traditional development approach&#xD;
    (such as waterfall) to an iterative approach. There is more planning with iterative development than with waterfall: one&#xD;
    plan per iteration. At every iteration, there is negotiation with stakeholders, changes in scope, and re-planning.&#xD;
    Project managers need to avoid detailed planning upfront, and should work with their best estimates for the tasks at&#xD;
    hand in a given iteration. &lt;/p>&#xD;
	&lt;p>&#xD;
	However, this behavior should not result in unplanned and non-prioritized requirements&#xD;
    creating scope-creep, nor unnecessary rework happening on elements that are not broken. The iteration plan, with iteration&#xD;
    objectives and planned tasks, should be collaboratively created by the project manager, the team, and stakeholders in order&#xD;
    to promote a common understanding and buy-in into what is expected at the end of an iteration.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Which comes first: specifications or software? &#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    In a waterfall approach, progress is often measured by the completion of specifications. For example, if the design&#xD;
    specification is completed and signed-off, the team advances to the implementation based on the design specification.&lt;/p>&#xD;
&lt;p>    &#xD;
	With iterative development, artifacts evolve throughout the iterations, and every iteration should result in an&#xD;
    increment in the capabilities offered by the solution: in other words, implemented, tested software that is able to be&#xD;
    demonstrated (and potentially shipped) to customers. Software comes first. Planning is more important than the plans.&#xD;
    Designing and architecting an evolving solution is more important than capturing and polishing design and architecture&#xD;
    models. At the end of each iteration, perform an assessment to gauge the completion of requirements that have&#xD;
    passed test cases. Another way to make significant progress is by focusing on the harder problems (or risks) as&#xD;
    early as possible, thus making sure that you create and use a sound, executable architecture as the basis for the other&#xD;
    requirements.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Different iterations for the different disciplines&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    A common problem found in organizations moving from a waterfall to an iterative process is that they use the iteration&#xD;
    concept only as an &quot;envelope&quot; for their engineering disciplines. For example, it is common to hear people in those&#xD;
    organizations talk about &quot;requirements iteration&quot; or &quot;test iteration&quot;. A fundamental tenet of iterative&#xD;
    development is that it takes a holistic view of work items: each work item assigned to an iteration is completed in&#xD;
    that iteration. For example, a &quot;Login User&quot; work item would see all required tasks (such as design, code, and test) to&#xD;
    complete that work item. At the end of the iteration, the Login User behavior can be demonstrated as an integral part of&#xD;
    the executable system.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    No visible progress&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Some teams will have work items that are not completed during an iteration as expected, and will not report problems.&#xD;
    This creates a false impression that work items planned for the iteration are being closed, thus showing an inaccurate&#xD;
    iteration burndown.&lt;br />&#xD;
    In order to avoid this, monitor active tasks closely, and address any slippage promptly. Use frequent, short status&#xD;
    meetings to gauge progress and detect issues. Create a &quot;no blame&quot; environment where everyone feels empowered by the&#xD;
    team and actively seeks advice and help from the team.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Adding work to an ongoing iteration&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Management or stakeholders may impose more work to be added to an on-going iteration. While this is sometimes&#xD;
    legitimate (for business reasons), there is a risk that this work just gets informally accepted by the team, without&#xD;
    passing through the Work Items List, where it gets prioritized with the remaining work.&lt;br />&#xD;
    In order to minimize the impact of new work being added to an iteration, make sure to involve stakeholders in the&#xD;
    planning process, so that they understand the impact a new work item brings to the current iteration. Be prepared to&#xD;
    negotiate the removal of lower priority work from the iteration, in order to accommodate the new requested work.&#xD;
    Another approach is to convince stakeholders that in a few weeks the iteration will end (with demonstrable progress),&#xD;
    and that the new work item can be prioritized and assigned to the next iteration.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>