The Many Faces of Agile Integration

Programs, even simple projects, can seem like exercises in herding cats. If you’re brave enough to manage such an effort, you’ve learned that one of the biggest challenges to progressing is pulling all the pieces together. Requirements for cost, schedule, personnel, and quality are only some of our concerns when we set out to deliver value to our customer. Rather than turn this into some lecture Project Management Institute (PMI) describes in its PMBOK, however, I’d like to discuss an approach many are trying to use to streamline execution.

I wouldn’t blame you if you just cried “Bingo” to your co-workers, having now completed your cliché cover-all card. Nonetheless, humor me. All the buzzwords will be made clear at the outset. And one of those daunting catch phrases I’d like to discuss is a little term PMI calls “agile integration.” It need not be so unnerving.

The term “agile” is a subject of some controversy within government circles. Our superiors elevate those who manage projects with the flexibility that this ideal conveys. We are encouraged to adopt this mindset, amid an unspoken dissuasion of rigidity. It makes sense, if you consider the perspective of our leadership who seem intent on breeding a “can do” attitude among the workforce. After all, who wants to be told that he can’t have that shiny new feature? “Be a little more flexible,” they say, in so many words.

And so, it seems we have adopted the use of agile integration to progress efforts with an eye toward driving flexibility. Inevitably, however there will be compromises. Stakeholder satisfaction, and bottom-line expectations are only some of the concerns that weigh in the balance when we plan these types of efforts.

Still, we have learned to pick our battles. Sometimes the need to flush out the technical details of a solution can simmer on the back burner while we deal with more pressing issues. Let’s say we run into some funding problems. As we shift our focus from pushing for deliverables to negotiating a budget solution, our teams forge ahead. Who knows? Maybe the downtime allows them to dream up a better solution, possibly even cheaper than everyone initially imagined.

At the program level, we might seize the opportunity to use the freed-up labor to crash the schedule on another effort. Then again, we may swap the team out with some other employees we’ve been wanting to send to training. We might allow someone a long-awaited vacation. The expertise we are using may be the kind that lends itself to lulls in execution. However, resources are free. And resources who are free can be utilized in any number of ways.

This approach to the agile objective, however, falls short. Consider the old mantra, “You can have fast, cheap, or good. Pick two.” That is to say, you can crash the schedule for a high-quality product, but it will be costly. You can ration out the limited finances you can afford over time to achieve an upscale result, but it won’t be fast. And of course, you can produce quickly on the cheap, but the finished product will likely not be one of high quality. There are always limitations.

Well into execution, variables such as quality don’t lend themselves to course alterations. The nature of many products, particularly those produced in a linear fashion (e.g., schedule of deployments) do not allow the rework necessary for quality changes. For this reason, quality issues need to be determined, not as a planning matter, but as an entirely separate project, previous or subsequent to any implementation – a design matter.

Consider the alternative. Has the project’s sponsor made any provisions for your team to revisit work completed per the initial quality standards? Do you have the expertise available to correct the issues that require rework? Even if you do, are you familiar enough with the sponsor’s standards to make alterations appropriate to the target environment? I could go on. Suffice to say that rework to address quality needs to be documented and carefully planned before proceeding with any changes.

Given the broader array of resources available at the program level, however, the expertise, the understanding, the relationships, and any other elements that may be required to accomplish quality rework could be available. To determine that, a careful review of these and likely other relevant factors need to be weighed. Perhaps the engineering needed to accomplish the change is minimal. One level up, program managers command a whole different set of resources that could make the rework a consideration.

And so, the question arises: Are we to practice the agile methodology at the program level, but not necessarily the project level? As we’ve found, at the level of the project, overcoming some of these limitations can be achieved with an attitude of flexibility at the outset. “Agile” flexibility, however, lies in the management methodology, not within the project’s planning. Project managers who attempt to channel that flexibility into planning are practicing what PMI calls “rolling wave planning” rather than conducting agile projects. There is a difference.

Agile projects occur in iterations. Many times, those iterations are a series of optimization efforts that enhance an existing product. Efforts like software development are ideal candidates for the agile methodology. A schedule of implementations or a manufacturing process that requires an engineering team to deliver a complete design ready for customer use is difficult to iterate over time. That is not to say that a finished product cannot benefit from a subsequent version. It’s just that, once a product is in the hands of the customer, it is difficult to optimize.

It is plain to see why integrating the agile methodology into the project management process is the daunting task feared by so many. No matter how much pressure we may feel to force agile integration, it is not always the most sensible approach. Given the expectations of our leadership, difficult conversations may be in order. It is always wise to help our customers understand the limitations of progress.

Assuming you and your customers agree to follow through with an agile integration, the effort is best approached with the cooperation of the PMO at the program level. If not promulgated by the PMO, managers of individual projects may find that they do not have the support they need to make the adjustment. Likewise, forcing the change at the level of the portfolio may impose the “one size fits all” requirement discussed above. At the program level, however, projects will have a common flavor that may stand to benefit from the method, and individual PMs will have the opportunity to share the lessons they learn.

There is an array of approaches to the agile practice: scrum, kanban, lean, xp, which may be used as the framework necessary to get started. Leaders can tweak any one of these to suit their efforts. Just remember: while there is nothing wrong with integrating agile tactics, that does not necessarily amount to integrating the agile methodology.

For more information on this and other project management related topics, see pmi.org.