Martyn Newman - Why happiness is good for business
Do relationships lead to happiness or are happy people more likely to be in a relationship?
"The constraint isn't money, it's people." Rex Tilerson, Exxon Mobil
"To be independent of public opinion is the first formal condition of achieving anything great or rational." Friedrich Hegel
Self-confidence comes from self-liking + self-competence.
Felicia Huppert - Defining, measuring, and promoting flourishing in the population
Beyond Money: Toward an Economy of Well-Being by Ed Diener and Martin E.P. Seligman
Core features of flourishing (i.e., the opposite of depression): positive emotion; engagement, interest; meaning, purpose; positive relationships; and 3 of either confidence, optimism, resilience, vitality, or self-determination.
5 ways to well-being:

• Connect...
• Be active...
• Take notice...
• Keep learning...
• Give...

Andrew Carnegie - Positive steps for managing workplace conflict - A manager training program
If you see a machine blowing blue smoke, you fix it. But when you see the equivalent with people, you're more likely to do nothing.
Happiness at Work Index (what matters most in order of importance)

1. Friendly and supportive colleagues
2. Enjoyable work
3. Good boss / line manager
4. Good work / life balance
5. Varied work
6. Belief that we're doing something worthwhile
7. Feeling that what we do makes a difference
8. Being part of a successful team
9. Recognition for our achievements
10. Competitive salary

I attended the 2nd Australian Positive Psychology and Well-being conference in Melbourne on 12 - 13 February. Here are my notes for the first day.
Christopher Peterson and Nansook Park - Positive Psychology: An even-handed yet enthusiastic look at its past, present, and future
"Australians are like Canadians with humour." (Chris Peterson)
"Never say further research is needed unless you can say what that further research is." (Chris Peterson)
The value of Positive Psychology is about "breaking through the zero point".
It is not about focusing only on strengths and ignoring weaknesses but rather harnessing strengths and assets to solve problems and enhance well-being.
The pillars of positive psychology:

• Experiences <- Current research emphasises this too much
• Traits
• Relationships
• Institutions

"Critical thinking is important but you need to know what to be critical about." (Chris Peterson)
Two factor analysis of the VIA strengths Mind vs Heart and Focus on Self vs Focus on Others:

Parents with the strength of self-regulation are the strongest predictor of happy children.
Barrack Obama explicitly mentioned 23 out of the 24 character strengths in his inauguration speech. The missing one? Humour.
It's important to look beyond the happiness, health, and success of "I".
"Love is never having to say you're sorry. Science is having to always say you're sorry." (Chris Peterson)
Abraham Maslow bemoaned the fact that humanistic psychology became a "safety science", concerned only with celebrating itself, and no longer a "growth science", constantly challenging itself in order to improve. We should be vigilant to ensure the same thing does not happen to positive psychology.
Craig Hassed - Mindfulness - the multi-faceted diamond
"Any man who can drive safely while kissing a pretty girl is probably not giving the kiss the attention it deserves." (Albert Einstein)
Mindfulness is NOT distracting ourselves or tuning out, but rather tuning in.

My favourite bits from Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior by the Principals of the Atlantic Systems Guild:
"Dashboards don't improve leadership, they reveal it."
"Managing is getting paid for home runs someone else hits." (Casey Stengel)
"Orville Wright didn't have a pilot's license." (Richard Tait)
"The correct amount of anarchy on a project is not zero." (Mike Mushet)
"Suppressing bad news can turn solvable problems into unsolvable ones."

My favourite bits from What Is Total Quality Control?: The Japanese Way by Kaoru Ishikawa:
"Quality control begins with education and ends with education."
"Narrowly interpreted, quality means quality of product. Broadly interpreted, quality means quality of work, quality of service, quality of information, quality of process, quality of division, quality of people, including workers, engineers, managers, and executives, quality of system, quality of company, quality of objectives, etc. To control quality in it's every manifestation is our basic approach."
"There can be no quality control which ignores price, profit, and cost control."
"If standards and regulations are not revised in six months, it is proof that no one is seriously using them."
"Standards and regulations are always inadequate. Even if they are strictly followed, defects and flaws will appear. It is experience and skill that make up for inadequacies in standards and regulations."
"If the people do not feel happy and cannot be made to feel happy, that company does not deserve to exist."
"Companies exist in society for the purpose of satisfying people in that society. This is the reason for their existence and should be their primary goal."
"Profit first is an old-fashioned idea that must be discarded."
"The customer is king, but the king may be blind."
6 categories of quality control transformation:

1. Quality first. Long-term profits over short-term profits.
2. Consumer orientation over producer orientation. Think from the standpoint of the other party.
3. The next process is your customer. Break down silos.
4. Use facts and data to make presentations.
5. "Respect for humanity" as a management philosophy. Full participatory management.
6. Cross-function management.

My favourite bits from Freedom from Command & Control: Rethinking Management for Lean Service by John Seddon.
My interpretation of the essence of the book is that effective leaders provide knowledge, not directives.
"The value of knowledge is it's use, not it's collection."
"Without theory, experience has no meaning. Without theory, one has no questions to ask. Hence, without theory, there is no learning." W. E. Deming

"Who are you? What do you do? Why does it matter?" Greg Galle
I also like the section with a series of questions to ask before you conclude that it's a "people problem" but that's too long to include here.

