The purpose of this document is to examine Agile to determine if it meets the needs of developers at the expense of meeting the needs of the organization.
From a purely business perspective, projects should be selected based upon an ROI (Return on Investment). Those with the highest differential between value and cost should be selected assuming no legal requirements for other projects exist.
In the traditional PMBOK model, one should be able to determine the cost of the project based upon breaking the work down in a WBS (Work Breakdown Structure), then adding costs for initiating and planning, meetings, project manager, risk reserve, etc. These costs can be compared with the value of the completed project and – VOILA! An informed decision may be made.
In agile, the work to accomplish a sprint (Scrum term for a 2-4 week release cycle), is determined just before the work begins for that sprint. Though a backlog (Scrum term for deliverables or potential deliverables) has been established for the project, no determination nor proper estimation of work to be accomplished to complete the backlog is performed until the backlog item for a sprint is selected. Therefore – no budget can be determined.
For this reason, scrum projects cannot be selected based upon ROI. The nearest alternative? Work (backlog) to be accomplished in a sprint can be selected based upon which provides the best return. ROI remains elusive.
Therefore, PMBOK projects can be selected based upon ROI. Agile projects cannot.
Project End Point
One of our clients in an agile environment decries the point that “once an agile project is initiated, there is no end to it. There always seems to be something worthwhile to do”. This issue makes the definition of what constitutes a project hazy at best. When does an agile project cease being a project and begin being “real work”? If a team is coding a website and making changes to it every two weeks, updating that website has become regular work and is no longer a project.
Other Confounding Issues
There are a number of other issues that seem to preclude agile from being considered a project methodology:
- Agile uses resource leveling. This technique increases cost because work is simply spread across available resources instead of the number and type of resources being determined by the work to be accomplished.
- Stakeholder management is nonexistent. There is only one person representing “the business”. It is only assumed that this person will do a good job of watching out for the needs of the organization. Has this person been trained to utilize tools such as the Stakeholder Register? Methods for gathering requirements? Requirements Traceability Matrix? The fate of the project meeting the needs of the organization may be put into the hands of someone untrained to fill that role.
- There is an extreme lack of documentation.
- There exists no standard method of evaluating metrics other than velocity. For example, metrics such as EAC (Estimate at Completion), BV (Budget Variance), ETC (Estimate to Complete) cannot be performed to compare how the project is performing against the budget, because there is no formalized approach to establishing a budget, little scope definition, etc. Therefore, how can you tell how the project is performing against the budget or the schedule? Oh, right… Proper budgeting and scheduling techniques were not used.
- Agile teams tend to be employed for longer periods of time because they are working on real work instead of a project.
- Releases are consistent with time frames – regardless of the additional costs of rolling code into production that may not include valued deliverables because the time frame was simply too short.
- Constant release patterns increase costs related to those releases.
Agile does maintain advantage over PMBOK in that agile delivers usable product every couple of weeks. PMBOK projects may take years to result in any benefits. By the time those very large PMBOK projects are complete, the business need for the project may have disappeared. For this reason, many very large projects become wasted money since the product of the project may be delivered and never used.
If one were to plan the project utilizing PMBOK, but establishing milestones that represent agile releases, one can build the WBS to include all efforts to roll the milestone into production. This way, the organization maintains the following benefits:
- Useable releases on a consistent basis
- Proper stakeholder identification and requirements gathering
- An end point
- Properly developed budgets and schedules
- Meaningful metrics to track the progress of the project against the budget and schedule.
Essentially, a hybrid between Agile and PMBOK may produce the greatest value for the organization.