Flexible quality

One of the things I have observed is that some projects get into problems caused by quality issues. The following 3 properties are part of every project:

  1. functionality: the stuff that needs to be implemented
  2. time: the total amount in man hours (budget is also expressed in time)
  3. quality: structural/code quality, maintainability, number of bugs

If functionality and time are fixed, the only thing that is flexible is quality. So especially in the end of an iteration, when the pressure is felt, the quality goes down: code doesn`t get refactored and the structure degrades, test are not complete or totally missing. The problem gets even worse because the next iteration is going to contain debt from the previous one. If this debt isn`t added as in issue for the next iteration to solve, you will get a lot of hidden work, and hidden work is a recipe for project failure.

The Agile methodology promotes fixed time and fixed quality, so the only thing that is flexible is functionality. I’m a very pragmatic guy, so flexible time (so increasing the length of an iteration) would be negotiable (although you could loose your rhythm) but when quality is negotiable I think you are on the road to project hell: unhappy customers, developers and managers.

2 Responses to Flexible quality

  1. Kevin S. says:

    After a successful year of trial by fire through an agile transition at a global 15 company… I will quote a mentor. It is management’s job to manage the project, not the teams.

    My team will no longer allow quality to be negotiable. We also do not allow the iteration to be negotiable once it is started… we tried this once and it led to a never ending iteration that was worse than the original fixed one. We could easily see the damage of extending the iteration (even if upper management couldn’t). The only negotiation is functionality. As long as the team is honest and transparent, the daily standing meetings will provide all the head’s up that is needed to make wise decisions just in time on this issue.

    Note: the team is running scrum and xp.

  2. In the original XP book, they talked about four factors of software development: money, time, quality and scope (functionalities). You can control three, but not four.

    Now, if you look carefully, you will find the only one that does not appear on the manager’s results.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: