No money, no mission

Mark Graban on why the phrase "doing Lean" is cringe-worthy:

Taiichi Ohno, one of the inventors of the Toyota Production System, always said "start from need." Great advice to this day. "... doing Lean" is something I almost hate to say, since "doing Lean" isn't the point. For Toyota, the point is to make money in the long-term and to serve their societal purpose. The same should be true for hospitals ("no money, no mission" as many would say).

Just replace "Lean" with "Agile" or any other bag of ideas and the message still holds. Pay attention to your situation instead of trying to impose some generic solution.

DHH on checklists

Checklists reminds me of when I was learning PSP and most recently from reading Lean health care blogs. Pretty cool that 37 Signals is using the idea:

We now have checklists in Backpack for confirming that a feature is complete, we have a checklist for preparing the feature for deployment and for executing the deployment, and finally for verifying that the feature is working as expected in the wild.

Checklists can be tedious but if they're effective, it's time for us to just deal with it and do it.

Just get rid of what you don't need and make the rest spotless

Given that he understands both Japanese and Lean, Jon Miller has a knack for clarifying the essence of what many Lean practices actually mean (or at least meant):

Last month when in Japan a retired Toyota executive advised our study mission group that companies starting out in lean should focus on the S1 and S3 only - just get rid of what you don't need and make the place spotless. Get the basics right, don't get fancy. Most of us can't do 5S properly but we never stop to say "then I'll just do 1S really well."

So the essence of 5S becomes something that even us in software development can apply:

Get rid of what you don't need and make the rest spotless.

Find Jason - Ignite Sydney photo slide show

Unfortunately there were audio difficulties with the video that was taken for Ignite Sydney so instead they created a photo slide show video.  See if you can spot me...


Ignite Sydney from Ignite Sydney on Vimeo.

Lost Generation by Jonathan Reed

Via Next Level - Digital Culture,

A reading of the poem Lost Generation by Jonathan Reed,

+1 for modern game play

Via the TED Blog,

Steven Johnson writes about the superiority of modern video games in terms of mental challenge over old-school classics like Battleship and Candy Land:

what sort of message does Candy Land send to our kids? (And I’m not just talking about all the implicit advertisements for cane sugar products.) It says you are powerless, that your destiny is entirely determined by the luck of the draw, that the only chance you have of winning the game lies in following the rules, and accepting the cards as they come. Who wants to grow up in that kind of universe?

Lean Software Development: On Radiators and Refrigerators

This is the presentation I gave at the first Ignite Sydney. 20 slides, 15 seconds per slide, transitioned automatically.

In hindsight, a better title would be "No Problem is a Problem: Lean Thinking for Managing Software Development"

Lean Software Development: On Radiators and Refrigerators

View more presentations or upload your own. (tags: lean agile)

A review and thoughts on Scrumban: And Other Essays on Kanban Systems for Lean Software Development

I read Corey Ladas' Scrumban book recently and I figured it's worth sharing my thoughts on it.

Summary:
I don't agree with everything Corey writes and sometimes with how he writes it but I appreciate the push away from romanticism to a more systematic, disciplined approach to studying our work. I'm not sure how easily all readers will be able to follow everything in the book though as it's really more a collection of essays.

Things I like:
The designation, "Agile Workflow Management".

Coffee barista examples. There are many examples in daily life of different strategies to executing workflow if one takes the time to pay attention.

The importance of limiting the number of kanbans in the system. However, I'm not sure this is explained sufficiently for people who haven't seen this in a real situation. A kanban in manufacturing is a physical token that gives permission to do work. Limiting the number of kanbans is intended to limit overproduction.

Lean thinking is generally far more concerned that the right work is being done at the right time than who is doing the work.

This is what John Shook describes as responsibility-focus over authority-focus.

The focus on the flow of a single item of work. Timeboxes are for sampling, reporting, whatever... but they shouldn't decide when work should be done.

“Hire the best” is an elitist and ultimately lazy management philosophy. ...the quality of the relationships between qualified players is usually more important than the individual performances

Focusing on the work items not the people. Focusing on people leads to the dysfunction of multi-tasking to increase utilisation and prematurely assigning work to ensure high utilisation.

