Fail fast

Panic Button by aperte on flickrFail fast is a technique for improving the quality of software:

“failing immediately and visibly” sounds like it would make your software more fragile, but it actually makes it more robust. Bugs are easier to find and fix, so fewer go into production. — Jim Shore

Scrum aspires to a fail fast approach to building software.

It describes practices that surface problems:

  • a backlog prioritized by the product owner and estimated by the team (accountability)
  • short iterations
  • frequent retrospection
  • a role dedicated to removing impediments

It champions values that motivate individuals to address problems:

  • delivering business value
  • collaborating with customers
  • empowering teams
  • building quality in
  • continuous improvement
  • courage and honesty (a refusal to hide risk)

Possessing these values and practices, an organization is less likely to overlook or tolerate dysfunction when it materially affects the setting and achieving of project goals.

  1. risks are identified before they become problems
  2. simple problems are detected and resolved quickly
  3. thorny problems are mitigated
  4. catastrophic problems are aired to all concerned parties (informed consent)

Cases #1-3 increase a project’s chance of creating value.

Case #4 compels an organization to cancel a doomed project.

All four cases represent a better outcome for the business. Assuming that business offers value to the world, that’s better for our end users, our reputation, and our society.

Immediate and visible failure. Much preferable to hidden, prolonged and inevitable failure.

This entry was posted in scrum and tagged , , , , , by Ken Judy. Bookmark the permalink.

About Ken Judy

I am an executive manager, software developer, father and husband trying to do more good than harm. I am an agile practitioner. I say this fully aware I say nothing. Sold as a tool to solve problems, agile is more a set of principles that encourage us to confront problems. Broad adoption of the jargon has not resulted in wide embrace of these principles. I strive to create material and human good by respecting co-workers, telling truth to employers, improving my skills, and caring for the people affected by the software I help build.