For a long time, collaboration and cooperation have meant the same thing to me. Actually, I use word ‘cooperation’ more often when talking about teamwork. Today I read an article called ‘Teamwork in Agile’ written by Bal Mahale. I realized after reading it that collaboration and cooperation are totally different. Here is Bal’s explaination:

People operate in cooperation mode when they divide the responsibilities and identify touch points (contract). In mathematical terms this is similar to 1 + 1 = 2. It means they are doing what is expected of each of the roles, but nothing beyond.

People work in collaboration mode when they build off each other’s strengths and knowledge to create something that is exceptional and beyond their individual abilities. In mathematical terms this is similar to 1 + 1 > 2.

Collaboration is not just working together. It should create something that is exceptional and beyond their individual abilities. Collaboration can be hard because we need to patiently explain to others what we do and why, while at the same time, remain open to criticism and be willing to change the way we do things. Similarly, we need to take a keen interest in others and how they do their work, while keeping an eye out for improvement.

If you want to know more detail about collaboration, please read Bal’s article. It can be found at http://scrumalliance.org/articles/335

Robert Martin wrote an article in November, 2010 entitled “What killed water fall could kill Agile”

Martin wrote about the elitism in software development. In water fall, the analysts are elites; they define everything in documentation and leave the work to the developer. When a project fails, it is the developer who bares the blame. The analysts do not as often take responsibility. Hence, as Martin argues, elitism kills water fall.

It’s possible that the same thing happens in Scrum:  The Scrum Master is an important role in Scrum. They are usually certified as “Certified Scrum Masters” and most CSMs were project managers in their past. So the Scrum Master, in this situation, becomes the elite. If that is the case, will elitism kill Agile also?

I don’t  fully agree with this idea. In our CSM training, one key point mentioned all the time is that the Scrum Mast has no authority in the team. The team decides what they should do. The Scrum Master’s responsibility is to help the team follow the Scrum principle, so essentially, the SM and the team are equal.

But think about the other side: The SM need to be certified, while the team does not. So, it may be that the Scrum Master more easily takes to the role of the elitist, and when the project succeeds, the SM receives the reward and recognition (on behalf of the team, of course), but when the project fails,  perhaps it becomes easier to blame the team.

What do you think?

2010 Agile tour Hangzhou, Jeff Xiong shared an agile story of two teams in different city, we called it ‘a tale of two cities’.
The two teams work very hard, always overtime, but the output is not proportional with what they have paid. The client is unhappy, team always get blamed. They had to ask help from consulting company. With the help of consultant, they begin to apply agile in project.

Team A start from continous integration, team B begin to improve their communication. Both of the team get incredible improvement, and the more important thing is, team begin to realize the benifit agile could bring. they start to reflect themselves and bring more agile pratice to project. Team A is developing router product. to ehance the router quality, they use their own router in work, which is called ‘eat your own dog food’. Team B begin to practice the automation testing.

The project is back to road again, team know how to conitinue without the help of consultant. They know how to reflect themselves and improve using the agile principal, best practice etc. For me, his is the key of Agile.

I read the book “Agile Project Management with Scrum”  recently, there are some quotation I think is good to share. If you also have good one, please share with us.

1. ScrumMaster like a sheepdog, responsible for keeping the flock together and the wolves away.

2. A Scrum project is controlled by means of frequency inspection of the project followed by necessary adaption.

3. All the development artifacts like design documents that existed only to support the waterfall approach are recommended to be eliminated. Scrum relies on high-bandwith, face-to-face communication and teamwork.

For this one, I keep my opinion,  Most team in our company are distributed, face-to-face communication is really expensive some time, the documentation become necessary in this case.

4. Scrum team is cross-functional: in situations where everyone is chipping in to build the functionality, you don’t have to be a tester or a designer to design.