Cumulative Flow Diagrams, though I learned of these through David Anderson from quite a while now.

it is never necessary to estimate the particular sizes of things in the backlog. It is only necessary to estimate the average size of things in the backlog.
Important detail though, items must be broken down enough that the variation is limited enough that we can use the average.

And what about prioritisation? Estimation provides cost. I'll take a Porsche if the price tag is the same as a Volkswagen.

I'd say that a "feature" may consist of multiple backlog items which you can simply add up for purposes of prioritisation. Perhaps it would be more accurate to say that "Any estimation that is beyond the precision required for prioritisation is waste".

Things I don't like:
I thought that the whole "Sprints & Scrum Masters" model was a cute example, probably useful for some simple problems, mostly useful as a simple explanation for novices.

This passage near the beginning of the book comes off as arrogant and implies that complex problems (and the people who deal with them) are fundamentally more important than simpler problems (and the people who deal with them). This does not demonstrate Respect for People. There are also way more simpler problems in the world than complex ones, with a few of those complex problems being simple problems with self-induced complexity.

Triggered thoughts:
The workflow for a high-unknown, design-heavy project is different than that of a more straight-forward project (e.g., framework-based). The former might eventually evolve into the latter. The Toyota Product Development System call the intial stage, kentou, which is a period in which multiple concepts and designs are explored. The classic Scrum Sprints, being inspired by Lean Product Development, is most appropriate here. Set a general goal, set a timeframe, let the team work it out.

These are the situations where teams are simultaneously exploring both the problem and solution space. If they want to do this quickly, they do it concurrently. See Set-Based Concurrent Engineering. Exploration has a non-consistent, poorly defined workflow which is why it looks and should look different.

I would expect projects to exist along the spectrum where either approach (i.e., pull system vs SBCE) is more appropriate and the project's position on the spectrum will likely change over time.

On specialists vs generalists vs generalising specialists vs specialising generalists

What does Toyota do? Poly-skill. Even if there are specific jobs, people are rotated through them. US plants do this more often than Japanese plants. This is related to the other force which is developing expertise and we all know that expertise is about hours. There tends to be more specialisation in design and engineering vs production simply because it takes more time to reach the standard.

Don't reduce the standard for acceptable work; cross-train and yes, work with strengths but don't ignore weaknesses. Manage what's in front of you. That's the Lean approach.

On pair programming being contrary to Lean
No particular practice can be contrary to Lean. It depends on why the practice is being done. To paraphrase Ward Cunningham, pair programming doesn't make sense if the constraint to programming was typing.

Why I prefer burn-up over burn-down

When talking about burn charts, I usually refer people to Alistair Cockburn's article on the subject.

The article mentions that some people prefer burn-downs over burn-up because it is more "emotionally powerful". It also shows a couple variations to burn down charts to handle changes in scope.

While discussing this recently, I realised why I don't like any of those variations: they are misrepresenting or destroying data.

Appending a vertical at each iteration transition as necessary means that's it's not as straight forward to determine total scope. Granted it's simple addition but that's enough to make it not immediately obvious.

Dropping the baseline is even more misleading as now the values on the y-axis are incorrect. If instead, we push all the historical numbers up, then we lose data on what the original values were (i.e., it no longer indicates that there was a scope increase).

In comparison, the so-called Goodwin-Rufer burn-up variant is quite easy to explain, understand, and all the numbers line up to reality and history.

The only additions I would add would be ranges for the targets but that's another discussion.

Despite all this, Alistair's article is still the best on the subject so check it out if you haven't already.

Grady Booch on the Promise, Limits, and Beauty of Software

I'm watching a number of videos from YUI Theater and just watched a very good one of Grady Booch.  This is a version of a talk previously given at the British Computer Society in honour of Alan Turing.

Grady Booch: "The Promise, The Limits, The Beauty of Software" @ Yahoo! Video

Many interesting points but one that sticks out for me is that the primary contributor to software cost is not people nor tools but rather complexity, with process, that is, how you deal with that complexity, acting as an exponent.

On chess grandmasters and the expert mind

Via Positive Psychology News Daily to Senia.com,

