srsly: good post nice to see the “K-man” mentioned, too. Two other quotes from him that I think are appropriate to your topic:

“If words are not things, or maps are not the actual territory, then, obviously, the only possible link between the objective world and the linguistic world is found in structure, and structure alone.”

and one of my favs:
“There are two ways to slice easily thorugh life; to believe everything or to doubt everything. Both ways save us from thinking.”

mamund

I am reminded of the observation that there is a reason that “work to rule” is a labor action against management.

Kudos on bringing up General Semantics. I am often amazed when system builders are not interesting in being careful in their own language. What is programming about if it isn’t being precise in our meanings?

I wonder if it might be more trenchant to say “all process is at best an attempt to help.” I was watching Dan North’s Fallacy of Efficency talk recently on Vimeo from OreDev. He has a quote that he attributes to Virginia Satir – “Everyone is trying to help.” That certainly resonates for me.

I totally agree on need for failure. I’m listening to the audio version of Syed’s Bounce and he talks a lot about deliberate practice, which entails a lot of deliberate failure.

I think one of the challenges with this approach is that in organizations, there is not always a sufficiently shared sense of what constitutes a little non-destructive explosion.

Best,
Don

Cheers,

Ruben

I don’t know much, but the processes that I’ve designed that seem to work don’t focus on steps. They focus on goals. They break down “success” into a series of attainable goals. This seems to resonate. And it has significantly improved our business.

- Bob @FlowchainSensei

We want to avoid Cargo Cult mentality and replace it by understanding and appreciation of the organization culture. The organization will then evolve to figure out the appropriate practices.

Hope I got it right Jim.

Thanks

There’s a constant need for root cause analysis so that weaknesses can be identified and strengthened. Alas, technical debt will always exist. The key is to prevent it from growing too large. Your suggested approach is a terrific idea. Thanks!

Finding defects in the wild or missed requirements, especially late in a project cycle, often lead to responses that are akin to hero behavior in that they often bypass regular process and procedure just to get the darn thing fixed or shoehorned into the product. I’ve often said to our team “It happened. That sucks. Thanks for doing whatever you had to to fix the situation. But now let’s find out why we screwed up so that we can prevent it from happening again.”

Rearranging the lanes is very high on the priority list for the next release.

Did you get an API code from Agile Zen for the import?

Jim