<?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.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmi:id="-nt9iQFaHdTAtzPaMkX1E_g" name="new_concept,_CmxtULtxEe29CKVnbOLlJg" guid="-nt9iQFaHdTAtzPaMkX1E_g" changeDate="2023-03-05T19:46:30.225+0330">
  <mainDescription>&lt;p>&#xD;
    An Agile team is a cross-functional group of people that have everything, and everyone, necessary to produce a working,&#xD;
    tested increment of product.&amp;nbsp; Dedicate these people to the team, and as a rule, do not move them between or across&#xD;
    teams as demands ebb and flow.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    I’m going to suggest that the very definition of an Agile team is getting in the way of forming Agile teams. Mostly,&#xD;
    because we misunderstand what a product actually is. In the small, this guidance is clear, it’s the system.&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &amp;nbsp;All the way from user interaction to data and back and all the abilities to deploy and install said product into&#xD;
    production. However, in the large, forming a team like this isn’t usually possible, and often not advisable—even if it&#xD;
    is possible.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &amp;nbsp;Also, in the large, a product is actually a sub-system of a larger systems-integration.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    When you look at a product this way, it’s often possible to create a small, cross-functional group of people that has&#xD;
    everything—and everyone—necessary to produce a working, tested increment of product.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