A collection of my favourite bits from Leading Lean Software Development: Results Are not the Point:"It is the overhead incurred to enable auditability that induces the waste, not the standards themselves."
"Randomly giving patients medication until they get better would not even be considered. And yet, we randomly give our work processes medicine, adding on more and more 'best practices,' until the processes seem to get better."
"A jishuken is a training exercise, not a problem solving exercise."
"Which would you rather have, headcount constraints or big layoffs?"
"The advantage which a commander thinks he can attain through continued personal intervention is largely illusory. By engaging in it he assumes a task that really belongs to others, whose effectiveness he thus destroys. He also multiplies his own tasks to a point where he can longer fulfill the whole of them." (Helmuth Von Moltke)
"When opinions are asked, the tradition in the military is to let the junior person (rank in this case) speak first." (Tom Stephen)
"A budget will either prove roughly right, and then it will be trite, or it will be disastrously wrong, in which it will be dangerous. My conclusion is thus: Scrap it!" (Jan Wallander)
"Management that is destructively critical when mistakes are made kills initiative." (William McKnight)

Kerry Patterson tells an interesting story about root cause analysis in the May 2009 Crucial Skills newsletter:
Instead of a system wide program for improving the overall customer experience, the manager had instituted a program for improving Kerry Patterson’s customer experience. He essentially created “Mr. Patterson’s Customer-Service Program."

Tim Bray recently posted on his observation that the enterprise approach to building software systems is performing much worse when compared to the Web community:
Here’s a thought experiment: Suppose you asked one of the blue-suit solution providers to quote you on building Ravelry or Twitter or Basecamp. What would the costs be like? And how much confidence would you have in a good result? Consider the same questions for a new mobile-network billing system.

The April 2009 Crucial Skills newsletter talks about 5 warnings signs of project failure which I find quite familiar:
1. Fact-Free Planning — Commitments to deadlines and limits on resources are made with little consideration for the real demands of the project.
2. AWOL Sponsors — The executive sponsor of a project is not leading as he or she should. He or she is not showing up for meetings, holding people accountable, or walking the talk.
3. Skirting — Powerful leaders bypass agreed upon decision-making processes or quality gates in ways that are allowing scope creep or putting commitments at risk.
4. Project Chicken — Critical aspects of the project are going over schedule or running over budget and it’s not politically popular to admit it. Instead, people play “chicken”—letting things get closer to the deadline without acknowledging problems.
5. Team Failures — Key members of the project team are not competent or do not follow through on their commitments.

Despite how many times it said, when the Agile Manifesto says X over Y, people will always assume that X is important and Y is not.

I suggested recently that one of the ways to really detect what is valued is to look at what is dealt with first. In other words, values are detected when you observe X before Y.

Let's try this:

Individual and interactions before processes and tools. Look at people, capabilities, communication channels and required knowledge sharing before designing sequences of activities and selection of tools.

Working software before comprehensive documentation. Build and concretely verify the functioning of the software before describing what it does in documents. In other words, prefer as-built specifications.

Customer collaboration before contract negotiation. Work with and negotiate with people before capturing and supporting this with contracts. You never really negotiate with contracts; you always negotiate with people.

Responding to change before following a plan. When events occur, respond appropriately and adjust a potentially obsolete plan before continuing to follow it.

----
For another take, see also a simplified version of the Agile Manifesto that I wrote a few years ago.

In Becoming Lean: Inside Stories of U.S. Manufacturers, Mike Rother developed a model of Levels of Understanding based on what he believed he heard from a visit to the Toyota Supplier Support Centre. From "learning from theory" to "learning from practice" (slightly modified for more general applicability):

1. Awareness of concepts - "This is what it is"
2. Awareness of successful application elsewhere - "It seems to work there"
3. Awareness of how it can apply here - "I can see what it might look like here"
4. Commitment to action - "We will try it here in a controlled way"
5. Belief through experienced success - "I've seen it work in a limited context with great success"
6. Further action - "Let's try more in other contexts"
7. Deeper understanding and belief - "I can see how it works as a system and what the possibilities are. I can't go back."

This seems like a reasonable model though I'm interested in alternatives to see how they compare.

Just finished reading Becoming Lean: Inside Stories of U.S. Manufacturers. The best parts for me were John Shook describing his experiences bringing TPS to the US and the last couple chapters summarising the lessons of "becoming lean".

Mike Rother describes a few pitfalls that I think are also relevant for those of us introducing Agile / Lean to software organisations:

1. Confusing Techniques with Lean Objectives, which you may sometimes hear described as being a "tool head".
2. Expecting Employee Training to Make Lean Manufacturing Happen, which leads to a perhaps controversial suggestion that change driven solely from the bottom by self-directed work teams is "all pure bunk".
3. That's Not Lean Manufacturing, That's a Program, which is an over-emphasis on charts and diagrams before and rather than implementation. "If we find ourselves in endless discussions about whether something like standardized work comes under the heading of quality or JIT in the diagram of our company's lean manufacturing model, we should stop and ask: 'Where have we implemented this?'"
4. Relying Solely on Kaizen Workshops, in other words, isolated improvement projects rather than continuous improvement toward a common future state vision.
5. Quitting After Failures, which is responding to failure with "That doesn't work here" rather than "How can we make this work?"
   

Your organisation's values is learned by observing what people actually do, the things they talk about first in meetings, the things they spend the most time on... not their published value statements or what the leaders might spout during public presentations.

Pat Kua recently blogged about similar things.

Via the Limited WIP Society blog,

Keith Swenson provides a nice summary of how Taiichi Ohno's "Toyota Production System: Beyond Large Scale Production" provides lessons to the context of software development.