Collaborate to align interests and share understanding
Software is created by people with different interests and skills who must work together to create software effectively. Therefore develop collaborative practices that foster a healthy team environment. Good collaborative practices align the interests of project participants (e.g. development team, quality assurance, product stakeholders, customers) and help project participants develop a shared understanding of the project.
Practices
Maintain a Common Understanding
Project participants require a common understanding of a project to cooperative effectively. Without a common understanding among project participants disorder sets in because they cannot align their interests and will work at cross purposes to one another.
Therefore be proactive communicating and sharing information with project participants and do not assume everyone will just find what they need to know or has the same understanding of the project as everyone else. Use work products such as the vision and requirements to align the understanding of the stake holders and developers. Use the architecture to focus and align the interests of the developers. At the end of each iteration get agreement iteration goals have been reached and if not then what remedial actions must be taken. The Focus principle helps to maintain a common understanding.
Foster a High Trust Environment
People who do not feel safe will not communicate their ideas, take the initiative, or admit their ignorance. This leads to work environments where actions must be laboriously and expensively negotiated and work which must be carefully monitored and audited.
Therefore take actions that will foster a high trust environment:
- Manage by intent - create an environment where teams manage themselves and managers mentor teams to complete their objectives.
- Tear down the walls – work to remove both the physical and mental barriers that inhibit development of a common understanding between project participants.
- Walk mile (or a kilometer and a half) in someone else’s shoes – respect and try to understand the perspective of others before criticizing their ideas or responding to their criticism.
Share Responsibility
When a person works alone communications can stop and they can “go dark” Their understanding of the project may become misaligned with the rest of the team. They may get into trouble and not ask for help, or not realize the team is in trouble. In the worse situations trust breaks down as people see the team working at cross purposes to their interests.
Therefore, while project participants have primary responsibility for their work products, responsibility for work products is shared. Nothing is someone else’s job. It may mean either taking up slack and working with someone who’s 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.
The collaborative practice Foster a High Trust Environment reinforces sharing responsibility by making it safe for people to take the initiative, or to admit their ignorance.
Learn Continuously
Not only is software development a fast developing field where technical skills rapidly become obsolescent, it is also an experimental field where software is developed often by a process that resembles trial and error. Furthermore, software is developed by teams of people.
Therefore continuously develop both your technical and interpersonal skills. Learn from the examples of your colleagues. Take the opportunity to be both a student and a teacher to your colleagues. Always increase your personal ability to overcome your own antagonism towards other team members.
The Evolve principle closely supports continuous learning. Learn Continuously helps develop trust.
Organize around the architecture
As projects grow in size, communication between team members becomes increasingly complex.
Therefore organize the team around the architecture of the system so all team members understand the overall system but can focus primarily on a subset of a system, that is, one or more subsystems are assigned to them. Organizing around the architecture also helps with communication by providing the team with a common vocabulary and shared mental model of the system. However, be watchful that individuals and teams organized this way do not form a "silo" mentality where they focus striclty on their sub-systems and become ignorant of the other subsystems.
|