Archive

Archive for March, 2010

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.

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.

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.

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

Categories: Agile

Which gangster organization do you work for?

Yes, it sounds like one of those stupid Facebook quizzes, but this example is in James Surowiecki’s Wisdom of the crowds. He differs between three organization styles which can be found in gangster movies.

First up is Michael Corleone in The Godfather II. He’s the good guy, who built his organization with a hierarchy. It enables a growing organization, where a lot of trust is given to the local managers. Michael have lieutenants everywhere, which enables him to manage without being present. So, the organization grows, becomes even more wealthy. But the same structure brings wealth it also brings the downfall. Michael isn’t reached by necessary information. The lieutenants keep information from him, skim the business and betray Michael and the organization. Michael has hundred of men working for him but his distance results in him not owning the organization anymore.

In Robert De Niro’s character in Heat, we find the small specialized group. All the members monitor eachother and the individual gain is great since no one is surplus and the rewards are immediate. To the disadvantages are that the group are also limited by the specialty of the individual group members. The rewards are directly connected to that everyone succeed which leaves little room for errors. The downfall comes in a new member not following the script, and that is also common to the problems of this type of group. Every new member is potential a huge risk since everyone have to work.

In Reservoir dog we find a third type of organization. The individual group members are hand picked for a special occasion and the group is built for a specific project. When the project has finished, the group is broken again. The advantages are that the possibilities are great since you’re not restricted by the competence of a specific group. On the downside are the costs for building a group and sense of a team. There is often no or little trust which is a great risk and is costly.

So what is the ideal model? According to Surowiecki, none is perfect but you should try using the strength of all types. All enterprises need some of the Corleone to be able to become bigger. But in a pure Corleone organization, the management becomes detached. In the daily struggles, the closely knit group probably works best, but when it comes to building innovation, it can be a good thing to invite the reservoir dogs.

As for me, I’m not that into gangster movies but I must say that The Godfather I is a beautiful movie to watch. That does not mean that Vito Corleone is the boss of my choice.


Categories: Agile

stupidity of the team

2010/03/01 2 comments

I’ve just completed reading Wisdom of the crowd. It was not what I had expected, since the context within which I was given this book lead me to believe that it would cover something completely different. But this is not a bad thing – the area which the book covered is much more interesting than the area which I thought it would cover.

If you’ve read the book, my posts on the content will be old news but here goes. The book is about how the minds of many can produce better answers to questions than single expert brains. The average solution of a diverse and heterogeneous group can in many cases be closer to reality than one expert. Of course this is not always the case and single experts can of course outsmart the crowd, but this is absolutely not always the case.

But before I tap into those stories, I will first cover the stupidity of the team. Working with agile values and team work, this was a very interesting chapter.

Surowiecki sees great risks in team intelligence. What his research shows that a team often tend becoming more stupid than the individuals. Not 1+1=3 but rather 1+1+1+1=2

So, which teams are in the risk zone for building team stupidy?

According to Surowiecki, the small, closely knit homogeneous team tend to build team stupidy. 

But why?

In small, homogeneous groups, like minded ideas are welcomed and appreciated. The reward for agreeing with the others is high. You build team spirit and a sense of security about a solution. The person who oppose the idea is a trouble maker and is wrong since everyone else seem to agree. The opposer easily become an outcast and can select between leaving the group, staying an outcast or applying group ideas.

So what happens with that scrum team, where all the developers are of the roughly the same age, have worked together for many years, have the same education, read the same blog posts and have built a system together? They tend to create inside the box ideas.

But of course this does not apply to just software developers. We have committees, steering group and management teams. I've earlier explained that when I'm evaluating a supplier, I look at the Hiring section to learn more about the company. I will from now on also look at the Board of Directors listing. If the members seem to have been casted in the same form, I guess diversity is not a high priority and conformity is valued higher than collective intelligence.

So, how will this affect me? I will actively seek steering groups which are diverse. Of course they should all have the qualifications but I've added a new qualification and that is to be as unsimilar to the others as possible. I will work with the developers to make them not only discuss ideas in their normal comfort groups but also discuss ideas with other developers. This is one of the great things about working with a big development department. There are lots of guys (and some gals too…) so you're not always stuck with the same setup all the time.

I will also try to read blog posts, books and articles by people who have the opposite viewpoint of my own. Why should I read something that I already think? Why not read something that opposes my ideas instead? I might change my mind.

And that is perhaps too many turn to group stupidity instead of the collective intelligence. The risk for changing your mind is too great.

Categories: Agile
Follow

Get every new post delivered to your Inbox.