Category Archives: Teamwork

Leading Tech Teams

Leading Tech Teams

Slides from my workshop at I T.A.K.E. Unconference 2014


Against ‘Experiment’ as a Social Hack

Large Hadron Collider
The Large Hadron Collider

The year is 2009. I am having a hard time convincing my team to adopt one week iterations. As I’ve since observed, this short iteration length unnerves some teams, who fear they won’t be able to hold the high pace necessary to deliver each week. But I really wanted us to be extreme programmers, and I had read (sic!) that xp-ers did one week iterations.

So, I’m in the middle of my sales pitch and I can’t seem to be convincing my team, when I remember a trick I had learned from an agile book. I asked my colleagues:

Let’s make an experiment and see what happens!

After uttering the magical word: “experiment” everybody relented. It was something they didn’t seem to be able to fight against. We went forward with the one week iteration and eventually decided it had indeed been a good choice.

But the true meaning of experiments is somewhat different. Wikipedia dixit:

An experiment is an orderly procedure carried out with the goal of verifying, falsifying, or establishing the validity of a hypothesis.

Get it? No hypothesis, no experiment. You need to state what you are trying to prove with the experiment (the hypothesis) and also the means of verification (the measures). This way, assumptions and biases become more obvious.

So in the example with my team, I could have said:

My hypothesis is that one week iterations will not negatively influence our ability to deliver. We will run 5 one week iterations and 5 two week iterations. We will measure time spent in meetings against total working time. We will measure total story points delivered against total story points planned. The percentages should be similar for one week and two weeks iterations.

Often times, the experiment proponent does have a hypothesis in mind but doesn’t articulate it. By articulating it, the team can engage in critical thinking about the hypothesis and the measurements, thus improving the experiment.

Other times, like in my case, the proponent uses the ‘experiment’ coat as a social hack meant to get acceptance for a proposal. Please don’t use it like this. You owe it to your team to fully bake your thoughts.

I know I have learned my lesson.


(Photo credit:

Telling it like it is

Migrated from Posterous.

Even though a blunt truth might be the quickest way to present an idea, it is not the best way to cause change.

This evening I read an essay called Tact Filters (via J.B. Rainsberger) that divides people, in a slightly simplified view of the world, into nerds and normal people. The difference being that while “normal” people tend to filter outgoing communication for potentially upsetting messages, but not the incoming one, nerds do it the opposite way — they censor incoming communication, but not outgoing. This would explain why us nerds are very blunt when stating ideas, but tend not to care much when being criticized, while the rest of the world would easily get offended by criticism, but at the same time refrain from inflicting it on someone else.

While I do agree that to an extent the dichotomy has some substance, since most developers I know are more direct and egotistical than people in other industries, I recently came to the conclusion that “telling it like it is” is detrimental to having a constructive discussion.

At my current employer, we changed team structure recently, so a lot of adjustments have to be made until we will gel together as a team. As Scrum Master, I consider one of my main responsibilities to be getting the team to respect the Scrum and XP rules during our first sprints, so that we would share a common process to improve later, as a result of our analysis.

I am constantly trying to determine if we are not respecting best practices (pair programming, refactoring, unit testing, frequent commits, limiting work in progress, developing the most important stories first etc.) and remind people that they should change in order to “get back on track”.

Needless to say, my constantly being a pain in the rear has led to numerous arguments while I was trying to make a point. Returning to the tact filters, analyzing my behavior in light of its terms (input vs. output filter), I realized that change was easier for everyone to accept if proposed in a tactful manner, that is when my output filter was on.

Of course, information is more easily provided without trying to camouflage it in a non-controversial format, but I found that a lot of minds shut down when you start a conversation with “You are doing X wrong, because it leads to Y”. Our minds simply freeze and we enter a defensive mode that prevents us from discussing the idea, but instead we try to justify our ways. The least resistance comes when discussions start in a conversational format, such as “How do you think Y will be affected by doing X?”, which lead to idea swapping.

Especially in our industry, where a lot of practices are based on small-scale observation or educated guessing, trying to nudge the team in a certain direction requires a lot of diplomacy and attention so that dialogues do not end up as monologues, and eventually as a complete waste of time.

To be effective communicators, we should “switch on” both our input and output filters.

We still need offices

Migrated from Posterous.

Seth Godin recently announced the demise of the office in an article on his blog.

Here are the reasons he suggests lead to the appearance of the office:

  1. That’s where the machines are.
  2. That’s where the items I need to work on are.
  3. The boss needs to keep tabs on my productivity.
  4. There are important meetings to go to.
  5. It’s a source of energy.
  6. The people I collaborate with all day are there.
  7. I need someplace to go.

One by one, he rebuts them:

  1. If you have a laptop, you probably have the machine already, in your house.
  2. If you do work with a keyboard and a mouse, the items you need to work on are on your laptop, not in the office.
  3. The boss can easily keep tabs on productivity digitally.
  4. How many meetings are important? If you didn’t go, what would happen?
  5. You can get energy from people other than those in the same company.
  6. Of the 100 people in your office, how many do you collaborate with daily?
  7. So go someplace. But it doesn’t have to be to your office.

The reasoning is sound for traditional waterfall. It would also be for agile development were it not for a small quirk in the logic. The point I’m talking about is number 6). What was the first value of the agile manifesto again? Individuals and interactions over processes and tools.

Since we started doing agile development at Syneto, this has been the most important source of improvement: people interacting, sharing and discussing ideas. I walk past people on their coffee breaks as they are discussing test smells, form label microcopy or process improvement and realize that “the agile way” promotes this kind of communication and involvement. The focus has shifted from individual success to team success, and I think face time is a crucial factor to this.

Now, before you start telling me that I live in the previous century and have not heard of virtual companies or online collaboration tools, let me assure you that I am aware of their existence. On the other hand, I think that information throughput and productivity is maximized with co-located teams. Here is why:

  • It’s the only way to easily do pair programming and not get frustrated by tools yet in their infancy.
  • Ad-hoc, informal meetings are easier to set up, which speeds things up. (If I call him for the fifth time via Skype, he’ll definitely get pissed.)
  • Trust can be built easier when seeing the other persons. (What was the name of that designer again?)
  • Commitments are stronger, so the chance of respecting them increases.
  • Teams get a stronger sense of a goal and higher purpose.
  • Common time zone means “live” access to the other persons.
  • Impediments are easier to spot and therefore more of them are removed.
  • Analog tools seem to enhance productivity (In a recent poll on the scrumdevelopment mailing list, 25% (the majority) of 200 voters indicated whiteboards, index cards and sticky notes as their preferred way of project tracking).

Granted, the virtual office has its own strengths (diminished costs, no need to commute and the ability to staff the team from a larger geographical pool), but all in all I think face time and inter-personal relationships (the beer after work) are crucial to a happy and successful team.