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