An older Scientific American article on the mental processes of chess grandmasters and the clues that provides for developing expertise in other fields.  This is the same research that led to Outliers and Talent is Overrated.

Jeff Bezos' demonstration of 5 Whys

Pete at shmula recollects an incident at Amazon where Jeff Bezos walked through a 5 Whys exercise:

Why did the associate damage his thumb?

Because his thumb got caught in the conveyor.

Why did his thumb get caught in the conveyor?

Because he was chasing his bag, which was on a running conveyor.

Why did he chase his bag?

Because he placed his bag on the conveyor, but it then turned-on by surprise

Why was his bag on the conveyor?

Because he used the conveyor as a table

So, the root cause of the associate’s damaged thumb is that he simply needed a table, there wasn’t one around, so he used a conveyor as a table.  To eliminate further safety incidences, we need to provide tables at the appropriate stations and update safety training.  Also, look into preventative maintenance standard work.

Greatness is never a given; it must be earned

It was way late for me to be catching the Obama inauguration live out here in Oz but through the magic of the Internet, I can just watch the full clip later.  This is my favourite section:

In reaffirming the greatness of our nation, we understand that greatness is never a given. It must be earned. Our journey has never been one of shortcuts or settling for less. It has not been the path for the faint-hearted — for those who prefer leisure over work, or seek only the pleasures of riches and fame. Rather, it has been the risk-takers, the doers, the makers of things — some celebrated but more often men and women obscure in their labor, who have carried us up the long, rugged path towards prosperity and freedom.

Seth Godin on the best middle name ever

Far be it from me to disagree with Seth Godin on marketing matters but come on... Winnie is THE Pooh.

Scott McCloud at TED

Whether or not you're interested in comics, Scott McCloud's talk at TED is worth watching simply for the presentation style:

On marshmallows and rewards

Kerry Patterson always spins a good yarn before he gets to the point.  This one is about marshmallows and rewards:

As I lay awake that night trying to figure out where I had gone wrong, it came to me in a flash of insight. The fact that I choked on the string was not the problem. Although gagging on the marshmallows probably detracted from my mystique, what really had gone wrong was my assumption.

Three things to consider for estimating

Accuracy
Precision
Time (to do the estimation)

Pick two

Jon Miller on Standard Work

Jon Miller describes the three ways of saying "standard" in Japanese and identifies the one that is part of the Lean concept of "Standard Work":

The concept of omote-jun as a standard is important simply because documenting the current method as standard is the very starting point of kaizen. Taiichi Ohno said that when you create standard work it was OK for it to be less than elegant, as long as you used this standard as a basis for continuous improvement. Standard work is not the idea of a certain fixed basis or foundation of work. Neither is it the idea of performing to a certain level or standard. It is the idea of creating the evident norm as a basis for making abnormality obvious so that kaizen can thrive.

The questions that I expect an iteration status report will answer

1. Is the project going to succeed in terms of achieving scope goals within time goals?
2. Where is the project trending in terms of velocity (i.e., rate of completing work)?  Does it require intervention?
3. Where is the project trending in terms of scope increases?  Does it require intervention?
4. How far have we used up overall project buffer in terms of cost?  Does it require intervention?
5. Are there any other issues that require intervention?
6. What was committed to and completed?  What was committed to and not completed?  Why?
   

Kernighan and Pike on 5S in software

The Lean tool, 5S is fundamentally about ensuring that abnormal conditions (aka problems) are clearly visible... as well as establishing discipline and participation.

I'm reading The Practice of Programming by Brian W. Kernighan and Rob Pike and they have a paragraph that is suggestive of 5S in the context of software development:

Consistency leads to better programs.  If formatting varies unpredictably, or a loop over an array runs uphill this time and downhill the next, or strings are copied with strcpy here and a for loop there, the variations make it harder to see what's really going on.  But if the same computation is done the same way every time it appears, any variation suggests a genuine difference, one worth noting.

No matter how many times you say it, we still don't need a QA on the team

Quite often I hear phrases along the lines of "We need a QA on the team".

I find this incredibly annoying.  I could just suggest that the behaviour is a sure sign of lack of education but perhaps it would be more useful to examine why I have a problem with the phrase.

