Agile is collaboration

I categorized the collaboration component as Human because I believe it deals with human characteristics. Funny thing.. What do I know about humans? :-) Seriously.. not too much. I went to a high school with a focus on science. I studied Computer Science and I work all my life with developers!!

When I was writing it, I started doubting about having 2 different posts: one for customer collaboration and one for collaboration within the team. I think the Agile Manifesto talks only about customer collaboration, but I think the Agile community shares the feeling that team collaboration is equally important to success and makes for a better workplace. Do you agree?

What is collaboration?

To collaborate is to work jointly towards a shared objective, to help each other, to have good intentions, to share all the information and ultimately to do what's best for the team as a whole.  

Endless projects have failed in the past because of lack of user involvement. We used to believe that it was possible for the user to order what he needed and collect the product once it was finished. So, the user was involved at the beginning, defining the requirements and in the end, when the product was already built. Of course, in lots of situations, the user may have not liked what he was receiving but making changes at that point was very expensive. Therefore, the user was forced to specify correct and complete requirement definitions at the beginning of the project. Analysts and developers were 'forced' to understand these specifications which, as we all know are very difficult to do.

The Agile approach is very different as it tries to incorporate the customers throughout the creation of the product. The Agile Manifesto says "Business people and developers must work together daily through the project". So the customer is of course involved defining the requirements, but they also collaborate with the developers in their analysis and provide feedback with each increment of software. There's close collaboration between developers and the customer during the whole project. Customers and developers work together towards a share objective.

Agile collaboration does not end with customer collaboration. Collaboration needs to happen inside the team as well. Agile team members help each other, share all the information and strive for team success.  Agile builds on a team, not on isolated individuals. In a collaborative software development team, members contribute their efforts to build something bigger than themselves.

How is collaboration achieved?

The first requisite to enable customer collaboration is have a contract that allows the customers to be involved in the development process. For the business people, it may be difficult to understand that they will need to 'lose' their time working with developers to build the system. Besides this, having a business person involved in the project will probably generate changes as the project progresses. If there's a contract signed for a defined scope, it may be difficult to apply these changes as they may imply changing the conditions of the agreement. So the contract should be one that welcomes these changes.

Once changes are 'financially' feasible, it should be technically feasible. Agile relies on incremental development to be able to incorporate the customer in the creation process. That is build a bit, show it to the customer, get feedback and keep building while incorporating this feedback. This collaboration that happens in the construction of each feature helps build what the customer is expecting. Building software incrementally is not enough. For this to be sustainable, the cost of change of each new increment should not increase exponentially. If it did, those changes suggested by the customer wouldn't be welcomed at all.

How is collaboration achieved inside the same organization? Well, it may be very difficult to achieve as it deals with human nature. In any organization, there may be conflicts of interests as the interests of the organization are not exactly the same as the interests of its individuals. Cockburn says there are many "games" in place. The organization is playing its game where the project it's just another move. The individuals that work in the organization play another game which is their career. Personal interests may undermine the sucess of a project, but there are things an organization can do to improve collaboration:

Definition of Success or Failure

Either the team succeeds or the team fails. With this definition, there is no place for individualistic behaviors. What's best for the team is what's best for everyone. Individualistic behaviors don't help the team succeed. This definition of success encourages everyone to act in a collaborative way.

Productivity Rewards in the Organization

This point is very related to the previous one, but I think deserves to be mentioned separately. How does an organization rewards its employees? If rewards are made on an individual basis, employees will try to demonstrate their work and they will try to excel over everyone else. This type of reward encourages employees in selfish behaviors and diminish collaboration. I think this point is very interesting as I've seen many organizations doing Agile that have incompatible rewards schemes.

One question that I often asked myself is if a medium that favors collaboration could be unfair with high performers. Someone that works hard and also helps his/her team-mates a lot could feel his/her work is disguised under this scheme. Someone that doesn't work as hard could be 'hidden' under team goals. Probably the only way for managers to verify who works hard and who doesn't, who is talented (and ultimately who deserves a raise!) is to live in the day to day of the team. High performers Agile developers are those who help the team succeed and if you live the day to day with the team, they are easily noticeable. 

Attack dysfunctions

Patrick Lencioni describes in his book "The Five Dysfunctions of the Team" the dysfunctions that a team must overcome to be able to work well as a group.

Image taken from: http://www.thepracticeofleadership.net/2007/03/21/book-review-the-five-dysfunctions-of-a-team/

The first dysfunction is Absence of trust. Lencioni says 'this stems from their unwillingness to be vulnerable within the group'. Well.. It's hard for anyone to expose its vulnerabilities. Even more when your seniority is high. However, if team members don't trust each other, they don't ask for help and they hide information. Ultimately, they do what's best for them instead of doing what's best for the group. On the other side, teams where members trust each other are much more healthy. They ask for help, they help each other and they provide all the necessary information to anyone.

Failure to build trust generates Fear of conflict. If members don't trust each other, they don't engage in constructive arguments. Teams that cannot engage in arguments where everyone expresses their honest opinions lose much of the team's power.

Failure to engage in constructive arguments becomes the greatest cause of members not committing to the decisions taken. If members were not able to express their opinions freely and discuss them with their peers, they don't buy into what has been decided.

Members that don't commit are members that are not accountable. How can you ask a member that hasn't committed to a plan to follow it, right?

Finally, non accountability creates an environment where the five dysfunction can thrive: Inatention to results.

This book is pretty amazing. Once you read it, you begin thinking about those attitudes that were hard to understand when you just started working. For example, replying with a copy to the boss. Or you start thinking about those guys you used to admire: I used to say "this guy, I don't know what he does, but he is so politically smart!!". That sucks men... I love other attitudes now. Those that encourage transparency and bonding in the team. For example, saying in the standup 'Yes, I screw with this decision.. I apologize' or 'I really tried to make it work, but coudn't. I need help' and I also like the guys that step and say 'I will help you'. This makes a team.

Conclusion

I like seating, thinking and trying to order my ideas to write a post. I must confess I was not making the difference between customer collaboration and team collaboration. I was putting everything in the same bag. Now I think making the difference makes sense. I think the Agile Manifesto deals with customer collaboration, but I see no explicit mention to collaboration within the team in it.

Customer collaboration is of utter importance to the success of the project. A customer, someone that knows and understand what is needed, throughout the project increases exponentially the chances of success. Collaboration needs to be enabled, both at a contractual level and at a technical level.

Team members that collaborate with each other make the other half. There is nothing like a health environment for people to reach their highest potential.   

There's also a side effect benefit. Collaboration over contracts makes the process lighter and thus centered in value. I believe there are some processes or quality standards that suggest contracts to supply lack of trust. If you don't trust the other part, you want a signature to be assured that the other part is committed to do something. In contrast, if you trust the other part, you just need his acknowledgement of understanding.