Koo Doy

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

This post is my own reflections on Agile organization after I read the following two posts:

1. Post-Chasm Agile Blues
   2. Swiss Limited WIP case study

Agile was explained in the Agile manifesto supported by Agile principles.

Why should the organization itself become Agile instead of the team level only? Read more…

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.

From my view, Program Management Office (PMO) helps when we engage with clients to address their requirements which can be full-filled through managing group of projects. PMO should use Work-Breakdown-Structure (WBS) as key tool for identifying required deliverables. By logically grouping these WBS items into projects, we can manage the whole work as an overarching program.The aim of this post is to relate the WBS items to Feature card (MMF) for managing requirements. Read more…

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

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.

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.

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…

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…