| <?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="-IXfkG-XfnoEo0xgux482Kw" |
| name="core_principle_collaborate,_KkTIsMp7EdqC_NfSivunjA" guid="-IXfkG-XfnoEo0xgux482Kw" |
| authors="Steve Adolph" changeDate="2007-05-22T10:04:50.107-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>
 |
| 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, and
 |
| customers) and helps project participants develop a shared understanding of the project.
 |
| </p>
 |
| <h3>
 |
| Practices
 |
| </h3>
 |
| <h4>
 |
| 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 then work with different purposes.
 |
| </p>
 |
| <p>
 |
| Be proactive communicating and sharing information with project participants. 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>
 |
| Foster a high-trust environment
 |
| </h4>
 |
| <p>
 |
| People who do not feel safe will not communicate their ideas, take initiative, or admit their ignorance. In these
 |
| low-trust work environments, activities must be laboriously planned in detail, 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>
 |
| Take actions that foster a high-trust environment:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <p>
 |
| <b>Manage by intent.</b> Create an environment where teams manage themselves, and managers serve as
 |
| mentors to teams to help them complete their objectives.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <b>Tear down the walls.</b> Work to remove both the physical and mental barriers that inhibit
 |
| development of a common understanding among project participants.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <b>Walk a mile (or 1.6 kilometers) in someone else's shoes.</b> Respect and try to understand the
 |
| perspectives of others before criticizing their ideas or responding to their criticism.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <b>Respond to conversations with relevance.</b> People, especially technical workers, often respond
 |
| with argument or disagreement, which leads to rivalry and establishes 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>
 |
| <b>Always look to yourself first for the source of communication problems.</b> 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 you 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>
 |
| <b>Understand the constraints of the workplace culture.</b> 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 their workers put
 |
| themselves in danger if they admit mistakes or experiment. 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>
 |
| 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>
 |
| 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>
 |
| 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>
 |
| 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>
 |
| Organize around the architecture
 |
| </h4>
 |
| <p>
 |
| As projects grow in size, communication between team members becomes increasingly complex. While all team members
 |
| understand the overall system, they can focus primarily on the one or more subsystems that 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. Communication between team members becomes increasingly complex.
 |
| </p>
 |
| <p>
 |
| Organize the team around the architecture, and the vocabulary and a shared mental model of the system. However, be
 |
| careful that individuals and teams organized this way do not form a so-called <i>silo mentality</i>, 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 in itself 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> |
