There is one very simple rule to make distributed projects work – or fail:
Do what you say, say what you do.
Category Archives: Distributed Teams
Insight into what it takes to work in a distributed team.
The secret weapon for distributed teams
There is a simple pattern that can be used to spot and solve one of the most unnverving communications problems in teams, distributed or otherwise. Once you know the problem, there’s a simple recipe for a solution.
The mojo of virtual teams
Virtual teams are around for ~20 years now. Still, they are far from universally mastered. Here is a first clue about what it takes to make them work.
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?