By cfossguy
via cfossguy.blogspot.com
Published: Jun 22 2009 / 09:04
Poor software quality is bad and should be avoided at all costs. Maintaining a high quality level is increasingly difficult as the project duration and team size increase, but it is not impossible. If you are using Scrum or another compatible agile methodology these ideas will help bring quality back.



Comments
reboltutorial replied ago:
"At all cost ?" I don't think the financial guys would agree :)
As for agility this is nothing really new, people are rediscovering Deming's Continous Wheel of Progress that is contrary to what is taught in Business Schools:
http://statistical-process-control.org/dr-demings-revolution/
James Williams replied ago:
I'm a firm believer that low software quality is to be avoided at all costs and I believe that with proper cost/benefit analysis the financial guys can be convinced to invest in quality. But, quality doesn't mean that R&D labor costs need to be abnormally high. Quality also doesn't mean that delivery dates should slip. I think the number one rule to quality is to ensure that developers take pride in their work. Some people may feel that the ideas in my blog won't work but I think they will if given a chance.
reboltutorial replied ago:
I think your ideas violate the 14 points of Deming's management:
http://statistical-process-control.org/deming-14-points/
For example your Wall of Shame is contrary to
"Point 8: Fear is a barrier to improvement so drive out fear "
,
James Williams replied ago:
First of all, the URL you posted in your comment returns a "forbidden 403" code when I try to access it. Secondly, I agree that calling out a team member for poor conduct could make that person fearful, and that's not good. But, I believe that agile teams should be a close nit group that trust and respect each other enough to be candid. The Open Source community does this exceptionally well and I think many enterprise development teams should copy the idea. Maybe the "Wall of Shame" is too extreme, but a properly working agile team should not have software quality issues to begin with.
Voters For This Link (8)
Voters Against This Link (2)