It turns out that Uncle Bob had some more to say on the role of the foreman, and how it applies in various situations. However, I have totally different experiences.

The foreman team

Over the past two to three years, I observed a pattern while visiting various clients in Germany, and I sense there is a correlation to what Uncle Bob is actually saying. Time and again, I see teams separating themselves from their peers. I see craftsmanship elite teams forming that put craftsmanship on their flag, rise it high – and dramatically fail to address the business needs underlying any software project.

More often than not these craftsmanship elite teams separate themselves at the core of the application, intending to create the best software they ever can. What teams outside that ideal bubble of crafts-fore-men get is that they are writing crappy code, but the world will be safe as long as that elite team continues to control all the commits to the main branch.

Sorry, I am exaggerating a tiny bit here. Just a tiny bit, unfortunately. These elite teams set themselves off to produce the best code that was created ever at this company – heck, ever in the whole damn universe.

This situation is so broken on so many levels.

First off, if you encapsulate yourself in your own little bubble, you are not teaching your peers – clearly a value that we set out five years ago when we discussed the contents of the craftsmanship manifesto, and the underlying ethics.

That sort of situation is also not very helpful for the larger community. It gives rise to a two-class organization. Either you are with or against us. Surely a driver for conflict, and Uncle Bob’s recent explanation carries along that this is what he intends to do.

A false dichotomy

Unfortunately, Uncle Bob is drawing a false dichotomy. Uncle Bob distinguishes between two extremes. On one hand, you have the perfect agile team that consists only of alpha-animal-like foremen that have a shared value system. On the other hand we have the open source model where a master committer appoints valuable contributors the right to also commit directly, and supervise the work of others.

This is a false dichotomy. There are many, many more levels of collaboration in between. There are many, many more levels of collaboration besides that. For example consider a quite senior programmer that is joining your team, but doesn’t know the code base. Would you grant him the commit rights from day one? Day ten? After ten successful commits?

Clearly, we can’t answer that question without more context. That context is crucial for deciding whether that new guy is actually sharing our value system, or parts of of it, or maybe just one of it. It’s hard to tell, isn’t it?

There are many more factors involved than meets the eye. There are more factors in play that don’t have anything to do with foremen at all, for example personal safety. These factors contribute largely to how productive and effective your team is. I worked on a team where we delivered nothing because the team hygiene wasn’t right. Overcoming that factor lead us to delivering twice the amount that we planned – for three sprints straight. Coincidence? I don’t think so.

A logical fallacy

Now, with all this said, here is the logical fallacy underlying Uncle Bob’s reasoning. He explains that someone might feel attracted to his classes. Then those folks join his classes, and ask him questions like “how can I convince my team mates?” Uncle Bob says that you can’t – I think you can, but it will take time.

The logical fallacy though, is this: Who is making you a foreman? Who is going to make you a natural leader that others want to follow?

Think about it. If you ask questions like “how do I convince my colleagues back at work?” you probably are not a natural leader. Otherwise your colleagues would follow you. Uncle Bob suggests to put those guys in the role of the foreman. But who would be doing that? Can you do it yourself?

I think this leads to elite thinking. “We are the elite. Please take a step aside if you’re not willing to join us.” On one hand, this might be good, since work might get done, and we will end up with better code than before. It resonates to some extent with me, since it sort of replicated the role of the ProductOwner for the code.

Still, it’s wrong. it’s wrong since you can’t lead without people following you. For that to happen you have to convince your colleagues for example by leading by example. That’s one way to do that.

I don’t know what Uncle Bob’s ultimate goal is with this rule and role. I am suspicious that it will in the end lead to sorting out capable from non-capable programmers and team members. I think it would be more helpful to engage in more proactive teaching with the ones that need it, and create a system that makes you aware when something is wrong. But maybe that’s just a cultural bias from my side.