[clairity]

it's subtle, but "plan" (material resource planning, MRP) is essentially waterfall in this context, where you design first, then do work breakdown into a waterfall schedule. it suffers from cascading delays because of the bullwhip effect (among other things). it's project oriented (a 1-off, 1-time event).

in contrast, "workflow" is akin to kanban in this context. you start with constraints (in this case time and money) and then design the system to those constraints. mary, the speaker, mentions that they had 4 different, decoupled workflows, which helped them avoid those pesky cascading delays. workflows are process oriented (repeatable events), so steel construction, for example, was thought of as an separate repeatable (if varying) process (swimlanes, in kanban parlance) as they went up in height. kanban also focuses on realtime learning and adjustments as well as just-in-time inventory systems (important to steel being delivered on time, like using 2 different suppliers to make sure there were no delays).

this is the stuff you learn in operations class in business school (or some engineering programs), as did chris (the author of the article/blog), who went to ucla anderson.

[aidenn0]

Lack of a plan is what results in bullwhip effect; the bullwhip effect is caused by each silo iterating on its local knowledge...

> in contrast, "workflow" is akin to kanban in this context. you start with constraints (in this case time and money) and then design the system to those constraints. mary, the speaker, mentions that they had 4 different, decoupled workflows, which helped them avoid those pesky cascading delays. workflows are process oriented (repeatable events), so steel construction, for example, was thought of as an separate repeatable (if varying) process (swimlanes, in kanban parlance) as they went up in height. kanban also focuses on realtime learning and adjustments as well as just-in-time inventory systems (important to steel being delivered on time, like using 2 different suppliers to make sure there were no delays).

That sounds like a plan to me...

[clairity]

no, the bullwhip effect is caused by uncertainty across coupled tasks along the critical path, no matter the level of detail of your plan. it's a statistical phenomenon that you can mitigate with other measures, like critical chain. the empire state building example shows that they reduced coupling by creating 4 separate, independent workflows, mitigating the bullwhip effect by roughly a factor of 4.

[aidenn0]

Yes, the bullwhip effect is caused by uncertainty across coupled tasks. A plan that doesn't reduce and manage uncertainty is bad. Not having a plan means there is uncertainty even when all of the information is there to determine the answer. The empire state building had a plan for obtaining steel from foundries at the velocity they needed.

If one defines plan to mean "We schedule everything up front and then stick our fingers in our ears and say 'la la la la' when reality conflicts with our imagined schedule" then of course plans are bad. Similarly if one were to define agile as "a system that is incapable of delivering any feature that takes more than 2-4 weeks to develop" then agile would be bad too.

[clairity]

yes, another restatement of the distinction between 'plan' and 'workflow' as used in the talk.

[peteradio]

I think what trips me up then is that "Plan" refers to a specific type of planning, I guess "MRP", but colloquially it would refer to anything that attempts to project how something will be done. Unfortunately I've had employers insist that planning in the colloquial sense was akin to waterfall and since we were agile it was verboten.

[projektfu]

Obviously there were blueprints and solid estimates of the materials and labor required to build the thing. This was no Gaudí cathedral. But there was nothing telling someone when things would be at which stage of construction, just the knowledge that some parts needed to get done in the summer and the whole thing needed to be ready for occupancy on May 1.

I think the story of the submarine/Polaris missile was more interesting. They produced the plan and basically ignored it, and the PERT planning exercise has subsequently been cargo-culted for years.

[clairity]

yah, plan is an overloaded word, like most words. here it seems to boil down to the old adage of "good, fast, cheap. choose two."[0] if you set scope and budget (the "plan" version), then you have to be flexible on deadline. if you set deadline and budget (the "workflow" version), you have to be flexible on scope. for the empire state building, they designed the building (controlled scope) to fit the budget and deadline.

whether it's waterfall or agile shouldn't really matter. in agile, there is planning, but often it's workflow based (tracking flow via story points, or what not).

[0]: https://wikipedia.org/wiki/Project_management_triangle