1. It confuses a broad activity, Quality Assurance, with a role, tester.
2. It confuses Quality Assurance and Quality Control.
3. It confuses a role with a person.
4. It perpetuates the myth that quality is all about testing.
5. It perpetuates the myth that testing is all about quality.
   
6. It perpetuates the dysfunction of quality as someone else's problem.

Let me take a stab at defining Quality Assurance versus Quality Control.

Quality Assurance (QA): The design and implementation of processes (roles + activities) to ensure quality in a system/product/service.

Quality Control (QC): The design and implementation of processes (roles + activities) to verify the quality of a system/product/service.

QA = prevent defects; QC = detect defects.

There's a concept called mistake-proofing which has several levels in order of preference:

1. Eliminate unnecessary steps or components
2. Replace with more reliable processes or components
3. Prevent by product or process design
4. Facilitate to make work easier
5. Detect errors quickly
6. Mitigate to minimise effects
   

QA is about the design of the product/service and the processes that create that product/service.

QC is about inspection at various stages during the processes that create the product/service to ensure that defects are not leaked to the next stage.

Simple questions: Is it important to distinguish efforts to prevent defects versus detecting defects?  Are they somewhat different in design and execution?

An important part of Quality Assurance is the mindset that the next step of the process is your customer and that you don't leak defects to your customer.  So for example, I as a developer assure quality in my step and the external testing team is verifying that my efforts were successful.  Any defects that are leaked to the next step should be triggering root cause analysis and changes in our approach.

To emphasise the point again, another important part of Quality Assurance is the acknowledgment that you cannot "inspect quality in".  Quality comes from the design of the product/service and the design and execution of the process used to create the product/service.

Because Quality Assurance is part of the overall process of creation, it's associated with everyone involved.  Everyone has a responsibility for quality.

There's a book you may want to look at.  It's by this guy named Shigeo Shingo.  Of course, it's about manufacturing not software development, so feel free to ignore it and keep trying to inspect quality in.

There's an important concept in product development: The specification is the output, not the input.

Assuming that software development is a particular form of product development more so than a form of manufacturing, this idea that specifications are not inputs should also apply.  Testing is used to understand the boundaries of a solution space.  When will this component break?  How much load can it take?  What happens when it encounters certain kinds of input or environments?  This type of testing is not Quality Control; this type of testing is about understanding and creating a specification.

There's a blog post I wrote in June last year which I also consider relevant:

What's a role? How likely is it that the artificial and arbitrary boundaries of a role will match the natural boundaries of a real person?

You are not a tester.  You are a person who has capability to do testing.  I'm assuming that you have capability to do more than just testing.  I don't buy the unsubstantiated claim that testing is some kind of mystical innate talent that is mutually exclusive from all other capabilities.  Someone who has a job title that doesn't have "test" in it, may also have the capability to do testing.  Getting better at the activity of testing is a matter of practice, not talent.

That's it.  I'm done now.

Crayon Physics Deluxe

Via Penny Arcade,

Awesome demo of Crayon Physics Deluxe.  Looks like he's using an HP TouchSmart.  The game is also available for the iPhone.


Crayon Physics Deluxe from Petri Purho on Vimeo.

And now you can also check out the Penny Arcade comic envisioning Crayon Physics Deluxe battle mode!

So... I decided to ignore everything those top executives told me

Kevin Meyer at Evolving Excellence has an old blog post on a Harvard Business Review article, The Contradictions That Drive Toyota's Success. (I lost track of this the first time around but I stumbled upon it again)  The article is not free but Keven extracted an interesting section:

Each individual in Toyota is expected to act according to what he or she thinks is right. Every employee enjoys the prerogative to ignore the boss's orders or not take them too seriously.

Confronting your boss is acceptable; bringing bad news to the boss is encouraged; and ignoring the boss is often excused. In many of our interviews, employees told us how local operations had succeeded by refusing to obey orders or ignoring what headquarters had advised. For instance, the head of Toyota Motor Sales, U.S.A., Yukitoshi Funo, told us candidly: "Before I was sent to the U.S. in 1997 [as senior vice president], I made the rounds of several top executives in Japan. They told me to increase the number of sales outlets. These were executive vice presidents and managing directors. I went to the market to see the situation. Increasing the number of dealerships would have caused more intense competition and threatened proper management of dealerships. I decided to ignore everything those top executives told me."

