| <?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;core_principle_collaborate.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: core_principle_collaborate.xmi<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: presentationName<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:presentationName,_KkTIsMp7EdqC_NfSivunjA CRC: 958450417 -->Collaborate to align interests and share understanding<!-- END:presentationName,_KkTIsMp7EdqC_NfSivunjA --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: briefDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:briefDescription,_KkTIsMp7EdqC_NfSivunjA CRC: 2421836772 -->Develop collaborative practices that foster a healthy team environment. Good collaborative practices align the interests of project participants and help them develop a shared understanding of the project.<!-- END:briefDescription,_KkTIsMp7EdqC_NfSivunjA --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: mainDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:mainDescription,-IXfkG-XfnoEo0xgux482Kw CRC: 1663640580 --><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><!-- END:mainDescription,-IXfkG-XfnoEo0xgux482Kw --> |
| </body> |
| </html> |