Fork me on GitHub

Saturday, May 2, 2009

Why I don't like overworking in a project

The normal reasons. This happens with a over enthusiastic team. They sign up more and find that they can't finish as committed. Put some extra effort. After a few iterations reach a balance. Also over work is not sustainable. Team burns out. All the stuff you already know.

But there is another form of overwork I have seen (Should call it over work.? If you have a better way to express let me know). A more subtle one. Not sure how many have observed or felt this. How many of us have gone to the office on Sunday and saw someone from our team working on something related to project? It is nice to have these kind of committed people in the project right? It is good that they take up something and help the project grow. But there is a risk attached with this.

The problem is the work of these people tends to help in setting unrealistic expectations with the customer. As long as they are in, the team tends to keep a good velocity. As they leave the team, the velocity drops to a lower level (which must have been the actual velocity). And this leads to all kinds of confusion with the management and customers scurrying to find out how to improve productivity unless they understand the real problem. The advantage with agile is it is easy to notice this effect really soon after they leave because of the short iterations.

The second problem is as most would already know, they work alone they may tend to leave the team behind and learn new things about the project and code by themselves. It is good and they can hold workshops to share what they learned. But when it comes to work related to a project I believe in learning with the team and not share knowledge in isolated chunks.

Most of the time these people tend to do this because they are interested in writing code or doing technical work. When you identify those people help them in trying to direct their potential in other ways. 
  • Contributing to open source projects
  • Involving them in coding dogo or technical book club
  • Participating in Barcamps or DevCamps or local user groups.
  • Help with the recruitement.
Also help them to understand the value of whole team learning and working together.

I have written my thoughts. Let me know yours. Have you worked with enthusiastic and committed people like these? How did you help them? What are the problems you faced?

I really like Alistair Cockburn's metaphor of Agile as a cooperative game. It gives meaning to the whole team approach or working and learning. I also like building knowledge which is not limited just by what we are doing in the project. 

No comments: