How Agile Development Methods and ITPM Help With Cost Control

Situation: You are considering an Agile/Traditional mix of approaches.

When you think of portfolio management, traditional approaches to project management seem to be a natural fit.  However, Agile approaches, with their tight focus on business needs, are steadily increasing in popularity.  In many cases, Agile is used within the core development team, but as part of a larger, phased delivery project.  These “blended approach” organizations still have a need to practice sound project and program management disciplines, but allow the Agile teams to work in the manner associated with that approach. An ITPM solution is required to manage the total project portfolio, but must be flexible enough to address these different methodologies.   In the end, IT must manage the end to end Agile development effort, from backlog to sprint delivery, all within the context of the broader Project Portfolio view.  All of this seems difficult enough to manage on its own.  So how can these varied solutions go one step further and help you control costs?

We recently spoke with Rick Moreau, Director of Field Enablement, Compuware Changepoint Solutions, who has a great deal of practical experience in this area.  Here’s what he had to say about how it all fits together.



Q.  Mechanically, dealing with efforts that are a mix of traditional and Agile approaches seems tricky.  Can you give us a few “rules of the road” for making it work efficiently and effectively?

Your introduction hits the nail on the head: Organizations need to be able to leverage an Agile development approach, but still need to make higher level decisions utilizing a portfolio management discipline. So the decisions about which projects to take on, which investments to make, etc. are still handled by the demand management and assessment functionality of the portfolio management process. Once the decision has been made to take on a particular project, some or all of that project may be managed using Agile.

The key is that some boundaries have been set for the project as a whole, such as start and finish dates, total budget and perhaps even the minimum included scope. The Agile teams then take over to do the detailed planning of the sprints or iterations.



Q.  The Agile mindset is often described as beginning with the concept that “your initial plan is wrong”.  Done incorrectly, that can make end results questionable or less predictable – which doesn’t help when you are prioritizing projects, managing resources, and cost.  How do you manage that from a PPM perspective?

I’m not sure I agree with the Agile mindset taking the position that “your initial plan is wrong.” The Agile mindset is more about deciding what can get done and in what order, rather than laying it all out in a detailed plan in advance. Agile teams will make a “best guess” at what they can complete and will then refine the requirements and associated estimates as development proceeds.

I think that the PPM perspective and the Agile mindset can co-exist in an organization. As a matter of fact, they will have to co-exist or that organization will have tremendous difficulty delivering value to the organization.

If we look at the basics of Agile we see a reasonable initial estimate of the size and make-up of the sprint teams, duration and number of sprints in the overall project plan. This gives us what we need for resource demand and capacity analysis. The identification of critical or high priority backlog items gives us what we need for “minimum scope.” So the PPM perspective has what it needs at the high-level for planning the resource utilization, schedule and cost.

The Agile mindset can then take over the detailed planning at the sprint level, working within the boundaries of the dates, sprint team size and priority backlog items. They organize and prioritize using the Agile processes and add additional items if capacity is available.

I see that as not much different than traditional project planning on a large project. Many projects cannot and do not have detailed project plans from the very start. They have high-level tasks identified for various work packages, with a best guess of resource needs and dates. As the project proceeds, these high-level tasks get defined to a more detailed level, usually 90 days out. Conceptually, that is the same thing we are talking about to support Agile within the larger discipline of PPM, except we may now only be talking 30 days out.



Q.  Do you feel that, generally speaking “more Agile” = “more business alignment”?  What are the implications here from a cost perspective?       

The theory behind Agile definitely means more business alignment, no doubt about it. The product owner--i.e. the business representatives--identify the requirements and prioritize them. They have the right to change them anytime they want, expanding the requirements, changing priority of items, etc. The role of the Agile teams is to do the things the product owner says are most important. As long as the product owner is representing the business, and not just a resource within development, you can’t help but be more aligned with the business.

But realize that the alignment with the business starts earlier than the Agile portions. The decisions to do a project or build a product or have another release should be made with business alignment at the forefront. Business alignment starts with the portfolio planning decisions. The Agile portion simply helps the development groups maximize that alignment and value by working very closely with the product owner.

From a cost perspective, I think organizations have more visibility and control than they may originally think. People tend to think that Agile gives away all ability to have a budget and track costs. That’s simply not true. Backlog items have an estimated effort associated with them, sprints have a planned duration and team size. This provides us what we need to build a project budget and have an initial scope of what we will get for that investment. We can, in essence, build a budget for the sprint and track accordingly.

What we give up is the ability to have a detailed cost estimate for every backlog item or requirement until we get started on that item. We will have the initial estimate based on the backlog estimate, but not the definitive estimate until the team starts working on it. I don’t see this as a huge sacrifice when you consider how many tasks or requirements on a traditional waterfall approach end up going through a change request process, or at least should.


 
Q.  I understand how Project Management can help reduce costs or enhance ROI, but how can a managed Agile/Traditional blend help you do that more effectively?

I’m not sure a combined approach helps reduce costs, but I think it helps you increase value. What I mean by that is you may spend the same amount on the project, using the same number of people for the same length of time. But you will get the highest priority items delivered as part of the project and delivered in a way that meets the requirements of the business, since they will be able to refine those requirements through the Agile process. If all goes well, the Agile process will allow you to include even more things in the project than originally included, thereby increasing the value even more.

In the worse case, the high priority items may turn out to be so complex that the project cannot meet the initial items within the desired timeframe. That may lead to a decision to stop the project altogether. That should become evident early in the Agile cycles, so the cost of proceeding with the initial sprint and then determining if that is acceptable is likely no different than the traditional spending on an initial “definition” phase.

The key is to have the discipline to stop the project if it will not be delivering the required payback, whether that is determined in a traditional definition phase or in the first few sprints of an Agile process.



Q.  I’ve had conversations with analysts that describe your Agile integration approach as industry leading.  Your leadership position in this month’s Gartner Magic Quadrant and the report narrative seem to support that as well.  What specific or unique tool features enable effective Agile integration? (and Why?)  What have you learned from implementations so far and what future changes are coming as a result?

There are four areas of Changepoint functionality that have existed for several years and allowed us to incorporate support for Agile without having to build customizations to the core code. The first is request management, which is the ability to capture an “item” of any type, route it for initial review and place it into various statuses. This provides the functionality needed to capture and track product backlog requirements. It gives us the flexibility needed to support any different type of requirement and any preliminary review process a customer may desire leading up to placing the item in the backlog.

The second area is our configurable workflow and the ability to define a logic step, which is the ability to have the workflow perform a complex action. We have leveraged this to take the items selected for the sprint and automatically create the sprint tasks and assignments on the project plan, so the team members do not have to.

The third area is the ability to have distributed project managers within a Changepoint project. This allows you to have a defined user at a summary task level that can add and remove tasks just to that portion of the project plan. We refer to this as Summary Task Managers, but it was also perfect functionality to support the concept of the Scrum Master, who can add and remove tasks within a scrum or sprint.

The final area is the Changepoint Report Designer. It provided the functionality we needed to build the various reports necessary for the Agile teams, such as the backlog reports, burn-up and burn-down and the sprint task board.

Compuware Changepoint recently introduced an Agile Accelerator which is a pre-configured version of the Changepoint solution. The accelerator leverages the functionality mentioned to deliver best practices to support agile development processes and the associated reporting requirements, giving customers a starting point to manage agile development within a broader portfolio of projects.

It is still early for much implementation experience, but one thing we are seeing is that all companies do things slightly different, even with Agile. We have seen this over the years with respect to standard project management processes and it also holds true with Agile. Fortunately for us and our customers, the flexibility of Changepoint allows them to easily make changes to the configuration, workflow and reports to meet their specific process.