We know that people are our most valuable resource, but we seem to forget this too easily. Recently, I was with an executive team of a high-technology company, and the team was struggling with a string of late-to-market development projects. Finally, the CEO got up and proposed yet another rewiring of the organization chart. I have seen this scenario repeated too many times.
Fast, effective development depends on people and how they actually interact much more than on the formal linkages shown on an organization chart or process map. The creators of the Agile Manifesto had it right when they said, "Individuals and interactions over processes and tools." Furthermore, I doubt that it was an accident that this was the first of four such statements they made.
So what can you do besides shuffling the boxes on the organization chart or the process map? First, put strong team leaders in charge of your development projects. Every development project falls prey to a challenging variety of problems, and a strong leader will discover these problems quickly and address them before they do much damage. This doesn't have to be an aggressive leader -- one who uses bullying tactics to always get first priority -- but merely an assertive one who finds problems and works in creative ways to resolve them quickly.
Once you have such a leader, give this person the authority he or she needs to get things done. Progress will be slow (and the leader will become frustrated) if the leader must turn to management for approval at every step. In fact, daily decisions are a good test of the team leader's authority: if you find team leaders coming to you repeatedly for permission of a certain type, ask yourself if there isn't a way to turn this type of authority over to the team.
Next, you need committed team members, ones with skin in the game. Even with the best of intentions, bystanders trying to "help" the team often just create more work for it. Those who are doing the work should be making most of the decisions and living with them.
Strive for dedicated team members: those who are on one team, full time. Although you probably cannot afford to have every member assigned to only one team each, the more you can do this, the better your project is likely to perform. Diluted staffing simply slows down progress. On a fast-moving or fast-changing project, the part-timers will constantly be out-of-date, and others will waste time updating them. Finally, dedicated staffing greatly improves accountability and commitment. When the one project a person is working on isn't going well, there is nowhere else for this individual to hide.
Finally, if you are working on an agile development project or on any project subject to change, recognize that, to an extent depending on the amount of change you face, you will be making up the development process as you are executing it. In this case, pay attention to the mastery levels that Cutter Senior Consultant Alistair Cockburn has provided in his book Agile Software Development. You will need a few people at a fluent mastery level who are able and willing to improvise the process as they go. On the other hand, be sure that you do not have too many in the following mastery level, who are only able or willing to follow a single specified method; they will get lost or become uncomfortable in a sea of change.
In short, when your development projects are not going as well as you desire, look first toward strengthening the people on the team, including its leader, before you start looking for solutions at the organizational or process level.