On February 2001, seventeen people convened at the Snowbird Ski Resort in Utah to find common ground and develop an alternative approach to document-driven, heavyweight software development processes. The group included representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development and Programmatic Programming. They named themselves the “Agile Alliance” and created and signed the Agile Manifesto which became the cornerstone for the Agile movement.
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and Interactions over Processes and Tools Working Software over Comprehensive Documentation Customer Collaboration over Contract Negotiation Responding to Change over Following a Plan
That is, while there is value in the items on the right, we value the items on the left more.
Agile Streamlines Documentation
Historically, enormous amounts of time were invested in documenting the product for development and delivery. The list was extensive and included technical specifications, requirements, prospectus, interface design documents, test plans, documentation plans, and untimely approvals, resulting in bottlenecks and long cycle times. Agile does not eliminate documentation, rather, it streamlines documentation by providing the developer with just the essentials that are needed to do the work.
People Over Process
Valuing people more highly than processes or tools is easy to understand because it is people who respond to business needs and drive the development process. If the process or the tools drive development the team is less responsive to change and less likely to meet customer needs.
Negotiation vs. Collaboration
Negotiation is the period when the customer and the product manager work out the details of a delivery with points along the way where the details may be renegotiated. Collaboration is a different creature entirely, with development models such as waterfall, customers negotiate the requirements for the product often in great detail prior to any work starting.
This meant the customer was involved in the process of development before development began and after it was completed but not during the process. The agile manifesto describes a customer who is engaged and collaborates throughout the development process, making it much easier for developers to meet the needs of the customer.
Welcoming Change
Traditional software development regarded change as an expense and avoided it whenever possible. The intention was to develop detailed elaborate plans with a defined set of features and dependencies so that the team had a clear understanding of what should be developed and when it should be worked.
Agile welcomes changing requirements, even late in the development and uses rolling wave planning to decompose work just-in-time, without going into elaborate decomposition of the high-level plan.
12 Principles
The Agile Alliance also created 12 principles that support and expand on the four agile manifesto values. These principles have resulted in a number of widely accepted best practices that are used in many agile approaches such as extreme programming, scrum, DSDM, Adaptive Software Development, Crystal, and Feature-Driven Development.
The Agile Manifesto has spread like wildfire since 2001, forever altering the way we develop custom solutions and making impacts far beyond its original software origin.
These are some of the frequently asked questions we receive when discussing EVMS and Agile implementations within the same company or on the same project.
Question 1: What documentation do you have that I can use to help me understand EVMS and Agile and how they are implemented?
Answer 1: There is expansive EVMS documentation, and the EVMS guidelines are well documented. On the other hand, there is little in the way of Agile documentation since the Agile mindset is to be lean and not to document unless absolutely necessary. The DOD released an EVMS and Agile Program Manager’s Desk Guide that can be used for quick reference. H&A has done the homework and has created training for EVMS and Agile.
Question 2: What is the comparable Agile term or artifact for this EVMS artifact (for example the WBS)?
Answer 2: There is no roadmap between EVMS and Agile that is hard and fast. The best approach would be to identify “similar to” situations or likenesses. For example the EVMS WBS is similar to the Product Backlog within Agile. The Steering Committee of The World Congress in Computer Science, Computer Engineering and Applied Computing reported on Constructs to Support Agile and EVMS
Question 3: What roles within the PMO are there for EVMS and for Agile and how do they relate?
Answer 3: In Agile there is no real “management” role. So the PMO roles that are management titled are not germane to Agile. And in the opposite direction, the Agile roles do not really exist within EVMS. For example the Agile “Product Owner” is a person with a customer view of the product and speaks for the customer. In a stretch this could be a high level Software or System Engineer with requirements responsibilities. The Scrum Master is a facilitator on the Scrum team and there is no corresponding EVMS role. The team members organize themselves so there is no team lead like the Control Account manager in an EVM System.
Question 4: Since the Sprint in the Agile/Scrum approach is defined as a time-box with a fixed end date, how do you reconcile that with the EVMS approach of working the task until it is done?
Answer 4: The EVMS baseline can be set above the Sprint level and can correspond to known “mandatory” delivery points such as release deliveries. This will then align the Agile deliveries to the EVMS structure and the two can work together.
Question 5: Does the fact that Agile/Scrum Sprints have very short durations cause a problem with EVMS performance measurement?
Answer 5: Not at all since teams update their progress daily. But it is preferable if the Sprints are four weeks or less and align with the cut-off dates for the EVMS. In that way the EVMS can pull the stated performance from the teams and use it as the input for the EVMS without any translation work. If a Sprint crosses an EVMS period, that would need special consideration.
Question 6: Since Agile work is not really budgeted, how does that reconcile with the EVMS need for budgets and budget control?
Answer 6: Budgets will be held in packages in the EVMS based on the plan for the Sprints and the teams doing the Sprints. The Agile weighting of work will be within the same packages but is not considered to be budgeting; it is weighting of milestones, if anything.
Question 7: We do not like the idea of the 0/100 EV Technique even with milestones. At our company we have an allowance to earn partial credit for milestone work. How does that fit into the EVMS and Agile implementations?
Answer 7: Agile wants to measure work when done. The work should be in such small stories, or tasks, that they are in-process for only a matter of days. Partial credit should not be needed in this situation; if it is, then perhaps there are issues with work definition.
Question 8: Agile applies to software development, but can we use it for other types of work?
Answer 8: Yes. It is a misconception that Agile is for software only. If you are creative you can find ways to use Agile Development in many areas. One company reports it uses it for circuit design and breadboarding resulting in significant time savings.
For additional information about EVMS and Agile see the blog post:
This article provides an introduction to the differences between an Earned Value Management System (EVMS) and Agile approaches on projects, and isolates the challenges of implementing an EVMS on a project where the project management has chosen to follow an Agile approach to the development work. The article explores the principles of EVMS and of Agile, and contrasts them to show where there are inherent conflicts. The article then discusses how the conflicts can be mitigated so that the benefits of both the EVMS and Agile can be obtained from a joint implementation.
Earned Value Management is a 50 +/- year old methodology based on widely accepted principles that applies documented, systematized practices to support the processes of organizing, planning, directing, and controlling large complex projects, of any nature, which contain a high degree of uncertainty.
An EVMS is structured compliant to 32 guidelines that define what a project management information system should be capable of doing to support the program management team. Within the 32 guidelines there is a subset of generally recognized core principles. The core principles are:
Organize the entire scope of the project using a Work Breakdown Structure (WBS).
Organize the project team using an Organization Breakdown Structure (OBS).
Integrate the project work with the project team to create management control points (Control Accounts).
Schedule the project work in the Control Accounts across the entire project duration at the appropriate level of detail.
Establish time-phased budgets for the scheduled work in the Control Accounts.
Establish the scope/schedule/budget baseline as the Performance Measurement Baseline (PMB).
Authorize the scope/schedule/budget and control the start/stop of work.
Periodically measure the schedule and the value of completed work and determine the Earned Value.
Record direct costs (actual costs) and summarize into the Control Accounts.
Compare planned, accomplished, and spent to analyze the performance and associated variances.
Develop realistic time and cost estimates for the remaining effort in the Control Accounts.
Rigorously control changes to the Performance Measurement Baseline.
The EVM concept presented in these guidelines is a sound management approach, that once incorporated on any type of program, whether research and development, construction, production, etc. provides all levels of management with early visibility into cost and schedule problems. Earned Value Management now appears as a contractual requirement on programs world-wide. Primary EVM users include the United States, Europe, England, Canada, Australia, China, and Japan. It is a requirement of many U.S. Government agencies, including the Department of Defense (DoD), the National Aeronautics and Space Administration (NASA), the Department of Energy (DOE), the Intelligence Community, the Department of Homeland Security (DHS), the Federal Aviation Administration (FAA), the Department of Transportation (DOT), Health and Human Services (HHS), and others.
EVMS has been adopted by companies in situations where it is not a contractual requirement so that they can gain the discipline and benefits of the structural management approach discussed in the guidelines.
Flexible Planning with Agile
Agile Background
Agile is a 20 +/- year old approach to applying a mindset that values the use of small, empowered, self-organizing, multi-functional teams, mainly in software development, to establish a test driven product development effort. This uses a series of short, rapid incremental builds within projects with a high degree of uncertainty to achieve shorter development times, lower costs, and products more closely aligned with customer requirements.
Agile does not usually appear as a contractual requirement. The concept is adopted by companies and organizations with the belief that a better product will be produced faster, and with less expense, using this approach than if traditional approaches were followed.
There are a core set of principles for Agile that were initially established in the copyrighted Agile Manifesto. These delineated core principles are:
Early and continuous product delivery.
Deliver working software (product) frequently.
Expect change and respond positively to change.
Developers and project business organization (PMO) work together.
Product-focused build teams are at the core.
Support self-organizing teams – trust among peers.
Encourage face-to-face discussions (involve the user/customer).
Working software is the measure of progress.
Maintain a constant sustainable pace of development.
Simplify the process and the product.
Put the highest value on technical excellence.
Improve team effectivity.
So How Does Agile Work?
The Agile mindset or approach is implemented through a process of defining the product backlog into smaller and smaller subsets of work that are structured in a top down fashion. At the lowest level of product backlog, the work elements or requirements can be prioritized and assigned to teams. The self-organizing teams pull work from the backlog and work the tasks to completion in a series of short, time-fixed Sprints or iterations. Sprints are often from 2 to 4 weeks long.
Because the teams are self-organizing, there is no team manager or team lead. The teams work as a group and only pull from the backlog at the last possible minute, and do minimal planning for each Sprint. If the product backlog is properly deconstructed and defined into user stories, then the planning meeting for an entire 4 week Sprint can be accomplished in a few hours.
The teams design, code, test, integrate, and deliver functionality in every Sprint. Since tested product is output every few weeks, all on the project can see the product being created and can contribute along the timeline, as needed, to provide a complete finished product.
The product owner embodies the customer’s perspective and either accepts or rejects the team’s work. At the latter point of each Sprint, the tested product is demonstrated to the product owner.
High Level Side-by-Side
The two approaches are contrasted in the chart shown below. The EVMS is a methodology that is highly documented and highly systematized, while Agile is just the opposite. It is more of a mindset than a methodology with the preference not to have significant process documentation.
The EVMS is applied to entire projects and contracts, while generally Agile is applied to software portions of projects. However, it could also be used on other development work.
The EVMS is usually a contractual requirement with significant implementation and operation constraints while Agile has none of these. As a contractual requirement, the EVMS carries with it the option for customer reviews and the threat of non-compliance, which entails penalties.
EVM
Agile
Methodology
Mindset
Documented
Self-defined
Systematized
Self-defined
Any type of project
Software development (mainly)
High degree of uncertainty
High degree of uncertainty
Applied to the entire project
Applied to portions of the project
Often a contractual requirement
Adopted not required
Lower Level Side-by-Side
In addition to the high level side-by-side, there are significant differences within the details of the two approaches. These are shown in the side-by-side table below.
Agile
EVMS
Minimal documentation
More documentation
Plan at last moment
Plan ahead to end of project
Scope is flexible
Scope is baselined and controlled
Expect and embrace change
Avoid and/or control change
Schedule (Sprint) is fixed. Timebox ends the Sprint.
End the package when the work is done.
Budget is secondary
Budget is baselined and controlled
Cost collection is not mentioned.
Cost collection at the right level is critical
Accommodate and Capitalize on Differences
It is possible to implement Agile along with an EVMS if the EVMS application is set up to accommodate the differences and capitalize on them.
For example, the main reason that Agile’s embrace of change is a potential problem within an EVMS is because often the EVMS is used to plan too far in advance, and then reacting to change is difficult and expensive. If short term planning in the EVMS can be coordinated with the Agile planning, then the two can coexist.
The Agile free acceptance of scope changes within the backlog runs counter to the EVMS imposition of baseline change control. But if the EVMS baseline can be carefully set at a work level above the busy lowest level ups and downs, the impact to baseline change control is manageable.
A surprising chance to capitalize on Agile, within the EVMS, is found in the Scrum team approach in Agile where the team breaks work down into tasks far below what would normally be done in an EVMS, and then meets daily to update progress and provide corrective action. This low level constant attention means that the EVMS benefits from a better look at real progress as assessed by the real performers.
Not all the compromise needs be on the EVMS side of the equation. The Scrum team operations will often be defined to have the least possible recording of what happens during the Sprint. Since the product is king, then only the product really matters. But that misses the opportunities to capture the actions of the team for analysis, and use in upgrading their skills later. Necessary compromises would include some additional recording of the daily actions of the team and capturing the progress and problems. These would then be used in the EVMS functions of performance measurement, variance analysis, and corrective action planning.
One other compromise in the Agile realm that would be needed is the adoption of some minimum documentation of processes so that team operations can be repeatable and stable. Even a self-organizing team cannot change the way they work every time it wishes. That would raise the risk of a chaotic work environment.
These topics are recapped in the table below.
Agile
EVMS Accommodation
Scope is flexible
Select a higher level package for the baseline
Change is expected and embraced
Have the shortest possible planning horizon
Plan at the last possible minute
Have the shortest possible planning horizon
Daily Scrum Stand-up Meeting
Collect the data and use it for performance measurement
Sprint Review Meeting
Use for periodic measurement and analysis
Sprint Retrospective Meeting
Use in Corrective Action Plans
Lack of documentation
Add minimum documentation to stabilize team operations
Bottom Line
Implementing an EVMS is a challenge itself. Implementing Agile is a challenge too; perhaps a more difficult challenge. Implementing the two approaches side-by-side can seem impossible. But it is possible and even beneficial if done in a way the makes needed accommodations in both arenas for the project’s benefit.
