Following my previous post here, I will continue with the 3rd step for Lean implementation in IT/Software setup. Let me explain what the symptoms of poor communication are:
- Disconnect among management, people, project stakeholders and the customer.
- Not asking the right questions. Read more…
This is the second post for implementing Lean in Knowledge Work based on Harvard Business Review article here, you can read my previous post about visualising waste here. When trying to make knowledge explicit, we should appreciate the following:
- People are non-fungible. People differentiate themselves based on their character and ethics.
- Skills are levelled: We will continue to have people of varied degree of competency in certain skill.
- Having knowledge explicit will never replace people and their interactions. Read more…
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.
Read more…

For large projects, the size can be 50+ people working for 1.5 to 3 years, which is more than 100,000 man-hours/year. If the project is about to sink, new skills will be required which are not available in the project team.
It can be surprising how such entity which can have wealth of skills and resources are not capable to save the project. In fact the ship captain and crews will step aside (either voluntarily or forced) and leave the helm for rescue consultants till the ship becomes ready for normal operation. Read more…
This post is my own reflection after reading Harvard Business Review article of Nov. 2011 here. This article focuses on six perspectives or convoluted means which great organizations must have in-order to succeed in today’s globalized economy, which are:
1. Common purpose
2. Long-term focus
3. Emotional engagement
4. Partnering with the public
5. Innovation
6. Self-organization Read more…
In this post I describe a perspective of visual board when it’s used with an automated ticketing system. In current project which I facilitate its Kanban implementation I introduced a practice of process review. During which we found gaps between the board and the ticketing system, for a given card we can have:
- Visual board is correct state while ticketing system is wrong: This was the case for the majority of cards having inconsistency issues. This is rather easy to fix by agreeing and communicating instructions with team on the mapping rules between the states of the Kanban board and those of the ticketing system.
- Both states in the visual board and ticketing system are incorrect: This was failure in the process implementation and would require that we may change our mind on the implementation approach.
- Visual board is incorrect and ticketing is correct: This was very rare and in fact we didn’t encounter this situation.
Discontinuing the visual board and use electronic tool on top of the ticketing system can lead to drop in the Kanban process implementation. The visual board allowed:
- Collaboration among all team members to discover issues which otherwise could not have been found if we use electronic solution alone.
- The manual board can act as data validation process,which is often a missed step of a measurement system. Data captured in the ticketing system is validated against manual board which creates improvement opportunities for the whole process.
- Increased degree of transparency between what actually takes place and what is being reported.
- As corollary of previous point, the implementation of the visual board has raised the morale level of team members and improved trust.
- Produced accurate data to top management for deriving the overall process improvement.
The ticketing system is not the process; instead it’s a tracking system to help in implementing the process. The real process is what happens at the visual board, and by implementing the agreed on mechanics of engagement among team members. We can’t rely on the data of the ticketing system if the manual implementation of the process is unclear. The data is reflection to a process and in the absence of the process the data can be misleading.
Having a manual board for 2 months period or so before introducing a tool on top of the ticketing system is my preferred approach. This will allow the process to be substantiated among team members and to produce meaningful data from ticketing system.
Probably he’s me!
He is the perfectionist who wants to continuously improve. He’s theoretical and at the same time is passionate to implement so he can prove or disapprove his theories. Read more…
Ben, an engineer in our development team reported two issues from production and he didn’t like to report them as bugs. A bug is visualized as red card on the visual board and is visual to the whole organization. Read more…
For a product development organization, being driven by man-hours as measure for managing its operations, lends itself to the command and control zone of management. Instead of measuring and tracking how we meet client demand, the focus is shifted on controlling this measure.
This measure leads the organization to judge its performance based on the cost of its people instead of Throughput. Instead of being considered opportunity, people are perceived as liability. Therefore, Man-hours emphasize on maximizing people utilization. Read more…

Why we can’t accept work from our clients?
Answer: because all people are busy.
Why all people are busy?
Answer: There are so many projects and deadlines.
Why didn’t we plan this current work?
Answer: We planned, but it didn’t work, in addition our work has lot of defects (we call this maintenance to be nice).
Is this maintenance sort of new feature?
Answer: NO, it’s failure from our side and considerable percentage of our people effort is spent addressing them.
Why you didn’t tell me about that before
Answer: none… ** Fear **
Symptoms of Fear behavior:
- We are always busy
- People are forced to do work on expense of quality. We create our own technical debt.
- We always change priority
- We don’t dare to ask our manager to give us work because of available capacity
- Distrust
- Presence of heroes
- We create defects
Please add other symptoms.