How to Measure Progress in a Software Project – By Adam Ard

While I loathe the useless abstraction layer that is story points and while I generally agree with all of the points in articles like these, they almost never talk about the other side of the coin, which is the need for predictability.

Predictability is the oil that makes nearly every software business run efficiently and smoothly. It affects everything from software development to product roadmap to financial efficiency and profitability. Startups need to know if they have the ability to implement critical functionality before they're out of runway; big companies need to be able to coordinate product development, contracts, delivery dates, product launches across many disparate teams with interconnecting dependencies. Even deciding whether or not something is a roadmap priority requires some concept of how quickly you can implement it.

So yes, productivity theater, as it exists in many project management processes today is unnecessary overhead and wasted time/money. But unless you are id software in the late 90s—flush with cash and sitting on a couple of products that only you can bring to market—you can't rely on "it'll be done when it's done" or "you'll know when it's ready when you see it" and expect to remain competitive for long.

EDIT: Mobile typos.

I like this mentality, truly, makes perfect sense. Check in often to make sure you’re building the right thing. Keep going until it’s done.

However, the client is going to want to know (A) how much it’s going to cost, and (B) how long it’s going to take. These are extremely reasonable questions in most cases/industries. To answer these questions with a shrug is a nonstarter. The client is working with a time budget and a financial budget, and they need to have some sense of the numbers.

If the Waterfall and Agile methods are opposite ends of a spectrum, somewhere in between is where I’ve found an acceptable middle ground for both developers and clients.

There's no point in measuring progress if you don't have a defined end point.

And if you have a defined endpoint, you will get the "is it far? Are we there yet?" question. For good reasons.

Maybe your software needs to hit at a certain point, or a lot of money will be losts (ask e-commerce folks about Black Friday). That means you'll need to try to course correct as soon as possible if you take the wrong road - "IDK, but we made progress in the last two weeks" isn't helping.

Maybe your software needs a marketing push. The buy for that is months ahead of when it happens. You better know if you can make that date.

Maybe other teams depend on you delivering working software at a certain point.

"We make progress every sprint" is a nice feeling. It doesn't help you in any of those situations. Especially large-scale efforts need some planning and estimation to work out.

Do you rewrite your auth system to modern standards or migrate your infra to k8s ? Some projects take months to complete and don’t deliver value until fully done, so it is valuable to spend some time to do some upfront planning to weigh your options

This was interesting to read as a more "junior" software dev. Aside from Agile, what are other common frameworks that people use, if any?

Hmm... doesn't really offer a suggestion for measuring progress. FWIW, in our dev team, we don't talk about "percent done," but say "percentage of unit tests that pass without mockups" and then "percentage of requirements covered by unit tests." The first measure is pretty easy to quantify, but the second is where ambiguity and guesswork creeps in.

When I got my first EM job in 2011, implementing true agile was the dream. I became a zealot to every PM or business leader that came my way. I insisted that not only would we get more done, but we'd get better quality stuff. It was a beautiful dream.

I wouldn't say my idealism failed all at once, but through death by a thousand cuts. There are lots of scenarios where trying to bootstrap development into agile is simply more difficult without any clear gain...at least when it comes to principles around measuring progress.

In all my time in the industry, I've never met someone who lived true agile for more than a year that wasn't in a very small startup.

I would like to hire you to come read this to my PM daily until he gets it.

It’s not about like or dislike - it should have value in the context for which it’s designed. There are an unlimited amount of ways to do this. Validation in the context of the recipient of the value is the only thing that matters.

while i have only ever worked at places that do some form of agile development, sometimes i think about things that are just foundational elements. to be pedantic, they definitely work. they just, on their own, do not provide any utility. just a means to facilitate things to be constructed later on in development.

in particular i think of Black Triangles https://rampantgames.com/blog/?p=7745 which has been discussed here previously.