What Is Agile Project Management?

APM is the new kid on the block. Its history stretches back a little more than 25 years. As recently as 2001, Agile software development was first codified through the “Agile Manifesto” (shown in the accompanying sidebar) put forth by Martin Fowler and Jim Highsmith.¹ There were 17 signers of the original Agile manifesto.

The Agile Manifesto has been the guiding principle in all APM models, including those discussed in this book. Most of the APM models originated with software development and, as a result, are based on very specific software development practices. Prototyping and the Adaptive Project Framework (APF) are the only APM models designed for use on any type of project. Prototyping is discussed in the Iterative PMLC model section of this chapter; APF is discussed in the Adaptive PMLC model section. I'll share several APM models in some detail and show you how they map into the Iterative PMLC model and the Adaptive PMLC model.

This chapter covers several different APM PMLC models, but there are two major issues surrounding all APM projects regardless of the model used. These deserve special attention. I bring them up now so that you are aware of them as you explore the variety of models discussed in this chapter.

Implementing APM Projects

Adding more functions and features to the solution and implementing them at the same time sounds great. The client and the end user can benefit from whatever business value can be attained, experience the solution unfolding over short time periods, work with the solution, and provide valuable feedback to the developers about further additions and changes to the solution. But there is another side to this story, and that is the implementation of a constantly evolving solution. Iterations and cycles are short duration — 2 to 4 weeks is typical. The end users will give up and surrender if you expect them to change how they do their work by implementing a new solution every few weeks. How about your organization? What is its organizational velocity? Can it absorb change that fast? Most can't or won't. So what are the client and the project manager to do? Getting frequent client feedback is critical to discovering the complete solution and ultimately to project success, but the organization can't absorb change as fast as the APM models require. There is also the question of the project team's ability to support frequent releases. Training, documentation, and a support group are needed. Let's see, what release are you using again?

The following explains a way out of this dilemma that I have used with several of my clients.

Fully Supported Production Versions of Partial Solutions Are Released to the End User Quarterly or Semi-Annually

This seems to fit other organizational practices for implementing change, so it won't be viewed as anything different than what they are already doing. The input received from the end user and others who affect or are affected by the solution should still be gathered. It will be your most valuable information. There is a benefit in having longer periods to experiment and get comfortable with a new tool. You will gain valuable insight into the intuitive properties of your solution and see what the learning curve looks like.

This approach does not release the project team from the need to support the quarterly releases. I mention that so that you will remember to incorporate in your project plan the effort and support time that will have to be provided.

Intermediate Versions Are Released to a Focus Group Every 2–4 Weeks

You don't stand idly by and wait for end-user feedback from the quarterly releases. That flies in the face of delivering business value early and often. Instead, assemble a focus group of staff and managers who are respected by their peers and who have earned the right to critique the solution. You should ask them to commit to reviewing and critiquing every version of the solution. You will need to take advantage of any learning curve effects from having the same focus group members reviewing the evolving solution. The focus group should have some of the client members of the project team on it as well as a few other key end users. A focus group of 10 members is a good working group, but use your judgment on the size. The decision model you choose to use might also influence size — for example, do you need an odd number for voting? The project team will work very closely with the focus group on every version of the solution — both those that are released quarterly to end users and those that are not released. The documentation, training, and support needed by the focus group to understand the non-released solutions will be minimal. If you choose the focus group members to be a representative sample of all user groups, they can also provide limited support to the end users for the quarterly and semi-annual production versions. That way they can become a conduit from the end users back to the project team.

Co-Located APM Project Teams

Every proponent of APM approaches advises using small co-located teams of highly skilled professionals who are assigned 100 percent to the project and who can work without supervision. That's a nice goal to strive for but not too practical or likely in today's business environment. I haven't encountered a single example of a co-located team among my clients for at least five years. And the likelihood that I will is decreasing.

Most of the Iterative and all of the Adaptive PMLC models require a team of highly skilled professionals. The Adaptive project teams that do use highly skilled professionals are self-organizing teams and work effectively without supervision. One of my colleagues is managing an APM project and has never seen nor is she ever likely to see her teammates. She didn't even have the option of selecting them, and none of them are assigned to her project 100 percent. They were available, and they are distributed across the country. There is no money in the project budget for team members to travel. She has their pictures taped to her computer. It is obvious that the success of her project rests on team members knowing what has to be done and getting it done with little or no supervision. Openness and honesty are her critical success factors.

The reality is that the skills in most demand are in short supply and so the availability of individuals who possess those skills to work on a project is a problem. Out of necessity these professionals are assigned to multiple projects. That raises two management problems that must be attended to.

Cross-Project Dependencies

Consider this scenario. Harry is your only data warehouse design professional. When he finishes the data warehouse design on the Alpha Project, he is scheduled to begin the data warehouse design on the Beta Project. This raises the following management questions:

• Is Harry overcommitted?
• If Project Alpha is delayed, what is the impact on Project Beta?
• Who decides the project priority if there is a scheduling conflict with Harry?
• Can Harry's work on Project Alpha be overlapped with his work on Project Beta?
• What if Harry leaves the company?

These are difficult and complex questions to answer. But they must be answered. Your risk management plan is a good place to look for most of the answers.

Project Portfolio Management

Many of the situations that gave rise to the preceding questions can be mitigated through a project-portfolio management process. The decisions to approve a project for the portfolio can be based on a Human Resource Management System (HRMS). That system should include the skills inventory of all professionals, their current and future commitments, and their availability for additional project assignments. Unfortunately, not many organizations have such systems in place. Instead, they add a project to the portfolio based on its business value. That is all well and good, but not sufficient.

What is sufficient and what you might want to adopt is the Graham-Englund Model,² which answers the following four questions:

• What should we do?
• What can we do?
• What will we do?
• How will we do it?

The answer to the first question is a list of potential projects prioritized usually by business value. The answers to the next two questions can be based solely on the skills inventory and the availability of those skills over the planning horizon of the portfolio and the scheduling needs of the projects in the portfolio. The effective management of the contents of the project portfolio depends on access to a solid HRMS. There are commercially available software systems for portfolio management under a variety of resource constraints. For maximum effectiveness, this HRMS should be housed in a Project Management Office (PMO).

Co-location of the project team members is strongly advised in the Iterative PMLC model and required in the Adaptive PMLC model, but in its absence, Agile projects can still survive and succeed. The challenge is to deliver sound management of such projects despite the challenges of physical separation and time differences.

I developed APF under similar constraints. My team comprised 35 senior professionals spread across 12 time zones. The project was to design and implement an integrated software development PMLC process for Internet/intranet applications for outside clients under a fixed bid contract — a tall order even under the best of circumstances. With some logistical problems that had to be solved before the project started, we were able to hold daily 15-minute team meetings! Of course, there was some juggling of meeting times to minimize the torture inflicted on any one team member.

There are all kinds of technologies to help. Web meetings, instant messaging, and electronic whiteboards are all cost-effective alternatives. Some members of the APF development team cobbled together slide presentations and distributed them ahead of time to all who would be attending a daily team meeting or other meeting they were hosting. Another member built a simple dashboard so all team members could quickly post the status of work in process for presentation at the daily meetings. It wasn't fancy, but it got the job done. The bottom line is that distributed APM teams can be made to work. It just takes a little effort and some creativity. Above all, the value added from these tools needs to be balanced against the time to create and maintain them. Burdening an Agile project with non-value-added work is something to be avoided.