Koo Doy

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.

Why?

Because Flow has been enabled since:
- No stage with available capacity is idle
- No completed item is waiting to be pulled

How?

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. Read more…

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. Read more…

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. Read more…

Arguably, a software development team should not have a value stream (VS).  This is because VS  is a manufacturing tool and tends to be suitable for liner deterministic process which is not the case for Edge-of-Chaos nature of software development. Read more…

The product owner (PO) role requires multi discipline skills, for examlpe:
- Be responsible on deciding the right features at the right time
- Manage myriad of potential sources of requirements
- Product road map development
- Release planning
- Establish ROI from various features
- …… Read more…

WIP limit  can have profound effect on our Lean management thinking.

A good guess is to set WIP limit as 50% more than the current number of people working in the stage. Setting WIP limit to higher figure can lead to overwhelming the resources and create clog in the way of the flow. Setting WIP limit, at less than the head count, is undesirable in-general since it means having un-utilized people. Read more…

The visual board radiates almost all what happen in the project. I hold a daily Kanban board meeting with the purpose:

1. Get the team together in front of the visual board.
2. Ask team members from various stages to talk about the situation of their work.
3. Ensure equivalence of the story which the board tells to what is happening on the reality by team members.
4.  Investigate the status of items which have issues.

For me I found point 3 above is the hardest to achieve. It was amazing for me to learn how it was uncomfortable for people to put on the air what they currently doing and what they plan to do. The moment the team discusses the correlation between the board and the reality; fruitful discussions come to the surface. These discussions serve to:

-      Break ungrounded barriers
Stages of the board represent various skills of the team members. These skills are inter-dependent and visualizing the relevant stages on the board creates sense of collaboration and purpose among individuals apart from their skills.  Also, this can help to see and therefore improve how the team jells together.

-      Maintaining flow
This can be achieved by answering the following:
o   Are there any issues in the existing items and whether we’re taking resolution actions?
o   Do you know which item you’re going to work on next?
o   Is there any stage which has WIP limit more than the actual work?
o   Are there more items in the stage input queue than what it can process in reasonable time?

-      Recognize improvement opportunities.
To explain this point, once we had many issues for items pertaining to certain stage. The discussions revealed that the delay will always happen because of dependency on review. We resolved this issue by creating subsequent stage for review, freeing the problem stage from the stalled items.

Two weeks ago I met a client, who is transforming to Scrum, his biggest concern was that people may leave!

Showing lot of respect to his opinion, I sensed that he had ever increasing attrition of developers. I stopped short from even mentioning what Scrum prescribes, though he was specifically asking to implement Scrum. I didn’t want to mention dedicated teams, freeze changes during the sprint or release planning, or other practices which I practiced and value.

Rather than being interviewed myself, I began to interview him. He had projects  to be delivered at Fixed scope and Fixed schedule. He was worrying that a Scrum specialist would start pushing Scrum practices causing unpredicted impact on his environment.

For his surprise, I suggested that to hold our horses and don’t think Scrum or any other tool. I suggested to implement a gradual process improvement function that would allow solving the business problem he mentioned and continuously improving his capability to respond to customer’s varying needs. He was already preoccupied about using sprints, velocity, backlogs and other artifacts of Scrum. I suggested that he might like to consider Lead Time as the primary metric driving his continuous improvement activities. I emphasized that we don’t rule out the use of Scrum or any other tool.

Based on what we would discover we can decide on what to implement, instead of just go Scrum! Read more…

“Nothing is as invisible as the obvious.” Richard Farson

“It has been proven scientifically that the Loxodonta africana and Escherichia coli share most of the same characteristic” (Dr. Robert Charette from keynote at LSSC10 in April 2010). Then, we should expect that the creature we create from implementing organizational practices would carry similar characteristics and problems of the old system.

The two creatures, the old and new processes, may appear dramatically different though they are fundamentally the same. Then, how should we expect that our problems will be solved by moving to the new system? In my view, we might divert the attention of the organization to another endeavor till they ultimately hit the same reality (aka we still carry the same traits of the old system).

RskM in context

RskM is a practice that has rich body of knowledge. e.g. PMBOK® and CMMI®, however it has mostly been implemented in non-proactive way. Just to mention its importance,  traditionally we chose the software development life cycle (SDLC) of the delivery project based on risk assessment.

The implementation of agile practices requires enabling aspects or structures related to people, process and organization. These structures could be identified from up-front using risk assessment techniques. However, in my view, if we try to mitigate all risks from up-front, we might not start the improvement initiative at all.

Process improvement framework

A Kanban system provides evolutionary framework for incremental process improvement and therefore risk mitigation. It helps in implementing Lean practices to maintain the flow while at the same time the agile and XP practices can be rolled-out. In other words, Kanban system can envelop the implementation of various agile and XP practices to weather the winds that will definitely happen during process improvement.

A good starting point is to state the obvious (“the known unknowns” in RskM language) and use them as constraints in our process improvement  journey for discovering the root causes. More risks (” the unknown unknowns”) will be discovered as we progress which can be addressed under the umbrella of the Kanban system.

As we are moving our delivery projects to agile, it is about time to manage our process improvement and transformation programs in agile manner. Kanban system can be a good fit!

Acknowledgment: The above two pictures are from Dr. Charette’s presentation in LSSC10