Agile fail #1Cynical basis of agile: estimation is intractableAvoid estimation by working in short sprints- surely we can estimate the next twoweeks, right?Right?
Sprint fail #1: rolloverWe will build these ﬁve thingies/bugs/storiesin the next two week sprintTwo are more complex than anticipatedOne is blockedShip two, roll the other three overRinse, repeat
Sprint fail #2: Mara-sprintWe can’t get these ﬁve things done. Shouldwe ship with only two?If we just push the deadline out a week,everything will be ﬁne.And then another.And then another.
Sprint fail #3: Death sprintsWe HAVE to get these ﬁve things doneThe deadline is an immovable objectWe’ll just work really really late or all nightevery night for the next two weeksAnd then the same thing again....andagain...and again
Things I’ve learnedPlan the dimension of ﬂex and choose: Less functionality in the same time Flexible timelines or slower velocity Continuous deployment Train model
Coding fail #1:Build a new bikeshedSitting down to code when you don’t knowwhat you’re doing vsAnalysis paralysis/bikeshedding: getting stucktalking through a complex problem, over andover
Coding fail #2: One True RingThere’s one right way to solve this problemComplexGoing to take a long timeScope keeps expanding
Coding fail #3: Over-engineeringClosely related to the One True RingBeautiful class hierarchy and architectureLovely diagramsIt doesn’t do anything
Things I’ve learnedDifferent people work in different ways.Some people deal better with uncertainty.Those people should build a prototype.Do The Simplest Thing That Could PossiblyWorkBe happy with 60-80% solutions. Iterate.Even if you’re not a startup, Minimum ViableProduct is valid.
Deployment fail #1: Version chaosPush master/trunk/head.Have no other branches.Have no tags.Have things that aren’t under versioncontrol.
Deployment fail #2:Fail forward, fail backHave no rollback plan.Have no ability to fail forward, either.If failing forward fails, have no backup plan.
Deployment fail #3: Manual pushesRelease by manually logging into eachmachine and updating a checkout.This is even better under high load.Scaling is something best not talked about.
Deployment fail #4:ALTER TABLE ADD FAILRequire manual changes to databases. Haveno record of the changes in version control.Don’t estimate how long these changes willtake, how much they will degradeperformance, or how much downtime will berequired before kicking them off.
Deployment fail #5: Conﬁg of DoomRequire manual changes to conﬁguration,especially if there are more than twomachines involved - 30 or more is especiallygood.
Deployment fail #6:Single Person Of FailHave only one person that knows how todeploy your stuff.(Don’t document any of it.)
Deployment fail #7: It Worked In StagingStaging not the same as prod:Different OS, packages, hardwareOnly one of something where there are >1in prod (classic examples: db replication,memcache)
Things I’ve learnedHave a release management systemBuild the capability to deploy continuouslyAutomate everything: build, test, deployUse conﬁguration managementDocument everythingLoad test when neededEliminate SPOFs, including peopleStaging should reﬂect production