Forgot to CC the list :/
On 09-10-08 01:02 AM, Martin Pool wrote:
2009/10/7 Maris Fogels <[email protected]>: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 discoverif 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
