The visual board models the value stream. The stages of the value stream are exhaustive list of possible actions that could be applied on a certain feature card. This regardless whether this feature card represents new feature, client specific enhancement, requirement defect or bug. For me every stage in the value stream has analogy with method which is allowed to operate on certain object (feature card).
This analogy can be particular helpful to unify the understanding on what we could do when we process a certain feature card. Extending the use of the ticketing system to keep creating tasks linked to a ticket (card on visual board) can lead to waste due to micro management through task assignment. Instead confine the ticket to represent a card and use the visual board to:
- Provide common understanding of the value stream
- Ensure uniformity of methods which can operate in a certain card (UX, Graphic design, architecture, development, code review and so forth). This particularly can be helpful to improve the skills of people to better perform those methods. This has direct impact on quality and economy of delivery.
- A corollary to previous point, this analogy can serve to reduce dependency on single point of failure.
- Help to have consistent mapping of status of tickets in the ticketing system to the stage of visual board.
Exploding the ticketing system with tickets can be misleading because we should have business value attached to the ticket. Also, it reduces collaboration as task ticket is assigned by a team leader instead of being pulled by assignee whenever he has capacity. In general I found this creates inconsistencies.
Ticketing system and visual board are complementary. While the ticketing system is excellent for tracking, automating builds and communication with other support groups, it has limited value during the development of the feature card. Feature card development is a different game which requires high collaboration through visualization and having the ball bounces back and force between various stages of the value stream.
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.
Despite the delivered software has no bug, it is not uncommon for clients to ask for changes. This for me is a Requirement Defect. This corresponds to Validation activity of the V-model to ensure that software would be working and acceptable in its intended environment. Software Validation is implemented in Agile through product manager review. Read more…
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.
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
- Presence of heroes
- We create defects
Please add other symptoms.
The product backlog is arguably the most important artifact for Agile team.
The problem is how to ensure that the product backlog timely includes all requests with their relative prioritization apart from their source.
This takes us to the product owner role in managing the hand-offs from demand to the development team(s) using the product backlog as medium of communication.
The biggest team complaint is that there are back doors for pushing requirements. This situation leads to:
- The team takes prioritization decision.
- Rift the team from following the value stream due to uncontrolled work as it’s not included in the visual board.
- Compromise the product by making the team working at low value requests.
As shown in the diagram, the product owner is responsible to coordinate with all possible sources of requests and translate their needs into prioritized backlog items. The backlog item is a card on the visual board and can either be MMF, Defect or Service. It is important to have explicit policies for each of these three types. Adding the dimension of priority (regular, target date and urgent) can add rules to these policies.
Finally, being a gate-keeper, the product-owner can ensure:
- The integrity of the product,
- Avoid adding requests which create technical debt,
- Assume ownership on the product acceptance, and
- Be considered by the team as the ultimate authority for clarifying requirements.
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. Read more…
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. Read more…