You shall not compromise quality !
Last week-end Agile in Action asked whether we (as professionals) should you always do what customer wants (and don’t skip the comments at least one of those is great, will give you pre canned arguments in such a discussion and its not mine) ? It concluded that if a customer wants to compromise quality the author would walk away. I would agree with him, when it is possible because it is very much the sign of a barbarian culture on the clients part.
The way I understand it, quality is a measure of how well the software product finally delivered implements the desired properties (or qualities) and in particular the desired functionalities. In that context, compromising quality means that you are prepared to deliver a product that may not be fit for its intended purpose. Which generally really means they you want to go to the market as fast as possible, let the customer test (discovering in the process what they really use and how) and then fix the problems as fast as possible. In short a barbarian approach. I believe that stating it this way is actually acceptable because it means the client understands the implications of the choice to be as fast as possible (and it may even be ok to execute on this in very specific circumstances).
Obviously, this is exactly the kind of situations that Agile methodologies address best. They enable to discover the functionalities the client really cares about as well as how they should work. They enable to make the other -ilities emerge though refactoring when they become desirable attributes of the product. They enable to bring features to market as soon as they work (as opposed to before they are tested). They are more satisfying for both the client and the implementor.
In conclusion, rather than compromising quality for the things you need, drop the things you don’t. Unless your client wants to consciously sabotage the product and specify the bugs, truly making them features.
December 5th, 2007 at 12:33 am
Let me start by saying that I’m interpreting this compromise on quality as separate from the skill to determine the “needs” of a client from the stated “wants”. A client once asked me for a shared spreadsheet and I refused to comply because it would not solve the problem they actually had. I stated my reasons and my alternative proposal. This was grudgingly accepted and they resulting system was ultimately used across many businesses to handle thousands of trades for seven years.
Instead, I am reading this as an educated ranking of quality against other priorities. I have seen situations where a trader comes up with a new financial structured product and simply needs sufficient capability to be able to sell it to a client. Integration with the firm’s systems, scalability, automation and all that other good stuff is secondary. This can be because the first one to market will typically take all the revenue for the next 18 months, and the second to market will get zero during that time.
The stated need here was for an outcome-oriented solution. In that spirit, I have seen IT and various support functions collaborate successfully in knocking together a simple web interface for the client (to see positions or net value, or even to place orders) and all of the processing behind the scenes being done manually for 6-12 month - i.e. the solution was buggy software combined with hiring x low-skilled people to do repetitive and mundane paperwork. The client valued the opportunity to trade, and cared less about having to restart his PC every time an order was placed.
Don’t think that you can spend the next 6 months cleaning that up either. Now imagine that the following week another trader thinks up a new great product and that needs to be made available to the client asap…
This is my most extreme example of what you’re describing and it is a situation where you’re delivering well below your standards and not always able to enhance the functionality. However, the trader is prepared to take the risks and the company makes a lot of money with each one of these. In fact just about any other way to do this would result in losing the business opportunity or the client and their future business.
Agile works well in this environment, particularly because you can “bank” the value of every iteration where you get the chance to improve the technical foundation underneath all those products.
Where I oppose the “client veto” is where it would not be professional or ethical to allow certain choices. If the decision is made openly and with the participation of relevant groups (operations, compliance, risk, legal, audit…) then I have no issue. If the same trader attempted to put something on my queue without that involvement, I would not tolerate it and push it back or walk away.
December 5th, 2007 at 5:11 am
Your are putting too many -ilities (scalability, maintainability, extensibility, reuseability,…) under your understanding of quality. Quality is how close your product fits the stated requirements.
In your examples, how do you guarantee that the application you bang up satisfies its purpose ? I also specifically stated that in this kind of case, a barbarian approach may be acceptable if it is explicit.
Still my experience is that when you bang together an application that is actually useful, it pretty soon grows in size and user base and becomes very expansive to support. It is actually stuff of legend that the software that last longest in financial institution is the ‘temporary’ one.
Your remark is also based on the (flawed) assumption that ensuring quality lengthens the time to market. In my experience the main factors that lengthen time to market are:
inadequate requirements,
inadequate tools (like building a webapp in C++),
deploy-break-fix cycles (the barbarian qualiity insurane),
the learning curve (new tool, architecture,…).
December 5th, 2007 at 9:33 pm
I may have overloaded the term “quality” but in my examples the point is that quality is a scale. It takes longer to deliver higher quality so I fail to see how my assumption is flawed. I agree with your other factors affecting time to market.
The trader, the client and the developer may have expected and been used to a minimum quality level and this was not met. However, neither quality nor in fact the software itself were the common goal of the project. The goal was to deliver the structured product. Another (implicit) point is that I have seen some software developers behave as if the center of every project is the software, and failing to adapt when it is not.
The customer (i.e. the trader) expressed some requirements which needed to be delivered, but also some guiding principles that the project had to meet. Principles were more important than requirements, and they were things like “speed to market” and “focus on the outcome”. There was also a drop-dead date.
The initial delivery was barely fit for purpose. The trader was barely able to use the software and some of the requests-for-price were lost. The client was barely able to construct an order and experienced frequent errors and timeouts. Often, at least at the beginning, the communication reverted to the telephone or email, and the processing to excel. Both trader and client were happy though, because the transaction went through and they accepted this overhead not because they were used to buggy code but because they acknowledged that their minimum standards and stated requirements could not have been met in the time they provided even compromising quality. They also had control over prioritizing quality improvements or additional structured products or allowing other traders to process the existing product.
I may not sway you but I think I’m trying to express that there are environments and circumstances where saying “you shall not compromise quality” is too inflexible. Here is an extreme (and imperfect) analogy I will probably regret. How about a project where you are building a pipe to bring water to a village? Your customers request a pipe and you know how to build pipes so you set about doing that to the quality you know you can deliver. Now imagine that because of a natural disaster, you have to get water to that village before its population starts to die. Maybe the roads are impassable, there are no helicopters available, and there is no way to get them enough water in time. Say you have three days. The only thing you might deliver in that time is a low-quality solution that leaks badly and delivers water which will poison the village, but the villagers will thank you. While you are doing this, you recruit local people on foot to take bags of medicines to combat the disease your water might bring, and bags of sterilizing tablets to treat the water and minimize this disease. You have delivered according to their priorities which placed the flow of water above the quality of the water or the quality of your pipe system. Low quality, but overall goal accomplished. You then prioritize between doing the same for another village or improving the quality of the water and the pipe system for this village.
December 6th, 2007 at 5:22 am
[...] Agile « You shall not compromise quality ! [...]
December 6th, 2007 at 5:36 am
Cesar, the description of the system shows that the only quality attribute is the quantity of water delivered. So how do you guarantee that, despite all the leaks enough (or at least some) poisoned water arrives in the village ?
Compromising quality in this case means that you are prepared to lay down pipes that will not deliver enough (or any) water when you could have delivered pipes that delivered water by applying best pratices.
December 21st, 2007 at 7:24 pm
I used to think like Denis, in the sense of being a perfectionist in the software I build. Over the years I have learned, as Cesar points out, that my software is not the center of the little universe I am in.
More importantly, software quality is a continuum, like the line of real numbers, and one can only define what sufficient quality is. If one is a true perfectionist of quality, then one must refuse to work on a project unless formal methods are applied and the entire program is mechanically derived from a specification written in predicate logic (or something of equivalent power), regardless of whether one practices waterfall or agile or anything in between.
In the discussion above, the word “guarantee” is used in a number of places, but I wonder if even the perfectionists can “guarantee” anything — even when formal methods are used. You see, the initial specification I mentioned above, even thought it elegantly summarizes the requirement precisely, may be in error. There is no formal way to prove that this spec meets the requirement. To do that, the requirement will have to be specified rigorously, and then how does one prove that it is what is in users’ heads?
In summary, I am in general agreement with Cesar that one must look at the practicality of achieving high quality, this level of quality differs from one person to another, even among perfectionists.
January 8th, 2008 at 4:34 am
Hering,
I think the article does not fully convey what I mean by quality. This one was the result of a chat with Cesar to try to surface what I really mean by quality insurance.
Also, I fully agree with you on the achieved quality and the difficulty of having quality requirements. Which in turn is why I believe Agile methodologies are the best practical approach in many cases. In a few others formal methods help.