Traditionally, we think about projects is in termsof scope, time, cost, quality, human resources, communication, and risk. Thisway of thinking mainly originated in industries other than software development.It fits software development projects poorly, because these projects are mainlyabout people's abilities.

Our society is founded on the importance of meetings, and it seems that the higher on the corporate ladder one climbs, the more meetings he must attend. Indeed, one of Michele Sliger's coworkers calculated that the amount of time she spends arranging meetings, getting to meetings, and in meetings equates to almost her entire workweek-thirty-six hours on average. Even though we may lose track of time in meetings, we all are painfully aware of the time we spend waiting for everyone to show up. In this column, Michele Sliger explains some of the tactics she's seen teams use to ensure that meetings start on time.

Liz Barnett writes that beyond IT, the most frequent adoption of agile processes is found in teams using Scrum for team management. Agile processes won't provide the answers to all of our challenges. But if you dig beneath the surface, you might discover some interesting ways to use these ideas to address complex problems.

A phrase heard often in agile development practices discussions is "let the product lead." Applied correctly, these four words powerfully focus an agile team's energy directly on work that provides the highest business value. Traditional engineering practices that focus on process often divert a technology team's energy away from quick delivery of business value, and toward design of infrastructure and architecture.