How to Measure Progress in a Software Project – By Adam Ard
rethinkingsoftware.substack.com
rethinkingsoftware.substack.com
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.
Agile is "it makes sense every day of the week, we should talk often".
My comment strictly refers to many of the articles[0] and comments[1] that push back on the modern incarnation of scrum/agile/whatever. Productivity theater in project management is net harmful to innovation and actual product development velocity, but my point is that we can't go to the other extreme and have no planning or any kind of measurement.
[0] https://rethinkingsoftware.substack.com/p/why-scrum-is-stres...
Agile was ruined because of this need to be predictable and adaptable to plans.
And business folks often overlook that it is predictable and adaptable -- just not in the way project managers were educated in the old days (or even to this day, I don't know) expect.
The guide also mentions the backlog refinement: “ This is an ongoing activity to add details, such as a description, order, and size.” It’s true that scrum doesn’t directly mention story points but tell me whether story points or t-shirt sizing aren’t the two most common ways to size a story.
Those are "Events", activities to support development work. Unless you mean programming, testing, discussions, code reviews, etc are ceremonies as well?
> It’s true that scrum doesn’t directly mention story points but tell me whether story points or t-shirt sizing aren’t the two most common ways to size a story.
Borrowing your own words: "...story points aren’t in any way mandated by the..." Scrum Guide.
Keep what works for you, leave what doesn't.
That is, we estimate a certain set of tasks. For this two-week sprint, we're going to try to do a subset, and that subset adds up to 20 story points. After two weeks, how much did we actually get done? 7 story points. Next sprint we did better, we got 11 done. After a few months, we settle down to an average of 10 story points per two week sprint. Now we know how many hours something is (estimated to be) based on the story points.
Note well: This velocity is a function of the team. If the team composition changes, previously measurements of velocities are no longer valid.
If we were working on one app and just adding features and fixing bugs, maybe it would converge to a consistent average. However, I have always worked on teams that have myriad projects, moving in and out of development, with constant support and interrupt driven work taking up a huge variable amount of time.
So naturally people will come to despise it because managers will want a number and to hold you to that number. A strict number can't be given, but intuitive guess which has certain probability of being in a certain range according to experience can be.
If you have two engineers and one consistently completes 10 points a sprint and the other only completes 2 points a sprint, does that not tell you something about the output of those engineers?
Or as I usually put it: Statistics/charts are for asking questions, not answering them.
Low point stories that take a lot of time are often coordination tasks, and for people who are good at heads down programming, that can be their kryptonite.
It's also possible that Mr 2 Points is not getting fed stories that they could weave into the blocking points of their highest priority task effectively. He is spending a lot of time working on untracked tasks or sneakily working on stories halfway down the backlog. And they can't do it in the open because someone is engaging in Efficiency Theater: we are so far behind on some milestone that the optics of anyone working on anything except that milestone are terrible.
Nevermind that the next milestone needs them and we will be having this Death March repeat again in three months because of it.
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.
If you are doing R&D that is not something you can budget because definition of research is you don't really know what you are searching for - well you have to have some reasonable idea of course but if $20k becomes suddenly $50k that should not be a surprise for R&D.
People might say "but the CRUD app you are building is not real R&D" if you are really building a CRUD app that is like an existing one - setup Wordpress, SAP, Shopify or pick from dozens of existing ones and be done with it. All else is R&D because there is more unknowns than known stuff, there are always integrations with 3rd parties, some workflows that need implementations etc. .
Even building a piece of road - well all tech is there - can end up running over time/budget if for example you find terrain under is not as one expected and it sinks or something and you have to figure out how best to deal with that and there is no expert to deal with that specific type of ground you ran into.
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.
Unfortunately, a lot of unforeseen problems show up during the implementation phase, and people blame the waterfall model for not being flexible (agile) enough to address these.
Now, even more unfortunately, some people interpret agile as not needing to spend time upfront thinking and dive into the implementation straight away, creating an even bigger mess than the waterfall generation could have ever imagined.
my experience is that people spend half the time bikeshedding the obvious problems that waterfall would have identified in much less time, and then still hit the unforeseeable problems after implementation anyway. if they could have been foreseen, they would have been rolled into waterfall.
1. How did you define the scope of "what to build"? Did you have tickets, or some less formal specifications like wiki pages, or simply a verbal agreement? How did you ensure that everyone's on the same page?
2. How did you track the progress of "building a thing"? Did you have some kind of "statuses", or each work basically had only two states -- "not done" and "done"?
3. How did the engineers coordinate on their work? Or every "thing to build" was always done by one single engineer? If the latter, how was it later maintained - always by that same person or did others work on it as well?
Please note that I don't mean to demean your experience -- these are simply issues that pop up in software engineering, and decisions have to be made how to approach them. And not making a decision is also a decision.
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.
in particular i think of Black Triangles https://rampantgames.com/blog/?p=7745 which has been discussed here previously.