The Love Song of J. Alfred Prufrock

And now for something completely different...

Via Sean Doyle, who's wife, convinced him at age 39 to just pursue training in positive psychology rather than pursue a sports car or a younger woman...

I don't find myself encountering poetry that much in my day to day. This T.S. Eliot guy seems to be very good at it:

LET us go then, you and I,
When the evening is spread out against the sky
Like a patient etherised upon a table;
Let us go, through certain half-deserted streets,
The muttering retreats
Of restless nights in one-night cheap hotels
And sawdust restaurants with oyster-shells:
Streets that follow like a tedious argument
Of insidious intent
To lead you to an overwhelming question ...
Oh, do not ask, “What is it?”
Let us go and make our visit.

...

Read the rest of the poem here.

Girl Geek Dinner Sydney Two at Google

Google Australia is hosting Girl Geek Dinner Sydney Two. Lindsay Ratcliffe will be speaking about User Experience and Stephanie Hannon will be speaking about Google Maps related things. Apparently Rob Pike was invited by a geek girl so he'll be there too.

This time I'm pretty sure I can't sneak in as co-founder so I really do need a geek girl date... Anyone?

Register here.

Remember to check the box that says "I would like to bring a guest" and tell me where we should meet. :)

Ivory Tower Software Development

A rather old blog entry by Jeff Atwood which doesn't really say anything new to people in the Agile community but it's a nice summary and worth reading:

In my experience, the more isolated the developers, the worse the resulting end product. It doesn't help that most teams have a layer of business analysts who feel it is their job to shield developers from users, and vice-versa. It's dangerous to create an environment where developers have no idea who the users are:

Noticed as a reference in an InfoQ article.

Kent Beck learning from Lean

I just encountered a nice essay by Kent Beck on his thoughts on what we can learn from Lean:

So here is a single principle, eliminating waste, that brings different insights to software development depending on the metaphor. If software development is lean manufacturing, software development should aim to produce decisions at the same rate as it consumes them. If software development is lean product development, software development should strive to retain and disseminate learning. Both lessons can positively influence software development.

It's an interesting essay but I wouldn't consider the single principle to be eliminating waste. I prefer to see the fundamental principles as respecting people and continuously improving. Everything else comes from that.

Deriving a Lean Software Development House in pictures

[Click on the house image to get a larger version]



[Updated: Added Right Philosophy to the foundation]

It's never about the money; it's always about being able to help

Even quite intelligent people aren't necessarily familiar with the research nor have the insight to understand the fallacy of more money = more happiness (after a certain level of money).

So it's worth pointing to an NPR article writing about a new study in Science:

The researchers first asked a group of college students how happy they were. They then gave the participants money — either $5 or $20. Half were told to spend the money on themselves. The others were told to spend it on others, such as giving a gift to a friend or making a charitable donation. That evening, the researchers again asked the students to gauge their happiness.

It turns out that the participants who spent money on others reported a much greater happiness boost than the ones who spent money on themselves. And, surprisingly, the amount of money the students were given didn't seem to matter at all. It was how they choose to spend it that determined their happiness levels.

Here's the kicker...

... but another study suggests we're not very good at assessing human nature. Dunn and her colleagues asked a group of college students what they thought would make them happier: spending money on themselves or on others. The vast majority of respondents said: spending money on themselves.

Apparently, there is large chasm between what we think will make us happy and what actually does.

via Good News Network.

Use A4 sized story cards on your story wall

A while back we started using A4 sized story cards (aka printed on a piece of paper) rather than index cards on our story wall

This dramatically improves the visibility. We can read the identifiers from halfway across the room. Because we have some overlapping, we're using coloured post-its to differentiate stories associated with different iterations. This helps us visually determine whether work is flowing at the right pace or whether we have current or upcoming problems. "Analog zoom" is required to read further details such as titles and estimates.

Key points that you might otherwise miss:

• Clear owners for each process step including explicit entry criteria. This is close but could be better for us.
  
• Use blu-tack on each corner of the A4 paper. Otherwise, the corners curl in and obscures the story card.
  

