Personal Kaizen

I've missed the first Monday of the month by a mile, so I'll roll November's and December's Kaizen into one. Where did this month go?!

I've been continuing to try to increase the integration of planning tools on a Sharepoint site for project management and probably reached a sensible end point at the beginning of December. Any more work will be too much for a diminishing return. However, this seems to be the month that a turning point has been reached: we have Product Managers suddenly interested in Agile techniques and a department head showing a keen interest in moving our ad-hoc methods towards a more unified tool set. This represents both great opportunity and a challenge. It's a time for enthusiasm and commitment for the future, yet also caution and careful decision making.

I've rather failed to get regular GCC Linux builds going, which is annoying and this still needs to be done, as I think this has the potential to push up the quality of my code. This effort was unfortunately hijacked because my main Windows box died and the box I was ready to install Linux on was suddenly needed to do all of my work. Now, I have three windows PCs, which should reduce to two (when the worst of the bunch is rejected). One will then be turned into a Linux box, or perhaps have a Linux VM installed.

I also promised myself that I'd look into how the Toyota principle of Jidoka could be applied in our process. It seems that many people share a view on this, but know it by different names and arrive at it from different perspectives. There seem to be two things that we can do in the relatively short term

1. It's emerging that if we can all "move to the blockage" in our development line when a Big Bug is discovered and focus on getting it moving again, then productivity will actually go up and worries that highly paid developers will be doing menial testing are unfounded.
2. We have to solve the "root problem" before we re-start the line (part of the principle!), and there seems to be concensus that this normally means putting the automated tests in place to prevent similar show-stopping bugs ever making it to QA again.

I've had some interesting side benefits this month after installing Windows 7 on my main PC after it was repaired. There are just a handful of productivity shortcuts that really seem to keep things moving fast without me having to actually use the operating system much at all! Also, a simple system for mirroring our centralised automated build and test system on local machines has proved incredibly useful in flushing out bugs in merges of release branches to our trunk prior to committing the changes, and it all happens while I'm safely tucked up in bed.

Next month I've a few things down, which I'll report back on at the beginning of February:

• My GCC Linux box or VM.
• Looking into ways to inject a bit of FMEA into our processes without too much effort.
• Find some good project management courses before my CPD assessment: Masters courses hopefully.
• More books: I seem to be coming to the end of the last pile a picked out.
• Find out if I've become a Chartered Engineer!