Also known as
At least very much related to Kaizen, or 改善.
As the back of the card says, if you don’t get better, you get worse.
This one is simple: this is always applicable.
In a Scrum process, this is typically what you discuss during the retrospective. You first discuss the things you considered to go well, but then right after that, you talk about the things that could be improved, and then you see to it that you actually take some steps to improve.
However, Scrum is not the only context in which this is applicable. It’s equally applicable in - say - developing your coding skills. If you are wondering what on earth you could improve in your coding habits and you haven’t read the The Pragmatic Programmer or the The Productive Programmer yet, then I’m pretty sure there a couple of things you can learn.
Continuous improvement requires dedication, and dedication required dedicated time. It’s important that you and your stakeholders agree on the time you are going to claim to improve continuously. Resist the temptation to consider continuous improvement to be something you get for free. Granted, you may be able to weave some improvement into your daily activities without too much cost, but there is a risk you maneuver yourself into a position in which your drive to improve continuously in your work will start hurting you in your private life. Again, continuous improvement is benefiting your stakeholders as well. Make sure that is well understood.
- The Programmer’s Bill of Rights, Jeff Atwood, http://www.codinghorror.com/blog/2006/08/the-programmers-bill-of-rights.html
- The Productive Programmer, Neal Ford
- The Pragmatic Programmer; from Journeyman to Master, Andrew Hunt and David Thomas
- Kaizen, http://en.wikipedia.org/wiki/Kaizen