OpenUP/OpenUP_baseline_EN/exported_HTML_1_0/openup/guidances/concepts/iteration_lifecycle.html - epf/org.eclipse.epf.nl-libraries - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
 <!-- VERSION rmc:7.1.0 -->
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
 <!-- START NON-TRANSLATABLE -->
 <title>openup&amp;#92;guidances&amp;#92;concepts&amp;#92;&amp;#92;iteration_lifecycle.xmi</title>
 </head>
 <!-- WARNING: do not modify the generated comments in this file below this line.  They are used as markers for the import process. -->
 <body>
 Element Name: iteration_lifecycle.xmi<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: presentationName<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:presentationName,_DI_tICNaEdyCq8v2ZO4QcA CRC: 4088292195 -->Iteration Lifecycle<!-- END:presentationName,_DI_tICNaEdyCq8v2ZO4QcA -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: briefDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:briefDescription,_DI_tICNaEdyCq8v2ZO4QcA CRC: 1843813396 -->The iteration lifecycle provides a set of team-based practices describing how to leverage iterations to focus the team on delivering incremental value to stakeholders in a predictable manner.<!-- END:briefDescription,_DI_tICNaEdyCq8v2ZO4QcA -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: mainDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:mainDescription,-5xbLr54QjpynnPU8ZJ3_fw CRC: 403904965 --><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_C8773066.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_6CCF393.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_F47FC314.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><!-- END:mainDescription,-5xbLr54QjpynnPU8ZJ3_fw -->
 </body>
 </html>
	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
	<!-- VERSION rmc:7.1.0 -->
	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
	<!-- START NON-TRANSLATABLE -->
	<title>openup&#92;guidances&#92;concepts&#92;&#92;iteration_lifecycle.xmi</title>
	</head>
	<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
	<body>
	Element Name: iteration_lifecycle.xmi<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: presentationName<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:presentationName,_DI_tICNaEdyCq8v2ZO4QcA CRC: 4088292195 -->Iteration Lifecycle<!-- END:presentationName,_DI_tICNaEdyCq8v2ZO4QcA -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: briefDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:briefDescription,_DI_tICNaEdyCq8v2ZO4QcA CRC: 1843813396 -->The iteration lifecycle provides a set of team-based practices describing how to leverage iterations to focus the team on delivering incremental value to stakeholders in a predictable manner.<!-- END:briefDescription,_DI_tICNaEdyCq8v2ZO4QcA -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: mainDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:mainDescription,-5xbLr54QjpynnPU8ZJ3_fw CRC: 403904965 --><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_C8773066.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_6CCF393.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 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_F47FC314.html" guid="_rmBEkJjsEduad8I_c-ogIA">Self organization</a> 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><!-- END:mainDescription,-5xbLr54QjpynnPU8ZJ3_fw -->
	</body>
	</html>