nosewheelie

Technology, mountain biking, politics & music.

Sacrificing Quality should be an Executive Management Decision

with 2 comments

Quality (and the cutting of it) is something I’ve been thinking about a lot recently after transferring from a mature project onto a new one, with time pressures and little infrastructure to allow fast delivery of quality code.

At Agile 2006, Ken Schwaber talks about not allowing it to be sacrificed, emphasis mine.

At Agile2006, Co-founder of the Scrum methodology Ken Schwaber made a passionate case for maintaining software quality. Drawing examples of teams sacrificing testing, refactoring and other practices in order to meet deadlines, Ken argued that as professionals we should not accept business requests to sacrifice quality in order to meet timelines, and if quality does need to be sacrificed such a decision should be made by executive management and reflected in the financial statements of the company.

Ken’s message: Not compromising on quality is not only your professional obligation but it is also important for your own joy of work and is critical for the company.

Source: Ken Schwaber: Sacrificing Quality should be an Executive Management Decision

Written by Tom Adams

July 26th, 2006 at 8:59 pm

Posted in Agile

2 Responses to 'Sacrificing Quality should be an Executive Management Decision'

Subscribe to comments with RSS or TrackBack to 'Sacrificing Quality should be an Executive Management Decision'.

  1. This is something I’ve been struggling with lately. The thing is are executive manager aware of the consequences of sacrificing quality? Can they make any kind of informed decision in this area? The project I’m on called for some big changes to the thin and useless domain model it had so I had begun a rewrite as part of new features I was implementing. Of course this took time though it is the right thing to do in terms of quality: fixing previous bad design decisions. Increasing “management” pressureto see tangable results pushed me to cut corners in the implementation thinking it’s isolated behind the interface so that way I can fix it later without affecting much else … should this kind of thing be a management decision? How much of it should we try and explain to them?

    Marc Loxton

    18 Oct 06 at 7:27 am

  2. Eva…

    i like it :)…

Leave a Reply