launchpad-dev team mailing list archive

["Francis J. Lacoste" <francis.lacoste@xxxxxxxxxxxxx>]

On October 8, 2009, 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'?

Because otherwise people just settle in the new constraints. 

> 
> 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.
> 
> 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.
> 

Always is probably not the right answer. You usually want to preserve a 
process from more changes to give it enough time to settle in it get passed 
the initial bumps. So saying that we are going to try this experiment for 4 
weeks and then reassess is actually very useful. It gives enough time to give 
a good try on the process and then call for an evaluation. 

Once this habit of change/evaluate is well ingrained, then it becomes second 
nature and you might let go of the need of scheduling the evaluation. But we 
are not there yet, we are currently more at the level of change something and 
then live with new accommodations until enough people complains and start 
doing something about it.

-- 
Francis J. Lacoste
francis.lacoste@xxxxxxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part.