launchpad-dev team mailing list archive

[Maris Fogels <maris.fogels@xxxxxxxxxxxxx>]

Forgot to CC the list :/


On 09-10-08 01:02 AM, Martin Pool wrote:
> 2009/10/7 Maris Fogels <maris.fogels@xxxxxxxxxxxxx>:
> > When will we check back on the process to see how well it is meeting it's 
> > stated goals, and improve it?
> >
> > There is a great method from Lean and Project Management called 
> > Plan-Do-Check-Act, or PDCA for short.  The mail lays out 'P' and 'D' very 
> > well, it just needs 'C' ('A' comes later).
>
> This question pattern seems to come up a lot at Canonical recently, and
> personally I find it quite strange.  Why do you need a 'when'?

The problem is, without a 'when', you may never revisit the change to discover
if it actually made things better.  In the case of CHR, it took almost a year to 
ask "So does this actually work as we hoped?"

It also sets a pace for change.  If we had revisited CHR earlier, instead of
"whenever we get to it", we could have improved the process sooner, and spent
less time with a worse process.

> People here have a lot of interest in improving or deleting things that are
> not working well.  It is not always possible to fix things immediately, but I
> do think we do reasonably well at detecting things that ought to be fixed,
> without needing a specific reminder to assess them.  For instance, jml
> proposed this change (I presume) not because we'd got to an assessment gate
> for the previous CHR process, but rather because he noticed it was
> suboptimal.

That is true, but do note that CHR was set in place with a wide set of goals,
and it wasn't meeting a number of them.

For instance, one goal was to have those on CHR duty eliminate the bottlenecks
in their work, to fix the problems that CHR dredged up by themselves.  This
wasn't happening, and it was obvious pretty early on, say after three months. It
was also obvious early on that task switching for CHR duty was more costly than
originally planned.  If we had a fixed date to look at the process, at something
like the 3 cycle mark, these problems could have been dealt with back then.

I too believe that we are very good at detecting things which should be fixed,
but time pressures and task switching can cause things to run unfixed for a long
  time.  An assessment gate forces a time to fix things.  If the experimental
change is good, great!  No more gates.  If it is bad, kill it or fix it now,
before it runs any longer.


> Perhaps the correct answer is "always": we will always and continuously check
> if we are meeting our goals and always improve our process.  Setting a date
> to do something that could be done when it becomes necessary is anti-lean.

That is a good answer.

I personally do not see the use of fixed dates as anti-lean.  The date provides
a checkpoint and rhythm for the process improvements.  The experiment validates
itself at the specified date.  Building such self-correcting behaviour into the
system itself is also part of lean practice.

As a side note, there is an aspect of TPS Lean called Policy Deployment, or
Hoshin Kanri.  It very much makes use of dates, goals, and checks to ensure
things are progressing.  I draw my thoughts in this area from it:

   "Hoshin kanri ... is a Strategic planning/Strategic management methodology,
developed by Dr. Yoji Akao, that uses a Shewhart cycle (Plan-Do-Check-Act) to
create goals, choose control points (measurable milestones), and link daily
control activities to company strategy."

   "With hoshin kanri... the daily crush of events and quarterly bottom-line
pressures do not take precedence over strategic plans, rather, these short-term
activities are determined and managed by the plans themselves."

http://en.wikipedia.org/wiki/Hoshin_Kanri


Maris

Attachment: signature.asc
Description: OpenPGP digital signature