Things that we're missing that might be useful:

• Current iteration indicator. You'd be surprised how often someone doesn't remember.
• Visual avatars to indicate at a glance who is working on what. I'm still keen to try avatars that also indicate emotional state to make problems visible but I still haven't had the opportunity.
  

Do you just develop software? Or do you also develop people?

Via Evidence Soup,

Allan Alter at CIO Insight writes about how the real cause behind IT skills shortages is because many companies don't keep people for the long term nor are truly interested in doing so:

There’s a three-part solution to the skill shortage: One, no matter how the economy affects your firm, increase training for employees. Two, when recruiting from outside your company, be willing to interview capable IT professionals, even if their skills aren’t a perfect match for the job. Three, be willing to provide new hires with technical training.

So I wonder...

If you're having a retention problem, perhaps the first question is to ask whether you develop your people? And this doesn't just mean new hires.

If you're having a recruitment problem, perhaps the first question is to ask what you're actually looking for? Are you looking for foundational skills that will be developed? Or do you recognise, openly or not, that there will be no real opportunities for development and hire for specific skills?

The frustration of dealing with chicken thinkers

Shigeo Shingo described an experiment conducted on a chimpanzee, a dog, a chicken, and a human child.

Each subject is placed in a cage and every day the food is placed in the same location in front of iron bars such that it can be reached. This is repeated until the procedure becomes expected.

Next the food is moved just out of reach and the back door of the cage is opened.

The result?

The dog takes the least amount of time, possibly due to an enhanced sense of smell, followed by the human, and then the chimp. The chicken however, never overcomes trying to get to the food through the iron bars.

...

So how about we stop banging our chicken heads against the bars and take a look around for an open back door?

Favourite bits from Kaizen and The Art of Creative Thinking

Recently read the English translation of Kaizen and The Art of Creative Thinking by Shigeo Shingo. My favourite bits:

There were cases where quality control achievement was measured by the number of statistical charts created. Instead of addressing defects as they happened, people preferred to wait a month and discuss them in meetings using these charts. This not only made tracking down the causes of problems more difficult, it also created a distance between shop floor workers and management.

...

Depending on which type of judgment we make, the ensuing action and outcome will differ greatly. Those who think, "We can't do it," will likely take no further action. In contrast, those who think, "It'll work if this problem can be solved," will likely act further to find a better method. Naturally, those who make the latter judgment will afford themselves more chances for success.

...

You're employing what I call the 'engineer's instinct.' This instinct tells you if something doesn't yield a perfect result, it is a failure. A better instinct would be one that tells you the idea is fine as long as it yields some profit, even if the test results show only 60 percent success. I call it the 'manager's instinct.' If this were a research laboratory the story might be different; but at a working factory, it's ok to go forward with an idea even it is not perfect. A better-than-nothing mentality is what we need here, not an all-or-nothing mentality."

Having an engineering degree, I would actually replace "engineer" with "scientist" and "manager" with "engineer" but I share the general sentiment anyway. Some times you just kick the door in and figure out how to pick the lock later.

Stop motion paper prototyping

Via The Interaction Designer's Coffee Break,

Apparently a video of an iPhone crayon and paper prototype:



Given that it's in Portuguese, I'm not sure if this was done after the fact as an example or whether it was actually an example of Apple using this technique.

In any case, I normally think of paper prototyping as a tool for user testing but this kind of stop motion animation paper prototyping seems to be quite an effective (though perhaps a time consuming) way to communicate product vision, explain concepts, or create shows for Comedy Central.

Lean is about people, not about waste

Dan Markovitz blogs about Bob Chapman at the Lean Transformation Summit and is another nice example of why I identify with the Lean community even though I'm not a manufacturing person:

Everyone at these conferences focus on tools like value stream mapping and 5S. But the tools are only 25% of the story. Lean is about people, not about waste. Focus on the employees -- all other benefits are just by-products.

Revenue numbers kind of miss the point

Looking at Multiplayer Economics at Fast Company...

Typical cost of developing a high-end MMORPG: $40 million
Percentage of such games that don't recover costs (aka not profitable): 95%

