Home > Agile > Few resources the reason for bad quality?

Few resources the reason for bad quality?

The other day I was discussing with a project manager who is working in a large implementation project with multiple suppliers. He's really worried about one of the suppliers. The quality of the deliveries has declined during the project and even if the suppliers have "deliveries" every month, the delivery is not of useful software since they only have to make initial tests to find serious bugs. This has resulted in my friend always spending a lot of time after a so called delivery, verifying (or rather refusing) the delivery. In no case has a delivery been of installable quality and in most cases it has taken more than one week for the supplier to fix the so called delivery. In some times it has taken over a month getting a working delivery.

I've during this project discussed many times with the project manager, urging him not to accept this. A development team should not produce deliveries which are clearly of so poor quality that a 30 minutes test reveals catastrophic bugs. A software team which lets this pass their door has serious problems. Lacking professionalism, competence, leadership, technology or a combination. It is one thing that this happens sometimes but now it's a rule. What finally got my friend to react more strongly was when I told him that this supplier has no respect for his time. Since they every time send him this poor quality deliveries, they are wasting his time since he has to do their job making sure that the delivery works. We made a quick calculation of how much time they have wasted and this made him almost explode.

We talked through his meeting in advance, discussing strategies. But the outcome was not what we had expected. So, here goes.

My friend called to a meeting with the manager of the team. He asked how the manager thought that the deliveries were working. Since they are both in the same boat towards the customer, my friend felt that they should be able to have an open discussion. The manager said he felt things were working well.

Well? my friend asked. He and I had expected that the supplier recognized the problems and had some plans or excuses. But this was not what we had expected.

Baffled, my friend asked if the manager didn't see a problem with the deliveries. That he had to spend all this time verifying and testing. That the quality was so poor. That the customers were afraid for the new versions (my friend is not a tester so he does not find all bugs so many has affected the customer).

You might think differently, but I'm amazed by the answer given by the manager. He said that the problem was because they were understaffed.


This is such a bad excuse. You don't produce crap because you're too few developers. You produce crap because you don't finish stuff. If the developers don't have time to produce all the wanted functionality, they should develop less functionality in one sprint and making sure what they build really works. Where's the pride? I would be ashamed if I worked with that team. And my friend is ashamed too, that he's stood up with their crap for so long and that he didn't see this supplier for what he was.

Delivering crap can become a habit, just like not exercising or eating junk food. It perhaps feel like you have the right excuses but in the long run that's all they are. Excuses. And bad ones to. Just say no to crappy deliveries

Posted via email from forss’s posterous

Categories: Agile
  1. No comments yet.
  1. No trackbacks yet.

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 )

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: