4 ms·

This is the conventional wisdom, but in my n=1 experience, I have never seen the “ideal case sequential development” actually work in the wild. The ideal case

This is the conventional wisdom, but in my n=1 experience, I have never seen the “ideal case sequential development” actually work in the wild. The ideal case presumes that everything is known when the sequential development is planned, which is what permits it to be optimized. But in my n=1 experience, everything is not known, the development team is constantly discovering new information, requirements change, and the ideal plan never works out as originally envisioned, whether we tried to develop sequentially or not. But the “ideal” plan is often like highly optimized code: Expensive to change. So it has its own cost that cannot be escaped. So I am left extremely cynical about the “ideal sequential development” approach. It always seems at the outset to be cheaper and faster, but ends up being expensive and inflexible. JM2C. —— Now if you want something REALLY expensive, I give you “Scrumfall,” a plan where you combine the costs of iterative development with the inflexibility and attendant costs of fixed date, fixed scope, and attempt to optimize sequential development. But hey, you get to wear an “agile” badge, even though “inspect and adapt” has no place in the process.

kabouseng 8y ago
“Scrumfall” - Sounds fun /s >> So I am left extremely cynical about the “ideal sequential development” Off course, in development/engineering work that has unknowns. But taking TFA example of building houses, most / all developers would do the foundations of all the houses first before moving on i.e. working sequentially.
- braythwayt 8y ago
  I have zero to say about TFA’s example, as it is discussing iterating over releases of a longer scale than most people are thinking of when arguing sequential versus iterative development. In my environment, we “inspect and adapt” every two weeks, and we tend to do marketing launches a couple of times a year. But SpaceX was not launching rockets into space every two weeks, so their “iterations” from the outside look more like most companies’ product launches, not like sprints or whatever people call their iterations that happen on a fortnightly or monthly scale.
- smokey_jomo 8y ago
  As someone living in a housing development that’s being built around them, this isn’t true in the case I see. 2 important reasons are: 1) the project is around 6 years in total 2) the company has to fix any issues with the house for the first 2 years. If they did all the foundations first, they’d have exactly the problem described in the article - no money till right at the end. Instead, they get money the entire way along and use that to finance the rest of the project. This isn’t an optimisation, iterative delivery is essential to their viability as a business. They also eat the support costs on houses they build. That means they are repeatedly changing “features” in the houses to minimise those support costs. Just walking down 1 street you can see the evolution of the houses over time as they fixed various small issues with the original design. The houses look basically the same to a casual observer, but are quite stark to someone who lives in one of the versions. They are very obviously agile, and have a great system for inspecting and adapting. That doesnt happen on 2 week cycles, but it does happen at a pace appropriate for them.
coldcode 8y ago
At my employer I think we have a patent of scrummerfall. Or as I like to call it, waterfolly. We have to make detailed user story level estimates a year in advance, create capital requests to be budgeted with precise deadlines and staff based on numbers in spreadsheets, and call ourselves agile. Of course it never works yet we use our agile mindset to find some excuse to blame it on.
pault 8y ago
I've been calling it "wagile" and it's so bad at my day job that it makes me want to cry in frustration some days. I hope they give me an exit interview.
magicalhippo 8y ago
There is the pressure though to deliver this small feature ASAP, rather than putting in the work to make it flexible enough for the stuff that's highly likely to come down the road. For a lot of things it doesn't matter, but for some it can be very difficult to change later on, especially if you need to maintain backwards compatibility.

kabouseng 8y ago

“Scrumfall” - Sounds fun /s >> So I am left extremely cynical about the “ideal sequential development” Off course, in development/engineering work that has unknowns. But taking TFA example of building houses, most / all developers would do the foundations of all the houses first before moving on i.e. working sequentially.

braythwayt 8y ago
I have zero to say about TFA’s example, as it is discussing iterating over releases of a longer scale than most people are thinking of when arguing sequential versus iterative development. In my environment, we “inspect and adapt” every two weeks, and we tend to do marketing launches a couple of times a year. But SpaceX was not launching rockets into space every two weeks, so their “iterations” from the outside look more like most companies’ product launches, not like sprints or whatever people call their iterations that happen on a fortnightly or monthly scale.
smokey_jomo 8y ago
As someone living in a housing development that’s being built around them, this isn’t true in the case I see. 2 important reasons are: 1) the project is around 6 years in total 2) the company has to fix any issues with the house for the first 2 years. If they did all the foundations first, they’d have exactly the problem described in the article - no money till right at the end. Instead, they get money the entire way along and use that to finance the rest of the project. This isn’t an optimisation, iterative delivery is essential to their viability as a business. They also eat the support costs on houses they build. That means they are repeatedly changing “features” in the houses to minimise those support costs. Just walking down 1 street you can see the evolution of the houses over time as they fixed various small issues with the original design. The houses look basically the same to a casual observer, but are quite stark to someone who lives in one of the versions. They are very obviously agile, and have a great system for inspecting and adapting. That doesnt happen on 2 week cycles, but it does happen at a pace appropriate for them.

coldcode 8y ago

At my employer I think we have a patent of scrummerfall. Or as I like to call it, waterfolly. We have to make detailed user story level estimates a year in advance, create capital requests to be budgeted with precise deadlines and staff based on numbers in spreadsheets, and call ourselves agile. Of course it never works yet we use our agile mindset to find some excuse to blame it on.

pault 8y ago

I've been calling it "wagile" and it's so bad at my day job that it makes me want to cry in frustration some days. I hope they give me an exit interview.

magicalhippo 8y ago

There is the pressure though to deliver this small feature ASAP, rather than putting in the work to make it flexible enough for the stuff that's highly likely to come down the road. For a lot of things it doesn't matter, but for some it can be very difficult to change later on, especially if you need to maintain backwards compatibility.