Europython: distributed companies and agility+customers¶

Steve Alexander - Managing the launchpad team at Canonical

People at canonical normally work from their homes. Most communication is via phone or IRC. In total, Canonical has employees in about 20 countries. With a total timezone difference of 16 hours (launchpad), a meeting when everybody is awake is hard.

Communication uses phone, irc, screen/vnc, wiki, launchpad, specifications, code review, design review, jabber, email, bug triage, activity reports, weblogs.

The ubuntu team has (have?) a weekly meeting with a very strict format: they just go through everybody's progress and people get a chance to say at which they're blocked (waiting for someone else to complete something). This gives the team the change to de-block them and get them productive again.

The Launchpad weekly meetings are strictly 45 minutes. They always start on time and ends on time. This is the only way to get buy-in from people who have to get up real early or have to stay up late (remember, 16 hour timezone difference!). And they have a couple of standard agenda items.

At the end of the meeting people are allowed to say what to keep/bag/change. Keep short meetings, for instance. Change the standard agenda. Whatever.

Items must be dealt with switfly and decisively. You either fix it now or assign it to the responsible people and to a deliverable.

One of the ways to keep the IRC meeting moving is to prepare text beforehand. If you know you want to say something, make sure you can paste the sentences in one go. If you ask something ("next meeting on monday?") do a countdown 7 6 5... to force people to say it if they disagree. If you do a poll ("who upgraded to the latest version of xxxx?"), everybody has to answer done/not done. So he explicitly says "everybody answer done/not done" in irc.

Every day they send a timelog to a mailinglist. Most use gtimelog for that.

Q: How does it compare to an on-location team? Steve: I'd choose the on-location team all the time. It's so much easier.

Q: Why did you start it as a distributed company, then? Steve: Otherwise we couldn't get the people. You just can't get them all to move to one location. They hired people that worked on debian in their free time and offered them to work on it for pay: you couldn't get them to move.

Lene Wagner - Managing a distributed company

Lene manages merlinux together with Holger Krekel with 8 employees spread out in Germany and Europe.

There is a difference beteen a company context and an open source context. The common aspect is that a bunch of skilled people work on software. The difference is that there are more commitments: money, customers, etc.

Distributed versus non-distributed company. Common: commercial activity, customers, commitments and formal requirements. Distinctions are that there's no face-to-face communication ant there's a less fixed working hours requirement and so.

They asked their employees to fix a major part of their availability during the week so that they can rely on getting an amount of work done.

They also have regular sync meetings on IRC (nicked from canonical). They do it in 30 minutes. They have invitations and formal minutes. Identifying blockers and dependencies is an important part. Update on product status and feedback and so.

They're experimenting with one-week merlinux sprints, they did it twice till now. Of course they also participate in project-specific sprints and conferences. On the one-week-sprints they try to concentrate longer discussions about company practices and goals. Also giving feedback and having fun are parts of the sprints.

Central to their company is the issue tracker. Issues are assigned to specific persons. It is for both development and non-development issues. The person responsible is really responsible: for keeping track, for a result, for triggering/involving other persons and for reporting blockers and failures.

Tracking and controlling is done by means of an svn repository. Both code and company data. There are email notifications of each and every change to stay on top of all the developments. They make sure that everybody is subscribed to the commit lists that are relative to him/her.

Everybody has to watch his use of communication channels. Do I say this in IRC or in an email? If I send an email, am I not spamming too many people? Email is written documentation, which gives it weight. So if you say on IRC that you'll take over something: also send an email.

The formality level of the company changes per project. Some EU projects need fixed employees, other projects allow freelancers. EU projects also require more paperwork and thus more formality on the company's side. So they're agile with the formality level.

Social: there is less socialising, so if someone is stuck or not motivated or so, he has to explicitly request help/feedback. There's also no discipline from a formal worktime/office structure, but this also means that people can adapt their workstyle to personal situations (bringing kids to school, for instance).

Pro's of a distributed company:

• People appreciate working from where they want.
• Low barrier for good people to join the company.
• Connects very well to open source contexts.

Con's of a distributed company:

• A lot of formal considerations.
• Communication overhead, risk of misunderstandings.
• More difficult commitment organisation, it is harder to keep track of what gets (not) done and when it gets/got done.

Aiste Kesminaite - Agile customer management

Tools and processes on the customer's side will change, but people will mostly stay the same. If the people change, for instance because a central figure at your customer gets a new job, beware.

When talking with a customer, try to find a way to get the rationale from the customer, the real reason why they want something. One way is to give them an activity during which you can get them to talk about what they want. For instance writing stories (from eXtreme Programming). Some customers are scared of that because they think that all their normal procedures are going to fall down around their ears. Basic rule: be there and listen to them talk.

Documentation: customers don't read it, it just makes them feel better just because they have something visible on their bookshelves.

It is important to become a team: you and the customer. Get your customer to trust you. It must be you and the customer versus the problem, not you versus the customer.

Customers tell you to follow the plan, but what they really want is for you to follow the plan that is in their heads, not the one that's on paper. So you have to be flexible and respond to change and

Issue tracking is a sensitive issue. If it works it is great. They had a problem with a customer that just couldn't put the issues in a coherent form into the issue tracker. They lumb together multiple issues instead of splitting them out. In those cases they just collect all the user emails and turn them into issues themselves.

Agile mothodologies are great when they work. Don't try to apply everything all at once. Start small and teach the client along the way.