Absorption and Firefighting
Firefighting
Hiding things is not a long term strategy
We have recently written an article at our Assembly Mag column, Ps and Qs column on the metaphorical firefighter and things we do that encourages this behavior. There are many variants of this specific failure mode. To be clear, we are referring to valuing the heavy response when things are dire, over avoiding these possibilities proactively. Those people that step out of their part of the work, when we are on the edge of a crisis, are our firefighters. Our organization or projects, that do not value proactive measures but rewards those that help pull the company’s metaphorical fat from the fire. This Herculean effort is recognized, valued, and rewarded. Rewarding a thing encourages more of that thing. The organization’s culture can be moved to one of reactive rather than proactive and preemptive. We are not suggesting that this sort of intervention should not happen. However, we are suggesting that this happens more often than necessary. Additionally, our encouragement will create an environment wherein this reaction is more prized than proactive resolution. Ultimately, this hides the issue that caused the hubbub in the first place.
Hiding delays resolution or creating a long-term strategy to resolve. It might seem like we are helping the business by absorbing the trauma. At best we are putting forth a short-sighted, short-term solution.
I have been in positions where I have extended myself to solve the immediate problem. I likely had the misguided belief that one day this issue would become visible to management. I, like many team members, felt compelled to remove obstacles of the project, it did not matter if it was my responsibility, and often, from recollection, it was due to insufficient talent on hand for the project. There would be no management or other intervention to resolve. If there is no apparent or observable problem, there is nothing to fix. There was no complaint, and there was no dysfunction symptom.
Eventually, I came to understand this impact on the business at large. What may start out as a small issue, can turn into an ongoing problem. In this way, it is like eating liver, gets larger the longer you chew it. It is not good to treat the symptom, or more accurately, hide the symptom and not treat the underlying condition. To that end, I will share a story. For a variety of reasons, I will not use names or describe the actual event. I will describe the situation as best I can.
A story
I was in a verification group in a company. There was a large system that was under development and some of the parts for that system came from other suppliers and other parts from an internal supplier. For one of those companies, the team needed to understand how the internal supplier’s part of the system worked in the context of the system. How can you test a product, when you do not know what it is supposed to do or how it does it? What is in this iteration of the product? The internal supplier never sent any information on their product, which many would refer to as release notes. We knew the total amount of features available from the system, and some with insufficient detail to actually be able to test.
Try as we may, we were not able to get information on the iteration content of the internal supplier’s deliveries. Since the collaborative approach seemed to not be successful, we went another route. We started testing, top-down, the total features expected to be in the final product. We subsequently found defects in the product and reported the defects. Some of those defects were actual defects. However, some of these “defects” were missing features, that is, this content was not in that particular design iteration on the way to the final product.
Upon customer receipt of the defect report, the supplier informed us that feature was not yet delivered in this iteration of the product. I told them, if you cannot tell me what is in it allowing the department to focus on the product contents of that iteration, we will test top-down all expected final features. Doing so we will write defect reports for content that does not work according to the specifications.
After a few rounds of testing development parts with this missing content, the supplier better understood the need and expectations, providing release notes that described the product content. Previous development effort with the supplier, this difficulty was absorbed, nobody at the supplying organization nor the customer management knew this was a problem. Passing the pain of lack of release notes or any description of what is in the build to the supplier, writing internal defect reports that caught the customer management’s attention, brought the supplier to the table providing a list of the things that were in the build.
Compelled to find the solution because of the pain
The problem will be solved by the person or department that is feeling the pain. The testing group could have continued to feel the difficulty of not knowing what was in the product yet be expected and compelled to test, and most importantly, will be held “accountable” for defects that make it to the customer. Some companies have a political atmosphere allowing clear and open discussions about the difficulties. It is part of that whole, there are no problems, only opportunities. It is important to find ways to demonstrate the difficulty especially if you are encountering a systemic problem. The more that understand and perhaps feel the consequences of the difficulty, the more likely we are to find a solution.
