View low bandwidth version

Archive for December, 2009

What’s the difference between Open Spaces and BarCamps?

Tuesday, December 22nd, 2009

Having one foot in the world of IT and another in facilitation I keep getting asked

“What’s the difference between Open Spaces and BarCamps?”

Here’s how I described it to a good facilitator friend of mine (Julian from DecisionLab)…

“I suppose a BarCamp isn’t exactly like a pure Open Space. It’s got it’s own nuance.

For instance it’s generally not well regarded to plan BarCamps too far in advance. For no real reason in particular, it’s just not the BarCamp way.

People do prepare some stuff to take with them to a BarCamp knowing they will have an opportunity to talk about it – but they make no commitment until the day so they can change it or not give it at all.

Having people declare before hand makes it feel much more like a traditional conference and I think will discourage others from joining in on the spur of the moment.

One thing to remember about BarCamps, the big difference between BarCamps and Open Spaces is the ludic nature of BarCamps – they’re supposed to be fun and don’t have a particular outcome – they’re more like Popular Education rather than group decision making.

I think of it like this. Imagine you’re 11 years old and you and a gang of your friends are mad keen on technical lego. You’ve arranged one weekend to have a sleep-over with a lego theme. You’re parents have sorted out pizza and ice cream for everyone. Everybody brings lego with them and you take the half finished robot you’re working on. During the lego-fest the gang comes up with an idea – wouldn’t it be cool if we put all our lego together and see if we can make a bridge over the stair well.

THAT is a BarCamp. You might prepare something because it’s fun. But you’re just going along to learn, be inspired, get enthusiastic, hang out with some cool people and have a bit of a laugh.

The idea of getting people to coordinate their talks so they don’t have duplicates is I think wrong. You should have duplicates. If that’s what people want to talk about – duplicates give more opportunities for people to hear about it.”

Agile Development and Retrospectives: Learning from failure?

Friday, December 11th, 2009

I had an interesting chat with Alan last night about the role of “retrospectives” and it reminded me about the ICT4D Twitter Chat today around “Learning from Failure” being organised by the fine folks at Inveneo.

He was at the XPDay in London earlier this week – a 2-day hotbed of agile technology development geekery featuring a combination of traditional speaker sessions and open spaces.

Aptivate is a big advocate of using Agile methodologies. We see them as central to taking a participatory approach to international development. One thing we do after delivering a project is have a “debrief” or “retrospective” with the project stakeholders.

“Four key questions to focusing a community on learning and improvement” are described at www.retrospectives.com:

  1. What did we do well, that if we don’t discuss we might forget?
  2. What did we learn?
  3. What should we do differently next time?
  4. What still puzzles us?

Simple and sensible.

The key idea that Alan picked up on though was this: do a retrospective at the end of each iteration.

Every two weeks, every incremental release of a project, sit back, take an hour with your team and ask the above questions.

We’re certainly going to start doing this and from what was said at the XPDay – if you’re going to do one thing to improve your development process, do this.

Finally – ensure that all participants adhere to “Retrospective Prime Directive:”

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

Happy twitter chatting!

Translations, PDAs and Field Research

Wednesday, December 2nd, 2009

Translation can be a real headache.

PDA used for interviews in Tanzania

PDA used for interviews in Tanzania

Identifying text for translation, finding individual strings and phrases to avoid duplications, contextual exceptions, keeping track of them, revisions, collaborating remotely, reviewing, back-translating,  integrating translations back into a finished product – you name it, the translation workflow has got it.

But first, a bit of background:

Aptivate started working with Camfed about 2 years ago when they were planning a major baseline study of their work supporting women’s education and empowerment in Africa. As part of their broader monitoring and evaluation work they wanted to understand the impact of their programme on areas such as attitudes towards girls education, awareness of HIV and sexual health issues and the effectiveness of community structures.

We trained young women from rural areas in Tanzania, Zambia and Zimbabwe to use PDAs for face-to-face interviews with teachers, students, parents and officials in the education system.

We used Palm Tungsten E2 PDAs and Solar Bags from Voltaic to run the exercise. We customised and bug-fixed a version of the excellent Episurveyor for use in the education context (it was designed as a health tool).

The surveys that Camfed created for the study (50-60 questions for 6 different stakeholders, many common questions) were designed in English and had to be available in the following languages:

  • Swahili
  • Shona
  • Ndebele
  • Bemba
  • Lozi

The questionnaires were created in a spreadsheet – one sheet per stakeholder (e.g. parent, teacher) with a list of questions and optional responses on each sheet. We put together a tool in Excel to help with the translation process. Essentially it:

  1. Went around sheets indexing each cell with relevant text
  2. Built a single list of strings in a new sheet
  3. Presented only unique strings to a translator and locked the rest down
  4. Rebuilt the original surveys in the new language once the translation was completed
  5. Can repeat all the above to allow for back-translations too

This is a good example of the agile approach – do the simplest thing you can to get the job done well (and on a deadline!). The translations got done, we scripted the automatic translation of the EpiSurveyor survey files (which are XML objects) and that was, as they say, that.

Until I had a chat with Camfed yesterday and they asked – “you know that translation tool you made, can we use it for some other things we’re doing?”

Fantastic!

It’s great to have built a tool that starts to get useful beyond its original remit. The Excel tool we made isn’t suitable for general use yet and after using it for 2 years, there is plenty of scope for improvement around issues of collaboration and revision management.

Enter the internet.

I posted a question to MetaFilter yesterday on this subject and I got some really interesting responses I thought I’d share in case anybody is thinking of doing this kind of thing.

In particular, check out:

Happy translating!