My colleague Bill Baxter informed me that PMI had just released the Earned Value Management (EVM) guide in December 2019 and that I should take a look. My first thought was, “Geez I hope they aren’t going to force EVM on to agile projects”. Which of course they did.
Those of you born after 1990 have probably never heard of EVM. Unless you are working in the government sector where it may be a requirement.
Earned Value is an old-school way of viewing project costs, schedule and scope together to determine your performance. EVM focuses on delivery against those “triple constraints” which unfortunately tends to be the primary objective of traditional project managers who strive to deliver OTOBOS. While it may be required for some government projects, EVM should never be used on Agile initiatives. Yet that is exactly what PMI is trying to do.
My complaints about Earned Value Management include:
- EVM calculations are based on detailed and accurate upfront planning that doesn’t exist in agile project.
- EVM ignores the delivery of business benefits.
- EVM misuses the term “value”
- In reality, no value is delivered until the customer receives the working solution.
Let’s take a closer look, starting with a little bit of background.
Some Background on Earned Value Management
New EVM Standard Published in December 2019
This most recent standard for Earned Value Management was published in December 2019. Up till now, I don’t think many people were trying to force-fit EVM on Agile Initiatives.
The most previous version of the PMI Earned Value Management Standard was the second edition, published in 2011. That 2011 version doesn’t mention agile projects at all.
True to the PMI tradition, the 2019 EVM standard is a bloated 182 pages of detailed explanation for a topic that could be explained in 18 pages. Thankfully, the two sections of the document that describe how EVM can be applied to Agile and Hybrid environments is a relatively sparse 9 pages; it probably could have been one simple statement: “Don’t Do It!”
Calculating Earned Value Management
I don’t profess to be an expert on Earned Value Management. I learned just enough about EVM back in the 1990s to teach it in various IT Project Management courses. I never worked in an environment where I was required to use it.
In short, EVM is a way to track whether or not you are spending and completing work at the speed that you planned it. Nothing else. It does this by comparing your planned cost and schedule per item to the actual. Rather than just provide a % complete spend, it can reveal problems by showing how much of the planned “work” you spent got done.
Calculating EVM is straightforward. EVM looks at the relationship between 3 project constraints: time, cost and scope. We use the plan and actual for these triple constraints to calculate Planned Value, Earned Value and Actual Cost:
- Planned Value (PV) – This is the cost of the work you plan to get done at a specific point in time. Though it is labeled as value, it is truly the cost of the work.
- Earned Value (EV) – Earned value represents the cost of the work that you actually completed at a point in time. value of the work delivered.
- Actual Cost (AC) – Actual cost is the cost in dollars that you actually spent to complete the work at a specific point in time.
EVM is Based on Detailed Planning Upfront
One of the biggest problems with EVM is that it is all based on having detailed plans upfront. And not having too much change which doesn’t fit with agile initiatives.
Mike Griffiths has been straddling the agile and PMI schools of thought for over a decade now. I recommend his PMI-ACP prep book to everyone who is pursuing that certification. Here is what Mike wrote in 2007 about applying EVM to agile projects:
There are fundamental problems using EVA on agile projects relating to baseline plan quality. Also there are better alternatives available for agile projects.
Earned Value analysis and reporting measures conformance and performance to a baselined plan. So, given that on agile projects we know that our initial plans are likely to change, why track progress against a weak plan?
— Mike Griffiths, Using Earned Value on Agile Projects
You can also see the problem in the statements that PMI makes in the Agile Practice Guide. You may recall that PMI jointly produced the Agile Practice Guide with the Agile Alliance back in 2017. I went back to look at my previous post on the Agile Practice Guide and saw that I had criticized the inclusion of Earned Value in my review. I called it a “weird fascination”.
The statement below from the Practice Guide reflects a key challenge with applying EVM to agile:
Traditional EVM metrics like schedule performance index (SPI) and cost performance index (CPI) can be easily translated into agile terms. For example, if the team planned to complete 30 story points in an iteration, but only completed 25 then the SPI is 25/30 or 0.83 (the team is working at only 83% of the rate planned). Likewise, CPI is the earned value (completed features value) to date divided by the actual costs to date or, as shown in Figure 5-6, $2.2M / $2.8M = 0.79. This means a result of only 79 cents on the dollar compared to plan (but of course this assumes that the prediction is still correct.)
–Project Management Institute, Agile Practice Guide (2017)
The problem is that our calculations are from a baseline that is a best guess and is expected to change. We then calculate performance indexes against those guestimates and come up with conclusions like the following:
- “the team is working at only 83% of the planned rate“
- “a result of only 79 cents on the dollar compared to plan“
First, it sounds like the team is not working as hard as they should. And second, it is a measure from someone outside the team about the best guesses (story points) that the team could complete in a sprint. Never mind that a focus on measures like this will have the undesirable impact of the team gaming the measure so that they always hit (or exceed) their estimates in the future.
The problem here is that EVM is based on a detailed and accurate “plan” at the start of the initiative. And Agile avoids that detailed upfront planning because it usually represents waste and throwaway work.
In an agile project, the backlog and release plan may be a best guess based on high-level estimates of the work using imprecise measures like story points. So your actual results are highly likely to differ from the baseline you created. Remember the Agile Value statement, Responding to Change vs. Following a Plan?
If your results fall short of the plan, how can you possibly know if it is because the team did not perform well or that your original estimates were wrong? This comparison is back to reliance on plan-driven methods and assumes or is predicated on the ability to accurately forecast the future. Focusing on the variance is navel-gazing at best.
This effort to compare plan to actual serves no purpose except to encourage gaming and other dysfunctions, and to create a lot of work for the person calculating EVM. In fact, PMs who apply EVM to agile initiatives will find themselves chasing their tails trying to determine why their actuals are not matching the plan (they almost never do!). If you love to hunker down at your desk, endlessly manipulating MS Project and exporting it to MS Excel for hours on end, this is a great tool to help you achieve that.
One other problem is that the PMI proposal for EVM would take agile projects back in time to the “% complete” mentality and style of progress reporting. Which is exactly the wrong direction. According to the standard:
The key assumption in agile environments is that the ratio of story points completed to the total story points planned for a release is a good measure of the actual percent complete”.
— Project Management Institute, The Standard for Earned Value Management (2019)
Aha, we are back to using % complete to report progress. Awesome. What happened to value-driven delivery?
EVM Ignores the Delivery of Business Benefits
Section 3.5 of the 2019 EVM Standard (Applying EVM in an Agile/Hybrid Environment) starts off with a statement about how both plan-driven and agile approaches need to be aligned to achieve business objectives and we need to measure progress.
“All project teams should ensure that work is aligned to key business objectives. It is important that management at all levels can see that the overall progress is measured, risks are managed, and the wider view across the project is maintained”.
— Project Management Institute, The Standard for Earned Value Management (2019)
And that is exactly the rub – EVM doesn’t do anything to ensure the work is aligned to key business objectives, nor does it provide visibility to the progress toward those objectives. EVM’s magical properties only extend to tracking the relationships between planned and actual cost, schedule and scope. If your business objectives are to achieve some sort of business benefit or value, you won’t get there using Earned Value.
I previously ranted about how PMI focuses too much on the triple constraints in Time to Retire the OTOBOS and how they ignore business value in Why Scope Creep is Complete Bullshit so I won’t repeat it here. The point is, PMI focuses only on ticking off all the tasks in the WBS, and completely ignores the achievement of business benefits. It assumes the achievement of the plan is the goal, not the delivery of business benefit.
Earned Value Management Misuses the word “Value”
When PMI tries to apply EVM to agile initiatives, it mis-uses basic terms and sows confusion. Let’s look at the description of each of these terms from the PMI EVM Standard (see section 4.4.3.2 Calculating PV, EV, and AC within Agile).
The comparison of EV with PV lies at the core of EVM. PV is the value of the work planned for a certain date. It is the entire budget for work to be completed at the planned date. In agile terminology: It is the sum of the estimated feature sizes for all the features up until the planned date.
— Project Management Institute, The Standard for Earned Value Management (2019)
Notice that the PV or planned value, is stated as the value of the work, but then in the next sentence, it becomes clear that it is the budget for that work or the sum of the feature sizes. What PMI is saying is that PV is the cost or what you planned to spend, and that is equal to your estimate in story points. To that I say, cost and story points are not “value”.
Let’s look at Earned Value (EV):
For agile projects or control accounts, EV represents the value of work completed (i.e., total number of story points for all completed user stories times number of completed iterations) at the same date as used for PV. EV is not synonymous with actual cost, nor does the term refer to business value. EV refers to technical performance (work) earned or completed against the baseline or work planned. In agile terminology, it is the value of the completed user stories up until the calculation/status date.
— Project Management Institute, The Standard for Earned Value Management (2019)
In this section, it states the EV is the value of work completed or the number of story points completed. Then the kicker, “EV is not synonymous with actual cost, nor does the term refer to business value“. It goes on to point out that EV is a comparison of actual work compared to a baseline. So the earned value is the spent money and it doesn’t relate to business value.
And then we have another misleading statement “In agile terminology, it is the value of the completed user stories up until the calculation/status date.” No, it is not the value, it is either the cost or the number of story points.
Finally, let’s look at Actual Cost:
Actual cost is what the name implies: the cost in dollars to complete a set of user stories by the team per iteration and is usually derived from work hours recorded by the organization’s time reporting/tracking system.
— Project Management Institute, The Standard for Earned Value Management (2019)
Finally, a cost correctly identified as a cost. In reality, PV, EV, and AC all represent costs. None of them represent value.
Unfortunately, the PMI Standard ignores this and keeps on using the term value when it means cost. How about this statement highlighted below where “story points are mapped into financial value based on a value-per-point conversion rate of $3,500 per point (i.e. the burn rate).”
Agile EVM works by comparing the current release plan (taking into consideration changes to the scope in the product backlog) against actual work completed as captured in the release burnup chart. For example, progress can be shown on a burnup chart as depicted in Figure 4-7, where story points are mapped into financial value based on a value-per-point conversion rate of $3,500 per point (i.e., the burn rate).
Oh my, more misusing story points. The PMI Standard probably also contains a conversion chart of story points to hours as well.
In case it is not clear from the above how EVM works, let us take a very simple example.
A Simple EVM Example
Let’s assume that our initiative is to buy Christmas presents for my wife. I have a budget of $200 and I am going to get her 4 presents, one per week for the weeks leading up to Christmas. Each present will cost $50.
- Sweater ($50)
- Yoga Mat ($50)
- Gift Card ($50)
- Framed photo ($50)
While the first three are items I can buy off Amazon, the fourth is a combination of a nice picture frame, a printed photo, and my effort to come up with some kind words to add as a statement on the photo.
In terms of schedule, I am going to buy one present per week in December. However, though the deliverables may all be bought each week, they won’t be delivered to the customer until Christmas. That is when the customer (my wife) is going to open them up.
Here is what the EVM charts look like at the end of each week:
Week 1: I successfully purchased the sweater for $65. Planned Value was 50, Earned value was $50 and actual cost was $65.
Week 2: I got busy and did not do any shopping. Cumulative Planned Value was 100, Earned value was $50 and actual cost was $65.
Week 3: Whew, I carved out some time and was able to get out and purchase the yoga mat for $25 and the gift card for $50. Cumulative Planned Value was 150, Earned value was $150 and actual cost was $140.
Week 4: In week 4, I purchased the photo frame, and then I spent some time editing the photo to add a cool caption. Cumulative Planned Value was $200, Earned value was $200 and actual cost was $190.
The EVM Charts Don’t Tell the Story
This simple example illustrates two key points:
- The “value” perceived by the customer is not the same as the cost
- The customer doesn’t get any “value” until the solution is delivered
Let’s explain.
The Perceived Value is NOT the same as the Cost
The cost of the four example presents was $190 in total. However, that is not the Value of those presents to the customer no matter what the PV and EV say.
When my wife opens all the presents on Christmas, the “value” she places on the first 3 is almost nothing. The first one (sweater) actually had to be returned since it was the wrong size (my bad). The other two are just meh. But the 4th gift, the framed photo of her and I, this gift makes her cry, and cry. She hugs me. She takes the photo and puts it on a prominent place on her dresser and she looks at it every day.
The EVM calculations are about costs and waste, and they have absolutely nothing to do with value. Value is measured by the customer, and it is detached from the cost. The least costly of the 3 gifts above was the most prized.
There is No Value Until Delivered to the Customer
True value is not delivered until the customer is able to use the solution. In the simple example, the presents are purchased each week but they are not opened until Christmas Day. So there is no value in the customer’s eyes until Christmas. Getting those first presents bought and wrapped incurred cost but there is no value until the day the customer gets it into their hands.
In Lean thinking, all interim deliverables represent work in progress and are therefore waste. So any gifts bought that are not delivered to the customer represent waste.
At the end of the third week, EVM says you have earned value of $150 but the reality is all that you have created is waste at that point. And since we don’t get feedback until the end of the project, we also create risk.
What is the Point? Stop Applying EVM to Agile!
By trying to force-fit traditional approaches like EVM to agile initiatives, PMI continues to miss the boat. While PMI is trying to make some strides in the agile space (See: PMI Goes all in with Disciplined Agile and Flex), this EVM effort just shows that they don’t fully appreciate agile ways of work.
I know that I have probably have readers who love EVM. Don’t send me your hate mail to explain that it is required for your government agile program and how valuable you think it is and all the important project status charts you can get, yada yada yada. That may all be true, and good for you if it is helpful.
Like Scope Creep, the focus on EVM in agile environments is misplaced. Stop.
PMI should start focusing on value delivery, a term they use in the PMI-ACP certification. Not “Earned Value”, but the delivery of true customer value.
For those of you looking to track your agile projects, check out my post on creating reality based forecasts for agile projects. You can use this to create realistic release forecasts and track progress with burndown charts.
When I was first taught about “earned value” some thirty years ago, I made exactly the same point about there being no value until something was delivered. The lecturer simply could not understand that point at all. The real problem is the term “value”. It’s an attempt to turn expenditure into some sort of progress measure and fails hopelessly at it.
Hi Keith, thanks for weighing in. Yes the term “value” is one of the key problems. Too much focus on the triple constraint and not enough focus on delivering what the customer needs and getting feedback.
I hope this post was of value to you!
Anthony
Before using EVM my agile projects were a disaster … this technique has worked for me in software development projects …
Hi Keith, thanks for weighing in and sharing your experience. Perhaps you can share how you are using it that made it so helpful?
Cheers!
Anthony
It seems to me that the very idea of trying to apply EVM discipline to an Agile work effort is like an oil-slimed albatross with one wing missing and the other badly broken. It will never fly.
As Anthony indicated, EVM measures progress relative to detailed cost estimates, and such estimates simply will not exist in a true Agile work effort. They cannot be created up front because the scope cannot be defined up front in sufficient detail. That was why you needed an Agile mode in the first place!
Still, one has to wonder how to integrate an Agile work effort into a larger, generally predictive DOD project where use of EVM reporting is contractually required. Perhaps just keep it simple and use a ‘level of effort’ EVM ‘value recognition rule’ for the small Agile portion of the project.
Bill, thanks for your comments and for sparking the topic in the first place. I LOVE your oil-slimed albatross metaphor.
Thanks!
Anthony
If not EVM, what method(s) do you suggest to measure the project performance at any time?
Hi Maxim, is your goal to determine how the team is doing vs. a planned delivery schedule and scope? Or are you trying to determine if the project is a success?
If the latter, I would meet with the team, the Product Owner and users or stakeholders. I would ask about number of releases of working solutions over the last 90 days. I would evaluate whether customers are adopting the product, measure new feature usage or determine the ROI for new features. Project performance is the delivery of real value to real customers, IMHO.
If the former, I would ask a PM to pick a color – red, amber or green. And they will say green.
Anthony
I find this to be an unsatisfying answer. There has to be a leading indicator that project isn’t going to be successful as opposed to waiting until the end or asking the Scrummaster his or her opinion. Your response implies that Agile shouldn’t be applied to large, complicated project … which of course is true in some cases.
The issue here is that you are thinking in waterfall terms. There’s nothing innately wrong with that, but people have got to stop believing they can effectively serve both masters at the same time. You can go through the exercise of adapting EVM for agile projects (I’ve even done it myself!) but ultimately it doesn’t show anything of actual value and just sets up bad expectations or things to shove under a microscope.
Breath of fresh air. I was studying for the PMI-ACP, and just couldn’t really understand when / why I would use EVM for anything in an Agile environment (unless I had time on my hands). I feel like it is a clever practice, but ultimately I don’t see the value it brings to (most) businesses, as if I started talking in EVM terms at most customers I’ve worked with, I just don’t think they would understand it anymore or less than if I was simply talking about burnups, points and velocity.
Thanks!
Hi David, thanks for your comments!
Hi Anthony,
Thanks for sharing this perspective!
I would like to put a perspective against it; as I do see value in EVM. Only we need to upgrade and make it more flexible.
For example, in your example with the present for your wife. EVM does not fail, but your project setup. You do not involve your wife (business) in the creation of the outcomes. So where a surprise is nice for your wife, for customer it isn’t. They want to get involved in the creation and see value throughout the project; core principle of agile projects.
EVM helps show value created along the way based on deliverables as outcomes. These deliverables are jointly defined as “value”.
Curious about your feedback, happy to discuss further!
I am not familiar with the agile process but have worked in an Engineering, Design and Supply Company for 25 years. Agreed EV has nothing to do with cost. You can be earning your progress on time but still over running the budgets. We never compared this but do answer for the accrued costs. How can we earn 45% of the project progress and only spent 35%? Because most of our monies are on materials and the PO are committed but we are not invoiced until the vendor makes their milestones. We used a 9 step procurement process using ISO 9000 project documentation as tangible triggers that release the milestone. We only use budgets to weigh the materials by cost. So Sox has it mandatory that the as sold is documented and used as the original budget. If you don’t use the as sold plan, how do you measure or track the changes? I mean, you don’t have a plan, so the whole projects you are just executing by the seat of your pants. How do you coordinate free issue materials and fabricator completion dates if your schedule is not created to make the contractual delivery date; how do you know if there are delays caused by the client or small requests which will accumulate to a large amount of budget being spent not on the as sold scope. You can’t measure your planned vs. actual and have an accurate reforecast. Sure our high risk lump sum jobs EVM process tells the PCMs a story on where the project is heading. I have found the most useful theory to use when reforecasting the project until completion is the waterfall effect. It gives you flexibility to make changes on the project but has a plan in place so there is something to measure the actual project exeuction against. If not, how do you give good feedback to proposals so that as each job is proposed, the project budgets are more in alignment with actual execution vs. proposed. So between cash flow actuals & forecasts; engineering actual vs. planned progress and Procurement actual vs. planned progress, PCM can see 3 to 6 months in advance if there could be issued with making the contractual delivery date. If you use agile from start to finish, you ‘may’ find out two months before delivery date that the vendor is behind schedule but issuing us a schedule showing on time progress. That is how we managements to increase our profit margin from 5 % to 12%; taking contingency monies into profit.
Agile EVM works perfectly fine so long as you don’t conflate business-value, assigned by the accountable stakeholder(s), with team metrics assigned by the scrum team(s). The reason it usually fails is that very few real-world business stakeholders are capable of or willing to commit to assigning business value. The reason I’ve run into is, outside of Sales groups, few other business groups are willing to tie any quantification to their projects. Where such quantification willingness exists is almost always too high level and cross-functional to fit into the EVA/M calculation. At companies in more rigid, mature or otherwise compliance driven industries, this is far less of an issue because all project investments require dollar-denominated quantification of expected benefits, making the EV calcs possible without disturbing anything scrum related. Especially when projects are run through fixed standing team value streams. You know how much the standing team costs per temporal period, you know the WACC for the firm, and you know the quantified benefits the project investment is expected to produce (which itself is often a complex analysis on the business side).
I’ve worked in EV for over 20 years. Unfortunately, it hasn’t been very useful because most program managers don’t take the information into account when making decisions. I am excited to merge both Agile and EV on my current assignment. Those of us who fully understand the flexibility of EV recognize that EV and agile can complement each other, however, that is via an agile-ev method, not by using waterfall EV methodology on an agile program. At any rate, I do take this opinion with a grain of salt given that you admit you are not familiar with EV and your knowledge is based on limited introduction to EV more than 20 years ago (when it wasn’t very well understood, used, valued or taught). I still appreciate that you’ve broached the subject.
I have a perspective from managing and working on large DoD acquisition projects that are required to use EVM by Federal Acquisition Regulation (FAR)
Agile processes exist to deliver value to users as soon as possible and iteratively increase the value to users. Agile processes exist because users usually do not know what they want or will value until they see it. “If I had asked people what they wanted, they would have said faster horses.” – Henry Ford If Steve Jobs had asked his customers what they wanted, they would have asked for bigger hardware button on their phones. In fact, that’s what the customers told RIM and Nokia, and how well did that serve them? More importantly, users don’t know what they don’t want until they see it. That’s part of Agile’s “Fail Early” idea. How does failing early impact Earned Value?
Agile is focused on users not customers. Customer write checks. Users have to use your product. EVM is 100% about the customer and supplier and 0% about the user. For that reason alone, EVM is opposite of Agile.
Agile exists to enable progress in the absence of complete requirements. In spite of all the articles claiming otherwise, EVM depends on having the entire scope of work at planning time. The scope of work is determined by the requirements that Agile projects do not have. I have read about “rolling” estimates allowed by EVM and calculating cost and schedule variance for “features” as opposed to user stories or time boxes or releases. I have read about re-baselining whenever the project backlog changes using a change control board. The opposite of Agile is a change control board who meets quarterly and doesn’t make decisions until the next meeting.
Where does Software Requirements Review (SRR), Preliminary Design Review (PDR), Critical Design Review (CDR), Test Readiness Review (TRR) or any other reviews happen in an Agile process? Someone might say that those reviews are only needed in a Waterfall process. Try convincing your government customer that those formal reviews are not needed for Agile processes.
Long story short: I’ve spent 30+ years working on and managing large software projects. Agile has worked better across the board than Waterfall for delivering value to USERS. Customers and Executives expect to see Cost and Schedule Variance at every monthly Project Review. The needs of customers (check writers) and executives are not well met by Agile.
As a final glum note: There is going to be some procurement manager or contractor executive who goes to jail for “waste, fraud, and abuse” because their Agile project did not follow the Federal Acquisition Regulations requirement for EVM in the eyes of a judge and jury who don’t understand the technicalities. Once people start going to jail and companies are fined out of existence, nobody will ever mention Agile again in the context of government work. Putting Agile on your resume will make you unemployable.
Erik, thanks for that very detailed explanation, this helps paint a more complete picture of the utility of EVM to paying customers as well as to the need to adhere to it for Federal projects.
If it was not a FAR requirement – would you still use it? That is, if it wasn’t required by law, would you use it anyway?
Thanks,
Anthony
From a software developer point of view, I prefer Agile processes. I have an anecdotal sense that people are more productive overall using Agile, but of course, I can’t quantify that productivity in any way that produces apples to apples comparison with Waterfall and EVM.
From a Program Manager point of view, the metrics I receive from EVMS are slightly useful. Where I work, I am known as “Mr. No Drama” because my programs have a reputation for smooth Reviews. My secret is in the planning. You could have the same project with the same deliverables, but one plan turns the project into a death march, and the other plan makes failure almost impossible. How?
If there are 100 Contract Deliverables, I identify 1000 or 2000 small internal milestones that contribute to those deliverables. Every milestone is equally weighted in terms of “earned value”. We don’t mess around with 50% done. Every milestone has objective completion criteria, and the milestone is either 100% done or 0% done for reporting purposes. Many of the milestones are simple and easy to achieve like reviewing a documented and posting feedback or submitting a purchase order or documenting a trade-off analysis. At the end of every month, if it looks like we won’t have enough EV for the hours/money spent, a subordinate or I will quickly finish one or more “easy” milestones. I game the system into showing only small schedule and cost variances unless we are under/over staffed or there is some other reasonable justification for variances.
One feature of Agile is that I can’t game the system as easily. The developers set the points, and the points don’t have any absolute value. I can’t say, “Just finish a few easy User Stories” to bump the numbers and get your velocity up because the “easy” User Stories have low point values and won’t effect the numbers much. 🙂 In edition, the developers have a better big picture view of status with Agile. Few developers ever look at EV charts even if I post them somewhere. They also don’t see how their specific contribution effects EV making EV that much less interesting to them. With Agile metrics, everyone on the team knows what everyone else is doing and what is getting done.
To answer your question: EVM has made me a corporate hero in the eyes of the executives, but it has done nothing to improve developer productivity of deliver more value to customers. I will keep using EVM as long as the executives want it. I will game the system so that there is no drama and everyone agrees the projects run smoothy. We’ll finish more or less on time and deliver something that meets all the requirements, and we get paid. Then the delivered weapons system will never be deployed or used because the people who wrote the Statement of Work at proposal time had no idea what the actual users wanted or needed. The actual users didn’t know what they wanted or needed either. They just know the accepted and delivered system isn’t it.
Agile is better for users and developers.
EVMS is better for check writers and executives.
Guess who determines what is used?
The reason commercial companies do not use EVMS is that it doesn’t serve users, and the users are usually the customers (Exceptions for SAP and other systems executives force workers to use) The company goes out of business if it doesn’t make products that users want or need. When the customer is not the user, and the customer has never met the user, and the customer is spending somebody else’s money, the government ends up specifying and buying expensive wastes of electricity.
I exaggerated a bit above. The systems I have delivered are all deployed and operational and doing their jobs. I think that happened in spite of EVMS and not because of EVMS.
I am doing an online course for the PMI-ACP exam and was cruising along great through the lectures till I hit this lecture on EVM and I was like WTH surely this can’t be agile. Ended up googling and reading your article and I’m glad to see I’m not the only one having trouble reconciling EVM with Agile. EVM is probably useful at an executive level – because they want numbers and pretty graphs. But this is a poor reflection of “value” that a project delivers.
I’m reading this post as I figure out how to report on the progress of an initiative that is being delivered using Agile methodology.
I’ve been looking at Burn Down charts instead of EVM to track progress. We have burndown charts per sprint but I created one for the entire initiative that spans 10 sprints.
So far it is looking promising but I’ve only done one interation.
Has anyone tried this? Any feedback on whether this is a more useful way to show progress on Agile projects.
Hi Kate, thank you for your comment. I agree with you that the burndown chart (or burn up chart) may be a better way to track progress. I wrote about creating and tracking projects this way in the following blog post: https://170-187-203-246.ip.linodeusercontent.com/blog/using-reality-based-forecasting-agile-project-management/
You can also learn about this approach including release planning in Mike Cohn’s book, Agile Estimating and Planning. That book is getting a little dated now but still has some relevant concepts.
Thanks again for your comments!
Anthony
Interesting to read an article that confuses the verb form of “Value” with the noun form. How EVM uses the term “value” is not a misuse of the word as it applies to the verb definition. If you wanted to know what value (noun form) that your wife was going to get from your gifts, that is an analysis that you would have needed to do up front before ever embarking on the actions of purchasing those gifts.
What I will grant you is that Agile and EVM can be incompatible when being applied to software sustainment, or unplanned upgrades. I equate that to what I call the “Angry Birds” development. IOW as we get close to Christmas, it is time for my development team to create the bird icons that are holiday festive. What this really boils down to is stewardship of whosever money is being used to develop whatever is being developed. Agile is a great way of software development when I associate a budget to resources and not scope. However, that method is a horrible way to determine when my effort will be done and how much it will ultimately cost. When I know what the required outputs of my software are and I have a set budget and a limited amount of time, both set by a contract or upper management directive, the answer to the above question can’t be; not sure but you will love it when it’s done. While I can use burn down charts and velocity indicators, those are useless if I continue to change what the features are that are associated with my capabilities.
With all that said, misrepresenting the term value doesn’t really do a service to anyone except encourage areas where utilization of both Agile and EVM are appropriate. This is where I must have a known outcome. It might be a better service to focus on the areas where Agile and EVM do not compliment each other. This is where my outcome is constantly changing.
Here’s some applications of EV+Agile that may clarify how to add “value” back to Earned Value
https://app.box.com/file/984922406315?s=i15tlwl3j4jfvyuufxuudajek1v1lywk
https://app.box.com/file/962984376942?s=edlajbjczeto3ki2eegncy0i52sr3w41
as it is practiced on our software intensive system of system using agile SW development process
Glen, thanks for sharing those resources! I will have to take some time to review and see if that changes my view.
Cheers!
Anthony