| <?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.4/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.2.0" xmi:id="-5xbLr54QjpynnPU8ZJ3_fw" |
| name="new_concept,_DI_tICNaEdyCq8v2ZO4QcA" guid="-5xbLr54QjpynnPU8ZJ3_fw" changeDate="2007-07-10T21:00:25.734-0700"> |
| <mainDescription><p>
 |
| Iterations in OpenUP focus the team on delivering incremental customer value every few weeks by delivering a fully
 |
| tested demoable 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 is forced to happen faster, since there is no time for
 |
| endless debate. Iterative development focuses on producing working code, reducing risk for 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 2. An iteration starts with
 |
| a few hour long iteration planning meeting. The first day or two is 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 an incremental and tested build, as well as validated artifacts. To give
 |
| additional discipline, stable weekly builds are produced. 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 has 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 to 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>Figure 2. 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 towards the end.</em>
 |
| </p>
 |
| <p>
 |
| Team members work more effectively if they can influence what they do and how they do it, versus operating in an
 |
| environment where they are told what to do. Giving the team the ability and responsibility to themselves organize their
 |
| work and determine how to best meet their commitments motivates team members to do their best and to collaborate to
 |
| ensure that the right skills are applied to the appropriate tasks. Self organizations 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 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 to 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 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.<br />
 |
| </li>
 |
| </ul></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
