Sunday, March 19, 2006


If QA accepts a mantle to look at your project and tell you what is wrong with it (where it doesn’t meet it’s requirements, or more importantly where it doesn’t meet the customer’s expectations), then they are giving you a fish and you can have dinner tonight – cook it nicely, you may not ever get another. If QA instead identifies variations and deviations from expectations, and tells you what is wrong with the process such that these variation were allowed, then you will have dinner forever. By inspecting the process rather than the product, you are able to root cause the problem and increase throughput – by fixing the process, you eliminate the problem, not just identify it. In a portfolio organization, process problems most likely exist in multiple projects, not just where the problem is found. Each problem can be better viewed as a symptom rather than the disease. Cure the disease, save the patient.

Curing the disease is frequently hard. My daughter’s favorite TV show right now is one called House. It is about a curmudgeon of a Doctor who specializes in the really hard cases. Fascinatingly, every week someone comes into the hospital with seemingly obvious symptoms for a disease that is initially not cureable with the obvious solution. After several minutes of addressing the wrong problem, the antagonist (he is really the literary protagonist, but if you ask anyone, they will say he is far too antagonistic to be a protagonist) will do a hard restart and stop treating symptoms and start looking at the process of the disease. In that process, something invariably comes up that is the clue to cure the patient. Everyone but House is happy and next week, it all happens over again.

Root Causing the problem is tough. But often, finding the real problem is the only way to save the project and the process. As Mary said, use inspection to find the symptoms, and then perhaps Socratic methods to find the problems. Solve the process and you solve for the portfolio.

Living organisms are strange and complex systems. One of the mysteries about it that I always marvel at is their ability to heal themselves. When they are not able to do so perfectly, they do so sufficiently. They adapts. Where the adaptations are successful, they evolve.

Often times, when we come up against a constraint in our process, rather than eliminate it, we create an adaptation to work around it. If we don’t regularly evaluate our processes and hunt out these adaptations, they will evolve until they are so ingrained into our fabric that they can not be removed without dramatic and invasive surgery.


Blogger Tom Looy, Thoughtworks PM said...

Can you provide an example of the adpatation that you refer to? The reason I ask is, won't these adaptations eventually show up as constaints? I don't see why they need to be identified any differently than constraints.

9:20 AM  
Blogger mgelbwaks said...

Adaptation are certainly constraints, but because they become part of the fabric built to compensate for the constraints, they tend to be 'missed' upon further analysis.

Think here, biological adaptations - galopagos type: the finches evolved to be able to eat the local food. Now, if you took them back to their original habitats, they would not be able to survive due to the adaptations. These have become part of their fabric. They were originally necessary, but in the new environment, without the food constraint, they would all die pretty quickly (or re-devolve, but that takes more time than a normal company has available to it!)

10:23 PM  

Post a Comment

<< Home