Joseph Flahiff has more than 15 years' experience in agile and traditional project management. For the past five years he has managed agile projects in enterprise organizations exclusively. He now works for a multistate health insurance company, providing agile project management and training for a three-year $20 million project that coordinates the work of more than 100 team members
Flahiff is the author of a SearchCIO.com agile project management guide that includes real-world examples of agile project best practices, agile project definitions and agile terminology. Here and in a follow-up story, he outlines the ways an agile project can be managed to make it easier to understand when the often-elusive end date of an agile project can and should be set.
In February 2009, my project team had just completed the key release of a customizable website for employers to use in reporting employees' use of benefits. The main deliverable complete, I was asked to move on, so I handed off the project's completion to someone else. More than a year later, it still was not finished. Sponsors were asking when the website would be done, and for months no one was able to tell them. Finally, the end date was set for the end of the 2009, almost a full year after our first launch. Why did the project go on so long?
Sometimes an agile project seems to have no clear end in sight. Is this just how all agile projects are? Should you, as CIO or executive sponsor, expect this ambiguity in terms of setting the scope, scheduling and budgeting for an agile project and its end date?
Is it a project or a product?
The core of what you experience when you encounter ambiguity in an agile project, is that the agile software development process was not designed as a project management approach, but as a product management approach. This subtle difference lies at the root of much of the messy lack of understanding about the delivery of agile projects.
According to The Project Management Institute, a project is a "temporary endeavor undertaken to create a unique product, service or result." This definition stands in stark contrast to the ongoing nature of product management, which Wikipedia defines as "an organizational lifecycle function within a company dealing with the planning or forecasting or marketing of a product or products at all stages of the product lifecycle."
Table 1 identifies some basic differences between a project management approach and a product management one. The rest of this article uses the terms project and product with these specific definitions in mind.
|Initiation or upgrade.||
|Unique product or service.||Not a unique product or service, maintenance of or updates to an existing product or service.|
|Fixed scope, schedule, budget.|| Ongoing forecasting and planning
for scope schedule and budget.
If a project is a temporary endeavor, how do you know when it is done?
In traditional project management, the project ends when the scope is complete. Success is determined by whether first, the scope is complete; and second and third, whether it's completed on schedule and on budget: These are the three sides of the triple constraint or iron triangle. In a product development approach, the agile method is flexible on scope, but holds schedule and budget constant. When you apply agile to a project, on the other hand, you still look at the traditional variables -- but with a little twist. To determine when an agile project is done, you look at one variable or more. Success, however, ultimately is measured by customer satisfaction.
Does the triple constraint apply to agile projects?
Agile is all about being transparent about what we can and cannot do. In the spirit of transparency, let's be honest: In a software development project, where there are so many completely unknown factors and complexities, we cannot manage all three sides -- scope, schedule and budget -- of the iron triangle accurately. What can be done is to manage one, and report and respond to the others as they dynamically change. You really can fit only five pounds of flour into a five-pound bag, no matter how hard you try to cram more in.
Like a pilot flying a high-speed jet while constantly adjusting pitch, yaw and roll, project managers adjust scope, schedule and budget to bring a project in for a perfect three-point landing: scope complete, on time and on budget . Scope, schedule and budget are the three levers pulled to fly the project. A scope-managed project is one where the scope is of primary importance and needs to be kept constant in order for the project to succeed. Similarly for a schedule-managed or budget-managed project, schedule or budget are key for success, and need to be most closely managed.
To better understand the lifecycle of an agile endeavor, let's take a closer look at how agile projects can be managed by scope, schedule or budget. In this first part, we discuss how and when to use scope to bring your project in for a perfect landing.
Some people will tell you that scope is the one thing that is never managed on an agile project, but is left flexible. In my experience, this point of view just sells agile short. If it were true that you can't manage agile projects' scope, you could never use agile on such mandated projects as Sarbanes-Oxley or Health Insurance Privacy and Acountability Act (HIPAA) compliance. I am living proof that agile can work for fixed-scope projects, because the federally mandated HIPAA 5010 compliance project I am managing is working great. We're benefiting from early releases, early defect resolution, and the general energy that comes from delivering new features successfully every two weeks.
Like a pilot flying a high-speed jet and constantly adjusting pitch, yaw and roll, project managers adjust scope, schedule and budget to bring a project in for that perfect three-point landing.
As the electronic data interchange (EDI) infrastructure is being developed to support the HIPAA 5010 mandate, additional enhancements are being identified constantly. These items are not part of the mandate, but because we are agile, we add them to the product backlog. In traditionally managed projects' scope, schedule and budget, adding scope mid-project is discouraged. Termed scope creep, it is managed through a change-control process. With agile, however, scope can be added to the product backlog at any time. But if you can always add to the backlog, how do you control the scope of an agile project? Won't the project go on forever?
Remember the difference between project management and productmanagement? Being able to add to the product backlog at any time is an attribute of the product-focusednature of agile. Understanding how to manage and maintain the separation between the project and the product backlogs is the key to using agile on a fixed-scope project. When new scope is identified during my HIPAA project, I happily add it to the product backlog -- but I clearly communicate to the team, project sponsors and key stakeholders that this new scope is not part of the project, but will be addressed at a later date through post-project development. It is important that the team, project sponsors and leadership all understand this differentiation. The project scope is held constant, while the product will go on and be maintained under product sustainment for its lifetime.
What happens if the product owner establishes new priorities for the backlog?
Another problem with managing a product backlog on a scope-limited agile project is that the product owner might reorder the priority of the scope items in the backlog at any time. What happens if the product owner moves up in priority one of the newly identified scope items -- one that is beyond the scope of the project? There are two approaches one may take at this point. In both, it is imperative that the product owner be made aware of the effect of his decision. One of the benefits and mandates of agile is that its practices and tools make transparent the impact of leadership's decisions, which are more opaque under other planning models. When the product owner makes a change to add scope to the project, it is managed, and, not unlike traditional projects, the change will affect the schedule and budget. So, the management is left to choose to: push out the end date and increase the budget, or reduce some other piece of the project scope.
Which projects benefit from a fixed-scope approach?
If scope management is good for some projects, which kinds of project benefit from a fixed-scope approach? Typically these are:
- Projects with a clear and well-understood scope that absolutely must be completed.
- Regulatory projects.
- Business mandates.
You may ask why one would use agile on a project with such a well-understood scope. Isn't agile intended for projects that have a lot of ambiguity? There are three situations when you might consider agile for your fixed-scope project:
1. When the organization will benefit from the incremental release of the features that make up the project.
2. If the scope is fixed but there are various possible implementations. The final design benefits from an iterative cycle of development and refinement.
3. If the project scope is fixed but additional features (beyond the ones mandated) are identified along the way. Examples include legal mandates, such as HIPAA, federal tax projects and so forth.
Scope management is just one option available to agile project managers. In the follow-up story, we will look at schedule and budget, the other sides of the iron triangle.