• Beneficial change results from cycles of learning, doing and self-reflection.
• Success derives from delivering small things of value regularly and often.
• A discreet piece of work is either done or it is not done.
• Better to risk a bad decision than make no decision at all.
• The wisest decision is made just before it can be most efficiently acted upon and no earlier.
• Most features will receive little or no use. 60% of what you want is better than 100%.
• Plans document one scenario that will not happen and describe some other application than the one that was built.
• On time and on budget are not synonyms for success.
• In human endeavor, every enlightening truth contains a lie. The road to hell is paved with…

Editor John Solomon told Greg Sargent technology, not a person, was to blame.

“The theme engine, through automation, grabbed a photo it thought was relevant, and attached it to the story,” Solomon said, acknowledging that the photo had gone up without a person seeing it. “There was no editorial decision to run it. As soon as it was brought to our attention, we pulled it down.”

“There was no editorial decision to run it”??

Who decided to acquire/build a search algorithm to publish file photos without human oversight?

The example is outrageous but using loose tags to associate photos of people to stories of crime and human tragedy? Under what circumstances does this technical solution make journalistic sense?

Technology to blame? Not even the technologists. Doesn’t this newspaper have an editorial board?

How about applying the same standard of care to your online property that you’d use for print?

Mistakes happen but blaming your tools just betrays how unequipped you are to use them.

In it, they list ten mistakes most likely to produce catastrophic or serious consequences.

Half of them speak more to executive and product management than development:

• #1 unrealistic expectations
• #2 weak personnel
• #4 wishful thinking
• #7 lack of sponsorship
• #10 lack of user involvement

Given my experience of organizations that means projects are marked for failure well before agile methods are even applied.

Under these circumstances, we can hope frequent delivery will either morph the project into something more valuable or cause it to die a quick and merciful death.

A better answer disperses transparency, collaboration and continuous improvement from the team room out to sponsors, stakeholders, support units, suppliers, customers and end users — from development and project management to economies.

“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.