Raise the bar

Last week I had a conversation on T-shaped people with a client. Since the Agile Testing Days 2012 I wanted to write a blog entry on the topic and he filled some more gaps in my head. So now the time has come.

Whenever I heard about x-functional teams, I was told that it's best to have T-shaped people. The teams should be autonomous and so have to cover all the skills and knowledge needed to fulfill their quest. But if you have only specialists on your team who don't know much about what lies right or left of their way, you don't have a team. Then you just have a group of people who cannot work together but happen to work on the same project. To foster teamwork you need people whose knowledge covers at least partly what others know. Then they have the possibility to help each other out and to work together instead of working only side-by-side.

The argumentation for knowledge transfer and doubling which I recon is used most of all is working against the so-called truckfactor or lotteryfactor: If one teammember happens to be run over by a truck or wins the lottery and so quits to live on a desert island, then how is the chance that the team will fail? If the probability is near 100% the teammember is a knowledge silo. You will find them easily by seeing what happens when they go on vacation. If you hear something like "we can't do that now. We need to wait till Ben is back from vacation" or "we need to fix that yesterday. Call Mark out of his vacation" or "I've been on vacation for three weeks but this pile of work waiting for me just ruins my relaxation", you may listen to a conversation about a knowledge silo.

Clients react very similarly to this. Most of them fear much overhead. If everyone needs to know everything, they waste a lot of time learning. But that is not what I suggest. Not everybody has to know everything. Everything must be known by more than one. And I personally like the idea that everyone knows more than only one thing.

When I spoke to my customer last week he had two objections. One objection is a model I come to later on. The second is that, if there are more than one to know something, they always have to keep up with each other. I actually don't think so under certain circumstances. I don't think that two people working on the same code for example have to know everything about what the other does.

I worked on teams with six members on average who didn't specialize to certain parts of the code and who didn't have to know everything about all the others' work. What you will need is discipline and patterns. As so often in Agile Software Development discipline is the key. The team members have to write understandable code. If they don't, they will have this kind of friction. If they do, they're very likely to understand the code easily even if they didn't write it. Patterns help a lot with this! If they write code with the help of patterns the only friction will be high-level coordination which doesn't need to cost very much.

The second objection was related to his model of learning and knowledge. Instead of using T-shapes to explain, he used curves like Gauß's (although my drawing may not seem so):

He reconed that the areas below the different curves are the same for different people. I definetely disagree. If you have people like a certain colleague of mine who spends at least half of his free time to learn more, his area below his curve will be very much bigger than the one of someone who works 9 to 5.

Even if you don't believe the areas are equally sized, they get thinner the higher they are. Or otherwise: The more you concentrate on the depth of knowledge there is a trade-off in knowledge range. I don't think that you necessarly forget as much as you learn, when you concentrate on depth. But the more you specialize on one thing, the thinner gets your knowledge of what lies left and right of that specialization.

When I became aware of that effect, I immediately thought about the depth of knowledge. Is it really necessary to have specialists with a great depth of things? Or do we need more width instead? What is deep/good enough? When I see my teams, I realize that they benefit more from width than depth. Every time I see highly specialized people, they are seldom supposed to do anything else. And nobody else should do the same as them as it would take more time. Welcome, knowledge silo. Goodbye teamwork.

And now back to the T-shaped people. Markus Gärtner was saying at the Agile Testing Days, that he doesn't want to be T-shaped, π-shaped or m-shaped. He wants to be circular-shaped. I assume that he wants to have deep knowledge of more than one or two specialties. Another colleague doubts that it is a good sign to specialize in too many fields. He has a kanban-mindset and compares the situation to having lots and lots of expedite-tickets in your system. That doesn't seem very healthy.

My own thoughts are, that I want to have a few fields where I know more than most of the people. When you read my blog, you will see kanban- and testing-related topics, for example. But I don't want to stay behind in all the other knowledge. To work together with more people, I want to raise the bar. I want to thicken my overall-knowledge, the horizontal bar of my T (or π). That gives me the possibility to give and get help, to understand and to learn.

What about you? Are you a knowledge silo or do you want to raise the bar to foster teamwork?