Category Archives: Distributed Teams

Insight into what it takes to work in a distributed team.

Anecdotes for Project Managers: Cargo Cult

Another anecdote that is really working miracles is Richard Feynman’s story about Cargo Cult. I have to admit that I’m telling my own version. I’ve researched it on my own and massaged it a little bit to focus on the point I’m trying to make.

The situation where this anecdote works best is at milestone meetings, at larger companies: large companies have processes, even for project management. Project management processes typically focus on special milestones with special deliverables and a range of bored senior managers who have to take the decision.

The other day, I started one such meeting by telling the following story:
Continue reading Anecdotes for Project Managers: Cargo Cult


HDWKTWD – a User Story for Tasks

Have you ever experienced that a task has been agreed, and half-way through somebody comes back beaming with the statement “it’s done!”?

Every once in a while, this happens, and it happens more often in distributed teams than in localized ones. The point is: there was no real agreement about when the task is done. I’ve started a new experiment in my teams, I’m starting to add to every task a little “HDWKTWD” section.

What’s “HDWKTWD”? – It’s short for “How Do We Know That We’re Done”. A good task assignment already does that implicitly (compare “discuss the schedule for XYZ” to “agree on a schedule and inform everybody in an email.”), but sometimes it helps to be even more explicit ­čÖé

User stories deal with the user observable behavior of a system. Who says that this characterization of user stories should apply purely to programming? The trick is: If I’d make a movie – would an outsider be able to judge whether the goal has been reached or not?

In the example: “discuss the schedule”, everybody would be able to see that a discussion has happened – but that’s not the desired outcome. The desired outcome is an agreement. However, the agreement is not visible to an outsider until it’s documented in an email. Hence the re-worded HDWKTWD…

My first impression is that “user observable behavior” ‘s doing good for project management, too.


Anecdotes for Project Managers: Looking for the key

Lately, I started to realize that a lot of the project management I do has to do with anecdotes.

I like┬áusing anecdotes, it matches my mentality for managing projects, especially larger projects: I believe that problems should be solved as close to the actual work as possible, and I believe that I am in charge to help┬áthe teams to┬áleverage their own full potential. Anecdotes have proven a valuable means to unlock successes, like in the following example:┬áLately, I┬árealized that I’m using the following joke over and over again with different people:
Continue reading Anecdotes for Project Managers: Looking for the key


The importance of respect in the business of software

I found a reference to the article “Opinion: The unspoken truth about managing geeks“.

The reference is from Awasu’s “Anti-stupidity“. Thanks for drawing my attention to it!

Thanks to both your articles, I have nothing to add.

Hmmm… there’s always something to add, so how about this: The IT geniuses I’ve had the good fortune to meet all behave like that. But with IT becoming more of a profession and less of a vocation, I see first signs of IT pros turning “normal”. I don’t like it. Respect is – for all people involved – a better currency than credit.

I’ve been fiddling with the notion of trust, especially in distributed teams, for quite a while now, but respect is something that matters as much. I guess that – keeping honest respect in mind – even the quote “Unlike in many industries, the fight in most IT groups is in how to get things done, not how to avoid work. IT pros will self-organize, disrupt and subvert in the name of accomplishing work…” is not correct: I believe where mutual, honest respect is handled well, it will lead anybody to accomplishing their best and a little more. Which in turn tells us a bit about “most industries”.


Distributed Teams

Today, two blog posts collided with each other in my head:

Under the heading “Collaborating Across Boundaries“, Tessa Lau is contemplating which tools the computing community could offer to alleviate the challenges associated with distributed projects: It’s becoming harder and harder to cooperate – in my experience largely (though not exclusively) within the same company – with team members because people are chosen by expertise, never mind where they live.

On the same day, the social network XING reflects on this year’s nobel prize for economics: “XING und der Nobelpreis” (German :-/) explains that Oliver Williamson received the nobel prize this year for his work on transaction cost theory, the fact that the cost of conducting a transaction is one of the factors causing corporations to exist. I understood it like: Companies exist among others because they save transaction cost as compared to a same-sized community of freelancers. In a company, one doesn’t have to worry much about customers or suppliers, they are just there. As one might expect, there is a nice article at Wikipedia.

Social networks nowadays have a similar role for freelancers: They reduce transaction costs for individuals. That’s the link between XING and this year’s nobel prize.

Combining the two: geographic distribution imposes transaction costs that hit large cooperations about as much as individuals, but corporations are more rigid: while an individual could choose the second-best but geographically close specialist, a company has a certain department, say, in China. And if we are honest to ourselves: almost all of us are second best most of the time – is it really worth the effort? So, for knowledge workers: is geographic distribution a factor┬ácreating large companies, or is it rather┬áinhibiting large companies?

Could this be the dawn of a new age of small, regionally oriented IT companies?