Learning a lot in my few years of programming that the best projects are the ones with a clear ‘strategic plan’.
That means understanding the goal and research, Research, and RESEARCH!
The most important concept that teams has to realize that it’s not the ‘goal’ to show how smart you are or use the most complex design patterns, but having a simple and clear way of obtaining the desired plan.
I moving into a leader role; I wonder if some of you have any opinions on my comments?
I wrote a "philosophy" of leading software development teams in which you may find some useful perspectives. Find it here : http://aaronofward.com/philosophy.html
There are other factors that come to my mind in terms of being major impacts on a team:
Motivation - Does everyone in the team do their best? How committed to achieving success are they? Do they have that drive to get to the finish line? Is everyone conservative in their work because everyone is afraid to make mistakes and fail? I don't think this falls under the "simple and clear way." Culture or psychology could be other terms to describe this aspect of what's important to get things done.
Technique - Process would be another term for this part. How do things flow, does the team seem to be running at a good pace or are there spurts and stops? If this isn't set up well, then it should be obvious what kind of disaster can come. I'll grant you that a "simple and clear way" is very similar to this point.
Just to give a bit more of an example to this, let me explain some of how things work in my team:
There are daily Stand up meetings where each person summarizes their progress yesterday, what they plan for today and what blockers do they have. Blockers while they may seem a simple concept for someone that has spent some time doing technical things, isn't necessarily that simple in the end. Why does this prevent you from finishing tasks, what work arounds are available, who has the authority to decide which path should be taken are a few questions about it that some may have.
Then there is pair programming where a developer pairs with another and together some task gets done so that a pair of people have the knowledge of what was done and that it isn't just one person's mad science experiment.
Sprints and the planning meetings around it are another aspect used to help structure how we get things done and promoted through our environments so that priorities can be adjusted as needed over time.
Story cards are used to break work down into bite-size pieces and move along a wall to mark progress as well as tracking time spent on each card for a burndown chart.
Now, take all those ideas and practices, does it seem like I work in a simple and clear way? While each little part may be simple, collectively I don't think it is that easy to pick up and understand all the subtlities of how things get done. For more information look at Motivation and Technique.