I can say that tennis is a life style for me. Watching and playing it for hours are really enjoyable activities. I try to improve my game by modelling tennis pros, taking their approaches to games as reference. I have just finished reading a book about tennis strategies, written by Glenn Sheiner. In this book, he had collected his experiences and observations on how to become a winner and good player. One of the most noticeable ideas in his book is that; tennis is all about strategic match-ups. Winning or losing a match just depends on how good are you at finding winning match-ups.
What are those strategic match-ups then? Let me explain them briefly. Each tennis game is composed of several consecutive shots and movements through out the court, which are the reasons ultimately to win or loose points, games, sets and match at the end. Someone should always try to find winning patterns during the game, and should get away from losing ones immediately. When he finds a winning pattern during the game, for example a good approach shot when his opponent drops a slow ball just behind the service box, afterwards coming into the net, and finally closing the point by a smashing volley, then he can make use of it until his opponent figures out the current situation.
At this point, the critical question is that what is the relevance of this topic with software development teams at all? Actually, forming a software development team, and keeping it functioning properly and working effectively, is almost similar to finding or composing winning match ups throughout the match. For example, team members naturally have different skill sets, and during project development some tasks require specialised knowledge to be handled, and their current responsible person might not have enough experience on that area. You must promptly reassign those tasks to someone else who can handle it much more appropriately. It is a mistake to wait the other person to acquire necessary skill sets to handle the case. At least, you must arrange them as a pair for a duration in which tasks are handled. In another case, some of your developers might enjoy dealing with tasks that they don’t suite them very much in your point of view. Well, if you come across with such a situation, don’t hesitate on keeping those developers engaged with those kind of tasks until you see signs of boredom or de-motivation. You will usually come up with the opposite situation, too. If task progress isn’t very satisfactory or you feel that your developer looks bored with the task at hand, you should immediately look for a match-up change.