It is only after the winter that you realise the pine withstands the withering

In a poor financial climate, there is greater pressure to survive and situations that challenge integrity will arise.  The most critical moments are not actually those that are public and explicit. The most critical moments are with individuals faced with a decision and choosing a path that seems only slightly wrong but is fundamentally so.

Survival with integrity requires a dedication to improvement which is a lot of thought, and a lot of work.  If anything, this is the essence of the Lean mindset.

The alternative is an organisation that doesn't actually survive in one sense and doesn't deserve to in another.  And it's definitely not an organisation that people of character will particularly care to be associated with.

Make any surface touch sensitive

Via Johnny Chung Lee,

Sensitive Object is a French company that apparently uses pattern-matching acoustic technology to allow turning any hard surface into a touch-sensitive input device.

The documentation of work is not about making a document

David Meier has an interesting Q&A at IndustryWeek.  My favourite answer:

I want to say this to everyone -- the documentation of work is not about making a document! It is about deeply studying the work and improving it and teaching it. The documentation is just a result of your learning. There is NO substitute for a personal one-on-one training. Documents are not used for training -- but they may be training aids. The job breakdown process is intended to make you think about what is done and how to best teach it. The goal is performance results and they come from training, not making documents.

The main trap is forgetting to pay attention to what is in front of you

Sean Landis tried to capture the non-contrarian view of the traps & pitfalls of Agile software development from the Salt Lake Agile Roundtable.

I would say that the main trap/pitfall I've seen is a tendency, especially from newcomers, to worry too much about Agile instead of paying attention to and thinking about their actual issues in their actual situation.

British Medical Journal medical myths

Via Lifehacker,

A couple British Medical Journal features on medical myths.  This was on the popular TV news before Christmas but I hadn't seen the original sources.  Part One and Part Two.

The myths:

• Sugar causes hyperactivity in children
• Suicides increase over the holidays
• Poinsettia toxicity
• Excess heat loss in the hatless
• Nocturnal feasting makes you fat
• You can cure a hangover
• People should drink at least eight glasses of water a day
• We use only 10% of our brains
• Hair and fingernails continue to grow after death
• Shaving hair causes it to grow back faster, darker, or coarser
• Reading in dim light ruins your eyesight
• Eating turkey makes people especially drowsy
• Mobile phones create considerable electromagnetic interference in hospitals

Trade-off versus challenge

When talking about project management you might hear about the need to trade-off time, scope, quality, and cost.

When talking about management in general you might hear about the need to watch out for productivity, quality, cost, and morale.  These factors are not traded off against each other.  Satisfying them all requires a change in how one thinks about and approaches things.

Malcolm Gladwell and Geoff Colvin on Charlie Rose

Signal vs. Noise points to a Charlie Rose interview with Malcolm Gladwell on Outliers.  From the links below, I also noticed another interview with Geoff Colvin on Talent is Overrated.

I have to say that Gladwell is a better interviewee but it's worth watching both.

No evidence in 2007 that CEOs were fired due to poor short-term results

strategy+business does an annual CEO Succession series.  The 2008 version won't be done until a few months into 2009 so let's look at the old 2007 one:

One of today’s most pervasive criticisms of corporate behavior is that boards of directors are driven above all else by the stock market’s demands for short-term gains. As a result, they don’t give chief executive officers enough time to develop and implement long-term strategies that will drive sustained performance. New CEOs, the story goes, have two years to boost earnings per share — three if they’re lucky — before their impatient boards give them the ax. 

The problem with this story is that it’s not true.

Another interesting point in the article is about outsider vs insider CEOs:

• Boards still opt for outsiders; outsiders continue to underperform. More than 20 percent of all CEOs are brought in from outside the company, despite the fact that in North America and Europe, outsiders, on average, underperform insiders. For all 10 years studied, companies headed by North American outsider CEOs underperformed regional market returns by 1.0 percent on average, and the gap for European outsiders was 2.2 percent.