<?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 having all iterations with 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 progress can be shown at the end of each iteration. Do not extend an iteration in&#xD;
    order to finish work, neither finish an iteration without any software to be demonstrated. If needed, break the problem&#xD;
    into smaller, more manageable pieces so this balance can be achieved.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Plan an iteration in detail&amp;nbsp;only when&amp;nbsp;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; team members sign up&amp;nbsp;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&amp;nbsp;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&amp;nbsp;activities that are specific to the&#xD;
    beginning, middle and end of an iteration. For example, some common activities performed during an iteration are:&#xD;
    iteration planning, iteration architecture work, continuous development of micro-increments, creation of stable weekly&#xD;
    builds, bug fixing and iteration review and retrospective. See&amp;nbsp;&lt;a class=&quot;elementLink&quot;&#xD;
    href=&quot;./../../../practice.mgmt.iterative_dev.base/guidances/concepts/iteration_lifecycle_B16552E2.html&quot;&#xD;
    guid=&quot;_DI_tICNaEdyCq8v2ZO4QcA&quot;>Iteration Lifecycle&lt;/a>&amp;nbsp;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&amp;nbsp;an iterative approach, as 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;&#xD;
    href=&quot;./../../../core.mgmt.common.base/guidances/supportingmaterials/mgmt_references_D80619F3.html#KRU00&quot;&#xD;
    guid=&quot;_JlTPUM6aEdyuBO4ZIzcyig&quot;>[KRU00]&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;h5>&#xD;
    What project managers should plan for&#xD;
&lt;/h5>&#xD;
&lt;p>&#xD;
    One of the most difficult&amp;nbsp;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. However, this behavior should not motivate that unplanned and non-prioritized requirements&#xD;
    create scope-creep, nor unnecessary rework happens on elements that are not broken. The iteration plan, with iteration&#xD;
    objectives and planned tasks&amp;nbsp;should be collaboratively created by project manager, 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;h5>&#xD;
    Which comes first: specifications or software&amp;nbsp;&#xD;
&lt;/h5>&#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.&#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&amp;nbsp;that have&#xD;
    passed&amp;nbsp;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 a sounding, executable architecture is created and used as basis for the other&#xD;
    requirements.&#xD;
&lt;/p>&#xD;
&lt;h5>&#xD;
    Different iterations for the different disciplines&#xD;
&lt;/h5>&#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 “envelope” for their engineering disciplines. For example, it is common to hear people in those&#xD;
    organizations talk about, for example, “requirements iteration” or “test iteration”. 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 ‘Login User’ 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;h5>&#xD;
    No visible progress&#xD;
&lt;/h5>&#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 “no blame” environment where everyone feels empowered by the&#xD;
    team and actively seeks advice and help from the team.&#xD;
&lt;/p>&#xD;
&lt;h5>&#xD;
    Adding work to an ongoing iteration&#xD;
&lt;/h5>&#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&amp;nbsp;minimize the impact of new work being added to an iteration, make sure to involve stakeholders in the&#xD;
    planning process, so 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 the new work item can be prioritized and assigned to the next iteration.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>