Note, this is part 2 of an 8 part series of the agile principles series. You can find part one here.
Collaboration is fundamental
One of the most important things you can do is foster an environment, culture, and habit of collaboration. This is a key feature of whatever agile framework you chose to employ at your work. All of the procedures, ceremonies, and processes are built around the idea of collaboration. Collaboration is how we can quickly find a solution to a problem. It doesn’t require technical expertise, or detailed knowledge about how to solve a problem. If you are on a team that may not have the most advanced technical knowledge, don’t worry. You still have value. One of the things that helps in those situations is being a sounding board for other more technical people on the team. They can throw out technical solutions or talk through some implementation details, and in the middle of their sentence, they will either see the flaw in their idea, or will find a solution to their issue.
One thing to keep in mind is that collaboration is not linear. Collaborative efforts are more circular in nature. Often times we’ll jump from one subject to the next only to come back to the original subject later in the conversation. This is all fine.
The Agile Manifesto in review
To better understand how critical collaboration is, let’s take a look at the Agile Manifesto. The third value states:
[We value] Customer collaboration [more] over contract negotiation
In addition to specifically calling out collaboration, the agile principles that support the four values of the agile manifesto give additional weight to the importance of collaboration. The third value is supported by the principles of face-to-face communication (principle 5) and business and developers are to work together daily (principle 3) by telling us when and how to collaborate. The original creators of the Agile Manifesto knew that for a company to be able to accommodate, adjust, and react to changes, the developers and business had to talk to each other. And not only did they have to talk to each other, they had to do it on a daily basis, in person.
The various agile frameworks out there capitalize on this principle by creating various meetings meant to facilitate this collaborative communication. In scrum, you have backlog refinement meetings, sprint review meetings, and daily stand ups where people are meant to discuss face to face about what the team is creating. Additionally, the scrum framework places a business person directly into the scrum team (the product owner).
Scrum isn’t alone in trying to enshrine the idea of collaboration. Collaboration is a key element in XP via the use of feedback loops. You will also find collaboration a key component in Acceptance Test Driven Development (ATDD), Pair Programming, Kanban, Lean, etc.
So, with that said, let’s take a look at how we can collaborate better.
All about Collaboration
The environment matters
The space where you work needs to be conducive to collaboration? This means that you can see the people that you work with. You are not farther than 30 feet apart (they are within earshot). You have rooms setup where you can easily gather and review code, product backlog items, designs with one another.Within the space that you work, you have business people apart of that space and team.
When it comes to communication, the environment matters. A good, collaborative environment isn’t the only factor to better communication, but is a principle contributing factor to enhanced communication.
Not only is the environment important, but how you communicate is also a factor.
So, how do you communicate?
There is a reason that face-to-face communication is specifically mentioned in the agile manifesto. Face-to-face communication is the richest form of communication than other forms of communication. Why? Because when you communicate directly to another person, you capture all of the non-verbal communication. Studies have shown that 80% of communication is all nonverbal. Other forms of communication are less effective because they don’t capture the full spectrum of communication that happens.
With collaboration, there is a scale of effectiveness. Two people at a whiteboard discussing various options to a problem are more effective than a requirements document gathered by one person and distributed for review by the development team. The reason for this is there is a give and take between two people discussing an issue that is not present with a requirements document.
In a requirements document, there can be a give and take of ideas and feedback but it spans over days, weeks, and possibly months. The give and take between two people at a white board happens in the moment rather than longer spans of time.
To see how this works better, let’s take a hypothetical situation:
Let’s say that there is a problem you and your team is working on. Now, let’s implement this rule: to get to the solution, there has to be 9 exchanges of ideas and feedback. If the team is discussing the problem at the whiteboard, how quickly will you get through the 9 exchanges to get to the solution? Relatively quick.
Now, changing the form of communication, if you sent a document for review by your team that would count as one exchange. You then get the document back with further clarifications. That is the second exchange. You make updates to the documents and send it back for further review, thus making the third exchange. This repeats until you reached the 9 exchanges to get to the solution. How long will it take to get to the possible solution? Obviously it depends on how quickly you can change the document, but it would be much longer in comparison to people to people talking in person at a whiteboard.
Trust matters too
One of the things that hamper collaboration is the idea of trust. When there is trust within the team, people can throw out ideas without stifling fear. When you have trust people are more creative and collaborative. Agendas are put away, posturing quits, and everyone gets down to the business of solving problems. How you harbor trust is a subject for another post. But, suffice it to say that when you are assessing your team, keep trust on your radar.
The Summation: Don’t just talk, collaborate.
You need to make sure the team is collaborating. Make sure that developers are not separated off in their cones of silence banging out code. Make sure that they reach out to one another so that they don’t build the wrong things. For the same reason, make sure the business staff is embedded in your team on a daily basis. The more collaboration that you do, the more effective your products will be. Collaboration can energize your team, provide additional motivation and get you over challenging hurdles. You will know when collaboration is happening. It’s not hard to miss.
Thanks for reading.
Being > Doing