Archive

Archive for 2010/03/03

A sole misfit is not diversity

My post on the risks about the small tight team has resulted in a bunch of interesting discussions. Olga Kouzina writes about the risk of too much discussions not resulting in anything productive. And I cannot but agree. When you are entering or is in the middle of an intense debate, remember why you're discussing and what the outcome can be of your debate. Too many discuss too long without any result. We need discussion best practices to avoid this.

But Kouzina also points to the risk of the single outcast and the lone Opposite, the one who is always opposing everything. I agree with her view point and I think a clarification is in place. Including a single opposite mind is not building a diverse team. If you choose a single person to hold this role to play the devil's advocate, you will not harvest the intelligence of the crowd.

Building a diverse team is a strategic approach to the whole team. If you think you're diverse if you have a single outsider you've nothing more than a hostage situation.

Posted via email from forss’s posterous

Advertisement
Categories: Agile

A sole misfit is not diversity

My post on the risks about the small tight team has resulted in a bunch of interesting discussions. Olga Kouzina writes about the risk of too much discussions not resulting in anything productive. And I cannot but agree. When you are entering or is in the middle of an intense debate, remember why you're discussing and what the outcome can be of your debate. Too many discuss too long without any result. We need discussion best practices to avoid this.

But Kouzina also points to the risk of the single outcast and the lone Opposite, the one who is always opposing everything. I agree with her view point and I think a clarification is in place. Including a single opposite mind is not building a diverse team. If you choose a single person to hold this role to play the devil's advocate, you will not harvest the intelligence of the crowd.

Building a diverse team is a strategic approach to the whole team. If you think you're diverse if you have a single outsider you've nothing more than a hostage situation.

Posted via email from forss’s posterous

Categories: Agile

A sole misfit is not diversity

My post on the risks about the small tight team has resulted in a bunch of interesting discussions. Olga Kouzina writes about the risk of too much discussions not resulting in anything productive. And I cannot but agree. When you are entering or is in the middle of an intense debate, remember why you're discussing and what the outcome can be of your debate. Too many discuss too long without any result. We need discussion best practices to avoid this.

But Kouzina also points to the risk of the single outcast and the lone Opposite, the one who is always opposing everything. I agree with her view point and I think a clarification is in place. Including a single opposite mind is not building a diverse team. If you choose a single person to hold this role to play the devil's advocate, you will not harvest the intelligence of the crowd.

Building a diverse team is a strategic approach to the whole team. If you think you're diverse if you have a single outsider you've nothing more than a hostage situation.

Posted via email from forss’s posterous

Categories: Agile

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.

What?

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