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.
This post describes my own view on waste in software development. I recommend reading Mary Poppendieck’s book here. I was inspired by discussion with a bit frustrated product manager who mentioned that unless the organization understands how waste harms the bottom line, chaos would continue. Continue reading
In previous post here I suggested that historical data should be used for estimation and establishing of SLA. In this post, I talk about how we can give the up-streams dates for completion. The up-stream are those groups responsible on replenishing the back-log, who can be product managers, clients, marketing, management or others. The back-log card should contain the target date which the up-stream wants confirmation as early as possible on its viability. The first stage of Kanban board should address the following:
– assessment of technical risk
– establishment of technical solution to implement the requirement
– solution architecture
– task breakdown (e.g. graphic design, middle ware,…)
Estimation is embedded in first stage, however, it is being refined based on negotiating the solution between developers and product owner based on the constraints of cost and time. Doing sizing in the pre-sales cycle is almost always going to be changed when the backlog item is pulled to the development team in addition of waste creation as discussed in the above link.
The first stage of Value Stream should be the fastest. This in-order to provide quick feedback to the business on the viability of achieving target dates. The knowledge derived from this first stage can affect prioritization as well and should improve hand-off between business and development team. We can only commit to release date as we complete this stage.For me I would recommend board design to allow fast pulling of card and add completed cards into the queue of the next stage.
Accumulating backlog items to the backlog imposes high risk on our delivery ability and to satisfy the business users up-stream. Items which remain in the backlog can become obsolete and by the time they are pulled to the first stage the client might already changed their minds.
I summary use historical data to provide estimates during presales and use the first stage of Kanban board to provide commitment on release date.
Synchronizing the moment of having available capacity at downstream stage with the time an item completed by up-stream is for me the ultimate objective.
Because Flow has been enabled since:
– No stage with available capacity is idle
– No completed item is waiting to be pulled
Two issues here toward this.
1. Ensure a quality input to downstream
Rejecting items by downstream due to quality issue is major cause of waste to the harm of the flow. It causes rework, extra waiting and adds to the WIP.
2. Set WIP limit for every person not only for each stage
In Agile projects, it’s not uncommon having some person involved in multiple stages of the value stream. Setting the person’s WIP limit can avoid adding more work even if the stage WIP limit allows so. This can result in revisiting the stage WIP limit. Limiting the WIP has positive impact on quality and reducing stress on practitioners.
How we can influence client demand pattern?
To achieve Just-in-time, client demand should arrive when we are ready to immediately process it, this can serve to:
– Reduce waiting time of client demand
– Provide quick feedback to client
For me client demand should be full-filled and should not be subject to estimation, approval, Go/noGo, and other steps. For me those steps are non-value add, because the very reason of initiating a request is an operational need that the client encounters. We should believe that the client does not have vested interest to waste time of their business analysts in creating un-necessary work to the development organization.
Again, how to influence client demand rate?
If we can produce software at the rate of client demand, then this means that the demand should have arrived at the same rate by which we produce software. It’s kind of vicious circle! Let me say it in another way, if our software delivery system has been tuned to produce software at same rate of client demand, that means we have influenced the demand to arrive at the right rate to our system!
It came back to us!
The Kanban system is empirical and is based on continuous improvement structure to adapt to the varied demand rates. As the system become stable, that means the demand rate became predictable.
First, I state that I can’t improve the process; instead they should improve their work. I found this statement helpful by allowing the team to assume responsibility on their work and to position me as coach for building trustful relationship. The last thing they should worry about is that I am going to expose their weaknesses. This step is foundation for successfully working together. Trust shouldn’t be declared instead it’s judged by the team. Continue reading
The Japanese came with the idea of delivering products according to client demand. This is less obvious in software development organizations. This post intends to clarify this subject of demand analysis. I guess all organizations want to maximize their Throughput to meet and exceed client demand. The first step towards this goal is simple; understand client demand to arrive at patterns. We should build our software capability to address those patterns so that we can satisfy the demand. Continue reading
In a previous post here I discussed the benefits from having team value stream (TVS) to encourage collaboration and facilitating resolution of external dependencies.
Usually a product development organization has multiple product development teams with each operating under different context. TVS is useful tool to make team policies explicit and visualized to its members and the rest of organization. Continue reading