Lean for Knowledge Work
Agile methods promote experimentation to discover the unknown and desired product. Please see my post here. Not all software or IT projects require experimentation as noted in the post. Harvard Business Review article here suggested that Lean philosophies are well applied to non experimental IT/Software projects. Such projects will benefit from Lean approach in a way that can not be obtained from applying Agile methods.
Lean approach doesn’t dictate a prescribed method with orthodox ceremonies. Instead it empowers employees so that they act to the interest of the organization while at the same time expects managers to lead with soft control.
In IT/Software projects, substantial amount of knowledge is assumed to be tacit while in fact it is not. The HBR paper had data which supported that Lean principles applied to Knowledge Work has reduced Lead Time, increased quality, lowered cost and greater job satisfaction.
The paper advocated that implementing Lean in Knowledge Work can be very hard and it is a multi-years journey. Compared to manufacturing, Knowledge Work has far fewer repetitive and codifiable processes. But being hard journey will make the system tough for competitors to compete with.
I will explore the first pillar of Lean shown in the above diagram in this post.
Continual waste removal
Make everyone in the organization responsible on removing waste by making it visible. I believe having a visual Kanban board can be used as a tool for identifying and removing waste.
Partially done work
Limiting the WIP, will stop us from starting new work before completing the current work represented as wall cards. This means reducing partially done work to the total WIP capacity of the board. It creates habit for people to complete what they have started.
Defined methodologies which require considerable documentation and phase gates have proved inefficient in delivering fast what the client appreciates. The process is the visual board with quality policies defined for each stage and a Definition of Ready as prerequisite to pull work into the stage.
This is reduced by limiting WIP which will stop people from switching to new feature before completing what in their hand. Reducing waste of task taking longer time because of required learning that could be avoided if we did not task switch is an objective. Avoiding pulling people in a mid of a task to another one is a Lean discipline for reducing waste because of task switching. This is a commitment which require perseverance.
The visual board uses red stickies for features which are blocked. This visual control acts as alarm which warrant immediate attention from people working in the system, managers and others who can help. The Lean principle of “Respect for People” encourages people to take the initiative without fear.
The way I interpret this waste is how quick the knowledge is in reach to people if they need itl Waiting of knowledge can be in the form of needed customer clarification, investigating defect with tester, reach out to some other developer for help and others. Management establishes a system which allows people get the knowledge they need to do their work without delays.
Allowing defects to escape to the customer is very expensive. Generally defect escape from one stage to next is expensive too. Defects cause rework, task switching, delays and most important possible tarnishing in reputation. Mandatory defects must be communicated to the concerned person for immediate fixing once we discover them. We should set maximum limit for non mandatory defects. This maximum limit acts as another kind of WIP limit to reduce the first waste which is “Partially done work”.
Empowering people will reduce management overheads which contribute to all the above kinds of waste. For example, getting management approval on certain PMO phase will cause the wastes of Waiting, Extra Processes and Motion.
There are dependencies among all the above wastes and they should be addressed collectively. Wastes should be visual using the board as communication forum.
Root cause identification technique which is albeit being so simple is effective. Visualising the waste and correcting it should be followed by 5Whys for long term solutions which can have wider impact.
Small form of wastes linger through IT projects which can be the tip of iceberg for more chronic high impact issues. People should be active in identifying such wastes with same rigour given to visible big wastes.
Reviewing job description should be periodic and is the result of solutions to prevent certain pattern of wastes.