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

Short link: http://jkat.me/eL1xMw

Tag(s): agile, failure, product owner, quality, risk, scrum

Comments: none

Construx has a white paper revisiting Stephen McConnell’s Software Development’s Classic Mistakes.

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.

Short link: http://jkat.me/hCeggh

Tag(s): agile, Construx, failure, management, mistakes, product management, product ownership, scrum, Stephen McConnell

Comments: none

From Huffington Post, Washington Times Runs Obama Girls’ Photo With Story About Murdered Chicago Kids

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.

Short link: http://jkat.me/hf8Su6

Tag(s): editor, ethics, failure, Greg Sargent technology, John Solomon, Murdered Chicago Kids, online property, search algorithm, technology, Washington Times

Comments: none

http://www.flickr.com/photos/luc_viatour/ / CC BY-SA 2.0

• 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…

Short link: http://jkat.me/hd3Zky

Tag(s): aphorisms, failure, good work, process

Comments: none

At Agile NYC I presented a pecha kucha. 20 slides. 20 seconds per slide. This is the second of four parts.

I want to live in our imperfect reality

As agile becomes popular it becomes a buzzword. It gets promoted as a tool that solves problems when at its heart it is a set of values that encourage you to confront problems.

We should all recognize these organizing principles…

• Collaboration over negotiation
• Working software over specification
• People over process
• Responding to change over following a plan

In addition, Bob Martin’s “Quality over crap”

Let’s talk about following a plan… worshipping a plan

I think of this every time I think of worshipping a plan…

A driver put her faith in her satellite navigation system. It told her to turn onto a bridge. Problem was the bridge had been washed away. She drove her $160,000 Mercedes into the flood where it was swept away. She had to be rescued as it sank.

Where the customer doesn’t entirely know what will succeed… Where they aren’t entirely steeped in the technology…

Specifications become a black hole so dense with detail that even light cannot escape.

Project schedules become the most boring fairy tails ever told.

Mocks mock us.

And process gates (“handoffs”) kill collaboration.

We put a lot of energy into delivering the wrong thing on time and on budget.

And we don’t even recognize or care about that thing by the time it goes live – if it ever does.

I want to live in our imperfect reality.

…Focus on what I did, what I’m doing and what I want to do next.

I want to know what we are trying to achieve and converse with people I’m achieving it with.

I accept failure if we call it out as we recognize it, applaud the attempt and make changes so that we don’t repeat that exact failure again.

In short, I love an iterative, reflective way of working because I dearly want to spend each day doing a little less crap and a little more not crap than the day before.

Short link: http://jkat.me/erTJVR

Tag(s): agile, AgileNYC, failure, pecha kucha, process, values

Comments: 1