I can say that tennis is a lifestyle for me. Watching and playing it for hours are really enjoyable activities. I try to
improve my game by modeling 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 throughout the court, which are the reasons ultimately to win or lose 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 specialized knowledge to be handled, and their current responsible person might not have enough experience in that area. You must promptly reassign those tasks to someone else who can handle it much more appropriately. It is a mistake to wait for 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 suit them very much in your point of view. Well, if you come across such a situation, don’t hesitate to keep those developers engaged with those kinds of tasks until you see signs of boredom or demotivation. 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.