Process Cycle Efficiency (PCE)

Five years ago I prepared report for a Lean transformation for a certain client department. The PCE was less than 1%! PCE is defined as the ratio between the time we actually spent working on a feature to the Lead Time. PCE is an average metric.

The purpose of this blog is to explore if there were only one metric to choose, should it be the PCE and why. Continue reading

Addressing the needs of people and business

Process improvement has been doomed to be a waste function by many organizations. From my background, many who work in process improvement are treated as compliance workers instead of being contributors to the bottom-line. For me process improvement is the business. Every day we take decisions to get certain benefits. Continue reading

Institutional logic

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 Continue reading

Lean-Agile company

What I learned from Theory of Constraints that the overall system performance is determined by the slowest component in the value chain. What I learned from lean (esp Toyota Production System) is that we implement fastest way to respond to client demand and removing waste which elongates the Lead Time. What I learned from Agile is that software teams are self-organized in order to commit on delivering client valued software incrementally and often. Continue reading

Embedding Scrum in Kanban board

In a typical maintenance project managed using Visual board, we can have cards representing bugs, enhancements, new features or new product development. All card types can be managed using the value stream of the visual board except for new product development (NPD). The NPD represents fundamental architectural change into the product leading to break through added features to the existing product. Such NPD card can be managed as Scrum project because of the following.

Long duration
A typical NPD project can take in average 10 weeks which is much longer than cards from other kinds.

Team effort
While a typical card can have one developer, for NPD it requires team.

Requirement management
NPD by definition means requirement will evolve and new discoveries about the product would occur from one iteration to the next. This kind of convoluted development activity would require highly iterative and risk oriented delivery of slices of the requirements.

Different value stream
The value stream for non NPD card is agreeable and visualized. The NPD can have a very different value stream and can employ different skills from the maintenance value stream.

Technical risks
NPD involves myriad of technical risks and can require substantial architectural and design work.

Management oversight
For NPD management and business users would require periodic review of the increment for feedback. In normal value stream though these review  can occur but not to the extent of interactivity required for NPD.

Marketing analysis and ROI
NPD is driven by marketing and financial analysis of ROI. In additional to the technical product risk, there is also financial risks due to competition from other vendors. The revenue model is important for NPD and derives the prioritization of backlog of a NPD card.

Based on the above factors, I would recommend managing NPD card as sub-project using Scrum.

How to classify the card as NPD? Use the above factors as check list. Another rule: the card should be classified as NPD if the current value stream of the visual board fail to work.

What about code integration?
I suggest managing NPD card as separate trunk in the version control system. It can take multiple iterations before we can have shippable product, at that point we should start merging this trunk with the baseline product.