At the end of the past century, the approaches and methodologies (Information Engineering, RUP, CMMI) that were trying to improve software development processes and projects had a huge documentation on how to do things, initially on large documents sets and then on CDs. Checklists were often used as gateways between project phases and you had to confirm that every goal of the phase has been addressed. Then came the Agile Manifesto that proposed a new approach preferring “Individuals and interactions over processes and tools”.
This switched the software development process from picking a roadmap in an existing large body of proposed (or imposed) tasks to building upon a minimal framework, guided by general principles and with only few recommended practices.
One of the problems with methodologies and procedures in large organizations is that they were often created by people in a staff function that were not eating their own dog food. Thus checklists associated to these methodologies had a bad reputation. You would cross all items, just to move your code or project to the next level, even if you hadn’t actually performed the required code inspection. Checklists are however useful in software development and approaches like Lean recommend them to make the knowledge explicit. There is a difference between having checklists that are proactive tools to preserve, share and discuss knowledge and the checklists that are just gateway items often responsible for habits sclerosis.
You should consider software development checklists like cooking recipes. When you start cooking, recipes give you a quick access to the knowledge of expert cooks. However, as long as you know only what to do when you cook but not why you do it in a certain way, you might face disappointments if the size of your your fish or your oven are not exactly the same than the one used to create the recipe. The more you master the art of cooking, the more you can modify existing recipes to your taste or what you have just found on the market. At the end you might even be able to create your own recipes. If you cook this special meal only once every six months or if you need to share it with a friend, then you have to write down the recipe. This is the same for software development good practices. Your checklist will naturally contain what to do, but it will be even better if you write and explain the why, how and why not of its content.
If you are reading Methods & Tools, there are chances that you are convinced that you can share and keep knowledge with written material. You can do this inside your organization too. Just start to write one checklist for something that you don’t do often or share your knowledge with a new colleague. Your good resolution for 2013 could be to put writing checklists in your to-do list. Happy New Year to everybody.
Further reading:
* Just checking, do you use checklists?
* The Power of Checklists