| <?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-IXfkG-XfnoEo0xgux482Kw" name="core_principle_collaborate,_KkTIsMp7EdqC_NfSivunjA" guid="-IXfkG-XfnoEo0xgux482Kw" authors="Steve Adolph" changeDate="2006-09-27T16:35:17.403-0700" changeDescription="Initial Version |Removed metaphoric photo. Removed "Don't go dark" collaborative practice.|Removed metaphoric photo. Removed "Don't go dark" collaborative practice. Removed open_up from page name.|Added "organize around the architecture practice"" version="0.03"> |
| <mainDescription><h3> |
| Introduction |
| </h3> |
| <p> |
| Software is created by people with different interests and skills who must work together to create software |
| effectively. |
| </p> |
| <p> |
| Therefore, develop practices that foster a healthy team environment. A healthy team environment enables effective |
| collaboration, which aligns the interests of project participants (development team, quality assurance, product |
| stakeholders, customers) and helps project participants develop a shared understanding of the project. |
| </p> |
| <h3 style="MARGIN: 12pt 0in 3pt"> |
| Practices |
| </h3> |
| <p style="MARGIN: 12pt 0in 3pt"> |
| The next sections describe the practices associated with this principle. |
| </p> |
| <h4 style="MARGIN: 12pt 0in 3pt"> |
| Maintain a common understanding |
| </h4> |
| <p> |
| Project participants require a common understanding of a project to cooperate effectively. Otherwise, disorder sets in, |
| because the team members cannot align their understanding and interests and will work with different purposes. |
| </p> |
| <p> |
| Be proactive communicating and sharing information with project participants and do not assume that everyone will just |
| find what they need to know or that each person has the same understanding of the project as everyone else. Use work |
| products, such as the Vision, Work Items List, and Requirements to align the understanding between the stakeholders and |
| developers. Use the architecture to focus and align the interests of the developers. At the end of each iteration, get |
| agreement on whether the iteration goals have been reached, and, if not, what actions must be taken. |
| </p> |
| <h4 style="MARGIN: auto 0in"> |
| Foster a high-trust environment |
| </h4> |
| <p> |
| People who do not feel safe will not communicate their ideas, take the initiative, or admit their ignorance. In these |
| low-trust work environments, activities must be laboriously planned in detailed, carefully supervised, and extensively |
| audited. A team working in a low-trust environment may not be able to keep up with rapid change. |
| </p> |
| <p> |
| Therefore, take actions that foster a high-trust environment: |
| </p> |
| <ul> |
| <li> |
| <p> |
| <strong>Manage by intent.</strong> Create an environment where teams manage themselves, and managers serve as |
| mentors to teams to help them complete their objectives. |
| </p> |
| </li> |
| <li> |
| <p> |
| <strong>Tear down the walls.</strong> Work to remove both the physical and mental barriers that inhibit |
| development of a common understanding among project participants. |
| </p> |
| </li> |
| <li> |
| <p> |
| <strong>Walk a mile (or 1.6 kilometers) in someone else's shoes.</strong> Respect and try to understand the |
| perspectives of others before criticizing their ideas or responding to their criticism. |
| </p> |
| </li> |
| <li> |
| <p> |
| <strong>Respond to conversations with relevance.</strong> People, especially technical workers, often respond |
| with argument or disagreement, which leads to rivalry and the establishment of a pecking order in which only a |
| few people contribute to the discussion. Develop and encourage behavior that values curiosity and relevance |
| over argument and disagreement. |
| </p> |
| </li> |
| <li> |
| <p> |
| <strong>Always look to yourself first for the source of communication problems.</strong> Understand that |
| everyone has a perspective that is largely invisible to the individual (although it is often obvious to |
| everyone else). Develop the habit of identifying the assumptions and prejudices within yourself that lead to |
| argument or lack of communication. Learn to overcome these in the moment of the conversation. This takes |
| practice. There are times when others may be intractable, but often the problem can be addressed by wrestling |
| with your own perspective. |
| </p> |
| </li> |
| <li> |
| <p> |
| <strong>Understand the constraints of the workplace culture.</strong> Some organizations operate in a way that |
| allows people to admit mistakes, ask questions, and experiment. Some organizations limit these expressions, but |
| they may change, with time and effort. Some organizations have no tolerance for error, and workers put |
| themselves in danger by admitting mistakes or experimenting. Understand your environment and protect yourself |
| accordingly. Understand that low-trust organizations have more problems in achieving their goals and provide a |
| less satisfying environment. |
| </p> |
| </li> |
| </ul> |
| <h4 style="MARGIN: auto 0in"> |
| Share responsibility |
| </h4> |
| <p> |
| There may be disadvantages for individuals when they work alone. Communication with the team can become sporadic, and |
| then stop. People may get into trouble and not ask for help, or not realize that the team is in trouble and needs their |
| help. Their understanding of the project may become misaligned with the rest of the team. In the worse situations, |
| trust breaks down as individuals see the team working at different purposes to their interests. |
| </p> |
| <p> |
| Therefore, while individuals have primary responsibility for their work products, responsibility for work products is |
| shared. Nothing is someone else's responsibility. This may mean either taking up slack and working with someone who is |
| lagging for some reason or asking for help. Experienced staff should be extra-vigilant and watch over less-experienced |
| staff, encouraging them to ask for help if necessary. |
| </p> |
| <h4 style="MARGIN: auto 0in"> |
| Learn continuously |
| </h4> |
| <p> |
| Not only is software development a fast-developing field where technical skills rapidly become obsolete, it is also an |
| empirical process, where software is developed in a manner that sometimes resembles trial and error. Furthermore, |
| software is developed by teams of people who must work together to achieve results. |
| </p> |
| <p> |
| Therefore, continuously develop both your technical and interpersonal skills. Learn from the examples of your |
| colleagues. Take the opportunity to be both a student of your colleagues, as well as a teacher to them. Always increase |
| your personal ability to overcome your own antagonism toward other team members. |
| </p> |
| <h4 style="MARGIN: 12pt 0in 3pt"> |
| Organize around the architecture |
| </h4> |
| <br /> |
| <p class="MsoNormal" style="MARGIN: 0in 0in 0pt"> |
| As projects grow in size, communication between team members becomes increasingly complex.<span style="mso-spacerun: yes">&nbsp;</span>While all team members understand the overall system, they can focus primarily |
| on the one or more subsystems they are responsible for. Organizing around the architecture also helps with |
| communication by providing the team with a common vocabulary and shared mental model of the system<strong>.</strong> |
| Communication between team members becomes increasingly complex. Therefore, organize the team around the architecture |
| and the vocabulary and shared mental model of the system. However, be watchful that individuals and teams organized |
| this way do not form a so-called <em>silo mentality</em>, where they focus strictly on their subsystems and become |
| ignorant of the other subsystems. |
| </p> |
| <p> |
| An architecture that reflects the organization’s structure is not evidence that the team has successfully organized |
| around the architecture. If organizations and teams are not organized around the architecture, then the architecture |
| will naturally conform to the organization, as a result of political and cultural influences. In the end, the |
| architecture and the organization will almost always be a reflection of each other. The goal is to guide team |
| organization from the needs of the architecture as much as possible. |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |