Agile Mindset and EVM Methodology
In my last article, I talked about different experiences I’ve had while transforming a team to an Agile mindset. This month I’m going to talk about how to manage an EVM (Earned Value Management) project where the software development is performed by an Agile team. In case you’ve forgotten, most of my background is in the defense industry so my EVM experience and the statements in this article will come from that perspective. I don’t expect to cover all the details in this single article. I’ll try to make some basic points, ask a few questions, and plan to expand on some details in future articles.
So what are the basics? Fundamentally, I believe it starts with the fact that EVM and Agile make some very different high-level assumptions. I think two of the values in the Agile Manifesto are a clear indication of these differences. Let’s look at those two values.
Customer collaboration over contract negotiation
EVM is very much about contract negotiation. The customer generally has a budget, a desired delivery date, and a specific set of requirements. All the parameters are defined up front and the contractor is expected to deliver within all three constraints. That’s the basic premise. EVM is a methodology to monitor progress against a baseline plan to deliver the product (satisfying requirements stated at the beginning) within the agreed cost and schedule.
Agile is about customer collaboration. Agile doesn’t ignore the parameters that were defined up front, but rather recognizes that we probably don’t know everything up front. That’s why we strive to identify issues and risks as we go. So rather than try to continue to squeeze the developers and the test cycle, the mindset shifts to admit that there will be challenges and we all will work together to come up with the best solutions. Maybe it’s additional funding or schedule, or maybe it’s prioritizing some requirements and leaving others to a future release.
Responding to change over following a plan
Similar to the previous value, EVM is about creating a plan. EVM expects the contractor to develop a plan up front, baseline that plan, and track progress to that plan until project completion. Making changes to the baseline plan is intentionally difficult. EVM assumes we know about the entire product to make good decisions and plans up front. Unfortunately, in order to win on cost, the contractor often makes “best case” assumptions, identifies a handful of risks, and calls it a plan.
On the other hand, Agile recognizes that we’re unlikely to know enough to make all the right decisions up front. We’ll inevitably run into unanticipated problems and challenges and need to adapt. When that happens, we need to change the plan. Rather than spend exorbitant amounts of energy up front to develop an executable two or three year plan, Agile teams focus on the near term first and intentionally leave later items a little more vague. Agile teams respond to change and expect to adjust the plan along the way.
领英推荐
To be clear, it’s not that Agile ignores the items on the right. That is absolutely not true. The manifesto itself states “while there is value in the items on the right, we value the items on the left more.” There still needs to be a contract. However, maybe we need to work on new ways to structure those contracts. Obviously, we can’t go back to the days where everything is a “level of effort” and contracts are all cost plus. There needs to be a middle ground.
But let’s be honest. How often do EVM programs effectively perform and stay within all the constraints that were imposed when the contract was awarded? There will be challenges. The plan will change. Let’s admit that and work together with our customer to adapt, adjust, and be responsive.
Finally, to be fair, Agile probably works better for companies developing products to sell as opposed to contracted products. The developing company can make trade-offs based on the market demands. All the cost, schedule, and feature prioritization decisions are internal. However, I think it can work for the defense industry too. There are too many advantages to Agile development to not find ways to make it work for everyone - developers, finance organizations, and customers.
Do you have any experiences balancing Agile mindset and EVM methodology you’d like to share in the comments? I’d love to hear your thoughts in the comments below. I’d also encourage you to share this post on your own feed. The more discussion, the better.
________________________
Banner Photo by Yan Krukov from Pexels
Handshake Photo by PNW Production from Pexels
Chess Pieces Photo by Syed Hasan Mehdi from Pexels
________________________
I should probably come up with a more legal sounding disclaimer, but for now, I’ll go with this. The views and opinions expressed in this newsletter are solely my own and do not necessarily reflect the opinions of LinkedIn, my current or former employers, my alma mater, my church, or my family.