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. Continue reading
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. Continue reading
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. Continue reading
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
- Presence of heroes
- We create defects
Please add other symptoms.
Each team operates under a different context. The purpose of this post is to characterize team context using objective factors. This characterization should improve our understanding about what can matter most when developing a team Agile process. Continue reading
Going to the plain basics, maturity is to deliver what we promise. I heard this definition from a successful sales executive of product development company. For me this summarizes everything!
Meeting commitment is arguably the most important criteria for success. I use the measure of requests percentage which have deviation from target date exceed “x” days. This measure helps to quantify our maturity as organization. It represents the Voice of the Customer (VoC)
This measure can be organizational wide and it can be used to drive the whole improvement initiative.
The following chart gives high level analysis of causes of immaturity as suggested by this measure.
The foundational cause is the inability of people to timely communicate their issues. I worked with developers who had one month-long tasks and kept reporting that things are according to plan till they report failure at the very last day! I carry the responsibility by not allowing trust environment which encourages them to talk and share their concerns.
Sales people making commitment without consulting engineers is well-known issue which can be solved if they are educated about the capacity measures. These capacity measures can directly improve the above VoC measure. The capacity measures include Average Lead Time for each Class of Service. This measure allows sales people to provide informed estimates in the very narrow window that they might have to secure a deal. They can add percentage of uncertainty based on the inherent risks. I suggest this should be maximum of 20% with promise of being reduced as we proceed into the project.
Finally, a key assumption for failing to meet our commitment is the poor definition of customer valued request. Delivery on time requests which are not meaningful actually invalidates our improvement effort.