If you built a river bridge with Scrum:
The roadway would be built first, because that’s the Product Owner’s highest priority. Unfortunately, it would sink to the bottom of the river once deployed. This experience would be called “learning from failure.”
Realizing they needed to get above the waterline using some supports, the team would build a short set of pillars on top of the sunken roadway. The pillars wouldn’t reach above the waterline, but they would be valuable for the experience in building support pillars for this particular river.
Once the first set of pillars had been sunk, the team would use their new knowledge to build a second set of pillars that just breached the waterline, and construct a second roadway on top of that. This would make the Product Owner very happy, because “customers could use it” for the first time.
After the first week, they’d realize they’d built a leaky dam, not a bridge, and that all boat traffic was being blocked.
Working seven days a week, 14 hours a day, the team would scramble to fix the bridge. They’d cut channels in the roadway to let some boat traffic through, then build a third set of supports and a third roadway at the proper height.
Burnt out and frazzled, the team would begin pointing fingers, each specialty blaming the other for the death march at the end. Half would quit, and join a different company, building high rises. The other half would struggle to support the many bugs still left in the bridge, despite not having any experience with the things built by the members who’d left (what was the special concrete mix Nancy used?).
Meanwhile, the Product Owner would be praised for pulling off a miracle, and be put in charge of another bridge-building project.
Three years later, the whole thing would be bulldozed to make room for a ferry.
