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
Category Archives: WIP
Team Value Stream
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. Continue reading
Cost of Poor Quality (CoPQ)
As consultant your first action was to ask the client about immediate problem. The discussion has revealed to you that there is performance measure (Y) to be improved so that to help solving existing issues. Y is the percentage of features which the deviation of target and actual delivery dates exceeded “3” days.
The derivation of Y was based on analysis, for example:
- Understand the Voice of the Customer.
- Identify the Critical to Quality variables which impacts VoC.
- Data to support the above.
Now you want to analyze further what are the input factors which affect Y, as shown next:
Let us assume we analyzed existing data based on the above factors and we found that client requests, which have contributed to the main delays in the system, are having:
Technology = Perl,
Existing module design = Based on previous architecture,
Change impact = database and services modules, and
Software configurability = NA;
In a previous post here I suggested that WIP limit tends to be not followed by people who have scarce skills, in our example here they are the Perl developers.
What this means?
This means that the empirical observation of exceeding the WIP limit for certain stage, and showing resistance by people who work at that stage, are backed by data which directly impact Y.
By having shortage in these scarce skills, Y will increase which will increase CoPQ. Therefore, we’re not economical in our delivery of maintenance requests.
Instead, I suggest adding a separate class of service for Perl based requests in the above example with its own policies. The class of service helps to identify:
– Prioritization scheme
– Request hand-off from one stage to the other
– Expected SLA performance
– Any specific workflow rules