Managers Manage

Extreme Programming's popularity has overshadowed the fact that there's more to agile development than writing code. Even people who should know better seem to forget this fact: During both agile eWorkshops hosted by the Fraunhofer Center for Experimental Software Engineering (http://fc-md.umd.edu/projects/Agile/eWorkshops.htm), many participants focused exclusively on XP. It's time to broaden our horizons and explore agile project management.

The Scrum Methodology
Scrum is to effective project management as XP is to effective development. First developed by Jeff Sutherland and Ken Schwaber in the mid-1990s, Scrum was initially released at OOPSLA '96. The term scrum refers to the project team's daily planning meeting. During this 15-minute meeting, each member addresses three questions: What did you do since the last scrum? What will you do before the next one? What impediments got in the way of your work?

Anyone may attend, but only team members participate—limited to answering only the three questions. Interestingly, status reports aren't required—anyone who wants to discover the project status can observe the daily scrum.

Scrum is based on commitment, focus, openness, respect and courage. It asks you to commit to a goal and then provides you with the authority to meet those commitments. Scrum insists that you focus all your efforts on the work you're committed to and ignore anything else. Openness is promoted by the fact that everything about a Scrum project is visible to everyone. Scrum tenets acknowledge that the diversity of team members' background and experience adds value to your project. Finally, Scrum asks you to have the courage to commit, to act, to be open and to expect respect.

The Scrum Lifecycle [click for larger image] A Scrum project is organized into 30-day sprints. At the sprint's end, the team presents what they've built to the stakeholders, who then decide whether to have the system installed into production, to do another sprint or even to cancel the project.

The graphic on this page, taken from Jim Highsmith's Agile Software Development Ecosystems (Addison-Wesley, 2002), depicts the Scrum lifecycle. A Scrum project is organized into a series of 30-day sprints (iterations, in XP or the Rational Unified Process). The product backlog, a prioritized queue of requirements, is the responsibility of a project stakeholder in the role of product owner. The product owner, who represents and works with the stakeholders, has the authority to make decisions pertaining to the product backlog. At a sprint's beginning, the following 30 days' worth of functionality is taken from the top of the queue to form the sprint backlog, ensuring that the team works on the most important task. During the sprint, your development team follows your implementation process—perhaps XP—to build the system. At the end, in a demonstration and follow-up meeting, your team presents what they've built to your project stakeholders, who then decide whether to have the system installed into production, have the team do another sprint, or even to cancel the project.

Scrum teams are graded on meeting goals, rather than on the number of hours it takes to meet that goal. Although this sounds like an opportunity for a project to go over budget, this practice is counterbalanced by the post-sprint demonstration and follow-up meeting.

Scrum has been successfully applied to a wide range of projects, from small to large teams, from colocated to distributed, within various domains. To learn more about Scrum, I recommend Ken Schwaber and Mike Beedle's book, Agile Software Development with Scrum (Prentice Hall, 2001).

Extreme Project Management
But Scrum isn't the only game in town. Author Rob Thomsett has unabashedly added the "extreme" moniker to project management, thereby ensuring a new wave of interest in his ideas.

In his article, "Extreme Project Management" (www.cutter.com/freestuff/epmr0102.html), Thomsett offers sage advice for agile project managers in the form of 11 rules:

1. "The management of creative people and processes demands creative management processes." Project managers need soft skills that reflect the environment they're working in and the people they're working with.
2. "The less the project manager knows about the technical issues of the project, the better." The project manager should focus on business concerns and ensure that the necessary processes are in place so that the technical work can occur. In other words, managers manage.
3. "What happens after the project is more important than what happens during the project." Many traditional project managers ignore the post-development issues and costs to support and operate their systems. Agile project managers, however, consider a project's entire lifecycle.
4. "A project plan developed without full participation of stakeholders is nothing more than one person's fantasy." Planning is a team effort—it isn't something that a single person does using a sophisticated planning tool.
5. "The more time the project manager spends with the stakeholders, the better." Agile project managers focus on the organizational, social, political and financial aspects of a project.
6. "If you haven't defined project success at the start, you'll never achieve it at the end." Understanding the stakeholders' expectations is crucial for success. You should achieve stakeholder satisfaction; meet the functional needs, budget and deadlines; add value; meet quality requirements; and achieve team satisfaction.
7. "Show them the money—nothing else matters." The benefits your system provides should outweigh the costs.
8. "Stakeholders can be your best allies or worst enemies—you decide." Agile project managers know their stakeholders and their needs, and maintain effective relationships with them.
9. "If you can't predict the future, don't plan it in detail." Traditional project managers often assume that a primary aspect of their job is to develop a detailed project Gantt chart, but you can plan in detail only for the near term. Agile project managers know that they'll need to plan and then replan constantly.
10. "If your project hasn't changed, be afraid; very afraid." If your project isn't changing, it has probably slipped off track by "staying on track."
11. "In e-projects, a day is a long time." Change happens—sometimes very, very quickly.

Different Deliverables
Agile project managers realize that project artifacts have also changed; requirements specifications are no longer frozen and thorough, but are flexible and informally documented. One of my clients insists on flexible requirements: For each release, they commit to delivering 70 percent of the requirements defined by their stakeholders, planning to get to the other 30 percent if they have the time. Furthermore, the 70 percent that they do commit to is documented with just enough information to produce marketing literature several months before the final release—but not enough so that they promise things they can't eventually deliver. Impossible? Well, this company has successfully released their award-winning software on a regular basis for years now.

On an agile project, working software is the primary measure of progress. Agile project managers realize that agile software processes achieve the same results as non-agile projects, but do so in different ways. Agile managers abandon the traditional "command and control" philosophy of rigorous processes in favor of collaborative approaches.

The project manager's job is to enable team members, including actively participating stakeholders, to be as effective as possible—and then to get out of their way. Project stakeholders perceive agile project managers differently: You're no longer the IT weenie with status reports and project plans; now you're the person who helps to build working software on a regular basis. Sounds like a step in the right direction to me.

I'd like to thank Ken Schwaber for his insightful feedback on this column.