To be successful, cohesiveness is the most important ingredient a team can develop. The question is does your software development team ‘jell’? Do they think and act as a single cohesive team, working together to solve problems and push their performance to new heights? Or are they a bunch of people who happen to be working on the same project, each working in isolation and barely aware of what the other team members are doing? Studies have shown that a high performance highly jelled team can be up to ten times more productive than a poorly performing team.
Although teams can occasionally jell of their own accord, there are a number of things you can do to help this process along. Note the following five points for the success of a team:-
Make the team sit together- It is virtually impossible for a team to truly jell if its members are not all in one place. A lot of companies put their workers in individual cubicles that seem deliberately designed to stop them working effectively – they are shielded from their colleagues well enough to stop them communicating easily, but not well enough to stop them being distracted. Give the team its own area, and let the team truly take ownership of the area. Encourage them to move the furniture around, dismantle cubicle walls, and add their own embellishments. Let the team control who can enter the area, and where the team members sit.
Let them flourish- Encourage the team to learn and to develop new skills, both as individuals and as a team. Pair programming is a great way of sharing skills and knowledge between team members. Give the team control over its own training and book budget. Encourage the team to learn from its own experiences. Many teams have a retrospective at the end of a project, where they dissect what worked and what didn’t. The end of the project is too late – it is far better to have regular introspective, where the team explores ways of working more effectively that it can put into effect immediately. Another aspect of letting the team grow is in terms of team size. Start with a small team of highly experienced developers and grow the team slowly, as needed.
Give recreational & rest time- Playing games in the rest area helps a lot to restore energies. Playing cards or video games help restore tired minds. The other aspect is rest. It is well known that having a short rest break can stop fatigue setting in and can keep you mentally and physically alert. Rest breaks are also an opportunity for the human mind to process information subconsciously and come up with creative solutions to problems. Have a separate rest area where developers can go to relax, unwind and even sleep.
Trust the team- Developers are motivated by the desire to develop! They take pride in doing a good job, and the best incentive you can give them is recognition that what they are doing is valuable and worthwhile, and to show that you trust them to do their jobs well. They are not generally motivated by status or the next quarter’s profit margin. If you are going to give them a financial incentive such as a bonus, then give it to everyone in the team equally or give it to the team and let them decide how to split it. Singling out team members for special bonuses is a great way to destroy morale and team cohesion.
A team couch can be beneficial- A good coach will ensure that the team sticks to the process and does all the practices required by the methodology. A great coach will also monitor the team dynamics and work with individuals or the whole team to resolve interpersonal issues. Help the team forge a common vision and set of values, brainstorm with the team to find creative solutions to problems, and facilitate during team introspective to enable the team to find new and better ways of working together.
One Response
Or teaching it to the newbs like melysf.I think the biggest concern about live team size will ultimately be, very simply, budget. A live team on any kind of budget has to be relatively lean and mean at launch and until everyone figures out exactly how much money they’re going to be taking in. At that point, one could probably draw up various scenarios and projections for subscriber retention based on various levels of live team commitment.I suppose one could throw caution to the wind and go with a larger live team, whether it’d potentially put the company into the red or not (at least in the short term), with hopes of increased content and dedicated ongoing development bringing more people in but there’s a question of cost effectiveness there. We’ve certainly seen strong ongoing live development work out for games like Eve, etc. But more often than not, do players even notice? Isn’t this the case with EQ2? Or, has the straight Diku niche just been filled too well by WoW for anyone to notice? This can be an expensive gamble.What’s amusing is how small a team a live game CAN be run on. I don’t think most players would guess how few people are behind the scenes sometimes. The problem here is that, while a skeleton crew may look good on paper for a while, eventually players ARE going to wander away if the game doesn’t change, new content isn’t added, there are no events, etc. The problem with live MMO development seems to be that, while players *all* think that they want things to remain exactly the same forever they really, really don’t.