Does it really matter what the revenue numbers are?

What's even more amusing (in a sad way) is that a game is considered "successful" based on number of subscribers.

Is the waste in motion or in energy expenditure?

While learning about Standard Work at the recent Lean Summit in Melbourne, I noticed that the level of analysis that Toyota does to understand movements reminds me a lot of studying martial arts.

Which makes me wonder whether the analysis of waste is not so much about minimising Motion as it is about minimising energy expenditure.

Questions on influence and growth

I recently attended some visioning sessions. For the first one I was more active. For the second, I focused more on listening and thinking of questions that would trigger thinking.

----
If you don't have control, does it mean you can't influence?

Is control required for influence?

Does control increase or decrease influence?

What does growth mean?

Does dealing with greater complexity always imply growth? When does it? When does it not?

How do you know that you're getting better? Is that always something that someone else needs to tell you?

How do you establish reputation assuming you start with none?

When a decision is made, even if it's the "right" one, how was the decision made? Who made the decision?

What do you want to influence? What tools and techniques are used? How the project is run? How all projects are run (i.e. the production system)? How the product/solution is designed? How all products/solutions are designed (i.e., the product design system)? How problems are selected to solve? How problem spaces are selected?

Employees first, customers second, shareholders as a consequence

Mary Poppendieck posted this to the leandevelopment Yahoo Group late last year (reproduced with permission):

Think if it this way:

Once there was what was called Theory X Management – a Taylorist view of work that claimed that workers want to do as little as possible and they don’t care about quality. Then we moved to Theory Z management – which is well articulated in Kaoru Ishikawa’s 1981 book “What is Total Quality Control? The Japanese Way” (which I am just now reading). He says that people are fundamentally good and want to do a good job. A lot of good has come from companies operating on this basic assumption – that people are fundamentally good and want to do a good job.

Well, managers are people too, you know. So I propose that the starting assumption should be that managers are fundamentally good people who want to do a good job. If they do not, there is probably a system in place which does not allow them to do a good job – a system reinforced by measurements no doubt.

Ishikawa writes that the first job of managers is to create a workplace where workers enjoy their jobs and develop to their full potential. The second job is to look after customers. If this happens, then the profits that investors need will follow, but it does not work the other way around. Profits do not ensure satisfied customers or employees working at their full potential. When you get it backward, the business is not sustainable in the long run. So first and foremost, managers must delegate decisions to workers within the framework of quality standards, and make sure the workers enjoy their work, are proud of it, and are developing their full potential.

So I like that view of management. I have seen it work quite well – better than self-organizing teams, actually. Not that teams don’t self-organize, but they do it in a context of management that is committed to workers first, customers second, and shareholders as a consequence of the first two commitments.

There are PLENTY of companies out there that have good managers – generally they are the leaders in their markets and have sustainable business models. Companies with bad management won’t be able to compete in the long run. So I would rather spend my time focusing on what it means for managers to do a good job (because I assume that they WANT to do a good job), rather than trying to put a fence around bad management.

Watij vs Selenium RC

I recently created a set of smoke tests with which I didn't have to care about cross browser.

After some frustrations trying to get Selenium RC to work, I decided to try using Watij (would have used Watir but Ruby was borked on that machine).

Wow. Watij is a lot easier to get working. Not nearly the same number of finicky issues to debug and the API is superior by far.

I blogged over a year ago about how the whole proxy server thing with Selenium RC was problematic. Now I see it as a fundamental disadvantage to how easy the tool is for users.

Selenium still has the advantage due to the cross browser capabilities but if the COM driver tools can get their cross browser act together, or at least IE and Firefox...

"And while the group specifically focuses on women...

... it was a man who initially got the Girl Geek Dinner ball rolling."

Kind of wierd seeing my name show up in an article.

Somewhat misleading since Sarah got the Girl Geek Dinner ball rolling while I just happened to pass it on to Damana, who honestly handled most of the organising.

The next Girl Geek Dinner in Sydney will be a picnic in the Royal Botanic Gardens on Sunday, a day after International Women's Day.

Never know what to bring to picnics...