What works in development team building?

• By Colleen Frye
• August 30, 2002

August 30, 2002; XML Web Services One Show Daily - Trusting your development team to do their jobs, speaking the same language as your team, and backing up your team are key attributes for managing software development efforts. And for critical development projects with tight time constraints, smaller local teams work better than large, distributed teams. That was the consensus of a lively birds-of-a-feather meeting at the XML Web Services One Conference & Expo in Boston.

Panel members Toufic Boubez, CTO of Layer 7 Technologies; John Williams, CEO and president of Blue Mountain Commerce; and Dave McCall, development consultant at Groove Networks, all agreed that developers work better when trusted to do their jobs, and without feeling that somebody is looking over their shoulder.

''Micromanagers should be thrown out on their butts or retrained,'' joked Boubez.

Knowing when to leave team members alone, however, must be accompanied by knowing when to step in and back them up, and following through on things, ''in other words, a manager must have integrity,'' said Groove's McCall. And a manager who is well versed technically, he suggested, makes speaking the same ''language'' easier.

The ability to assemble a skilled team that works together well and meets project goals is also the mark of a good manager, the panel members agreed.

There are a variety of project management and collaboration tools for keeping a team on track, but the panel participants agreed that good instincts are just as important, if not more so. To manage a project, ''there are technologies you can apply, or you can rely on a go-to person and your gut feeling. I like tools, but you still have to use your gut feeling,'' said Blue Mountain Commerce's Williams. Layer 7's Boubez agreed, saying a good team manager relies on ''stop and think'' or ''stop and sync'' points to see where you are in a project. He added that sometimes project management tools and rigorous methodologies create too much overhead for certain types of projects.

While one audience member suggested that the notion of fixed development cycles with localized teams and hard dates for deliverables is ''1995 thinking,'' and that an open-source, distributed style of development is more in keeping with today's move toward Web services and iterative software development, panel members disagreed.

Rather, they suggested, the nature of the project should determine the style of development and the size of the team. ''With any software project you have time deadlines and goals. The harder these constraints are, the less a distributed, open-source type of development is successful,'' said Boubez. And while collaborative tools make it easier to communicate than before, ''you still have to make a concerted effort,'' said Blue Mountain's Williams, and occasionally gather the dispersed team for a ''face to face, pizza and beer'' session. And even though the nature of Web services means developers have to be more agile in responding to the customer, ''we still have to look at delivering a product. Someone has to be the person who makes the dates,'' said Groove Network's McCall.