How to make apps that help Europe-bound Syrian refugees

Syrian refugees are the most tech-savvy migrants in history and developers are creating apps to help them – but high-tech solutions aren’t always best

Finding their way

Finding their way – IAKOVOS HATZISTAVROU/AFP/Getty Images

TEXTING. That’s the innovative idea that took home the top prize at a hackathon to help refugees in Paris, France, last month.

The service, conceived after a weekend brainstorming at coding school Le Wagon, would send people on the move alerts in different languages about medical and legal aid, or how to find jobs in their new home. The project has reportedly been picked up by several French non-profits, including Action Emploi Réfugiés.

Such a low-tech solution may seem odd given that many of those leaving Syria have made the dangerous journey to Europe with a smartphone in hand – navigating the route to Germany via GPS, for example, or sharing tips on social media. But as well-meaning developers and aid agencies are finding, how people use technology is as important as the tech they carry with them – and what works best may not be what we expect.

“This is the first really big population movement of people who are technologically savvy,” says Jeff Wishnie, senior director of program technology at Mercy Corps. That has led to aid agencies coming up with new ways to help.

The Paris hackathon was hosted by Techfugees, an organisation set up to find ways for the tech community to assist refugees. Since kicking off in September, Techfugees has supported events in cities around the world, including London, New York, Oslo, Venice, Belgrade and Warsaw. It has given rise to a range of ideas for online services: CHIN, an app for locals to connect with refugees in need; special versions of services like LinkedIn and Airbnb; an app to figure out the direction of Mecca; and Refugees on Rails, a service that aims to give refugees an edge in the job market by teaching them to code.

Techfugees isn’t the only source of such services. Others are being developed independently, such as Gherbetna, an app providing information about settling in Turkey, and Kiron University, a Berlin effort to offer refugees free online college education.

While the intentions behind all these services are good, are they what refugees need? “There’s a lot of people in the tech volunteer movement building apps,” says Wishnie. “One thing nobody is doing is installing them.”

Some of those developing apps are rushing in without taking the time to understand the problems they want to address, says Richard Dent of the University of Cambridge, who heads the Refugee Futures Initiative, a newly formed partnership between several European universities. “If anyone is hoping that technology and data can offer a quick fix, then I’m sorry, but from my perspective that would be a bit too reckless,” he says.

Megan Price, executive director of the Human Rights Data Analysis Group in San Francisco, agrees. When people pitch her technological solutions to human rights problems, she wants to hear if they plan to study the issue before jumping in and trying to solve it. “If they don’t offer up that disclaimer early on, I get really sceptical,” she says.

The biggest problem is an assumption that everyone else uses smartphones in the same way as those developing the apps. But that isn’t the case. For example, access to the internet isn’t always reliable when travelling, so services that don’t work offline aren’t very useful to refugees. And some refugees carry feature phones – a more basic version of a smartphone – which if not taken into account could mean the service isn’t accessible to everyone. Making services available in multiple languages – Arabic, Farsi, Pashto and so on – is also important.

So Wishnie and his team have surveyed refugees to better understand how they use technology. They found a stark difference between refugees and Westerners. Westerners tend to think of their phones as portals to the internet, but refugees used “phones as phones”, he says – they mostly wanted to stay in touch with people they knew. “What we found is that people are in such a state of panic that they aren’t doing much else,” he says.

WhatsApp, the mobile messaging app, is most popular, followed by similar services like Viber and Facebook Messenger. One exception to the trend was MAPS.ME, an app that lets you download maps to look at offline.

“No one we talked to was using web search. Very few people we talked to used Facebook groups for information,” he says.

A separate study by a team at Pennsylvania State University, conducted at the Zaatari refugee camp in Jordan, underscored the popularity of instant messaging services. People of all ages ranked it as the internet-based activity they were most interested in. When asked what they would like to do if better internet access were available, many said they would like to use those apps more.

Wishnie’s findings shaped how his team approached their own effort to build an online resource. Their website,, provides information about things like housing, medical services, family reunification and local rules regarding asylum.

At first, they thought about advertising the site through targeted Facebook or Google ads. When they realised refugees were unlikely to come across the ads, they instead simply made the site the default homepage for all their free Wi-Fi networks – making their online resource hard to miss.

But making services that refugees will actually be able to use isn’t the only concern. Dent points out that some of the apps collect data from refugees. “If you look at a few of them, the terms and conditions are no different than Facebook in terms of monetising the data,” he says.

Last year, Dent signed an open letter affirming ethical principles for research in big data, along with researchers from Goethe University Frankfurt in Germany, the University of Groningen in the Netherlands and elsewhere. He hopes the wider tech community – not least those making apps for refugees – will embrace such values.

The sentiment is shared by Price. “Especially with refugees, there are a lot of hard questions about how we keep this data secure and how we make sure it’s used for good purposes,” she says.

However, the initiatives that are proving most effective on the ground may sidestep these concerns. A team from Google recently visited Wishnie on the Greek island of Lesbos to pitch some potential projects. Wishnie was sceptical, until he heard their idea. They wanted to print stickers, he says. Local shops could use them to advertise free Wi-Fi or power cables – with a link to at the bottom.

Wishnie was delighted that the tech giant seemed to get it. “You need to tailor your work to refugees’ needs, not what’s cool and fun.”

Counting casualties

How many people have been killed in the Syrian crisis? That question was first put to Megan Price at the Human Rights Data Analysis Group in San Francisco in 2012 by the UN Office of the High Commissioner for Human Rights.

“It seems like a straightforward question,” says Price. “It’s certainly the fundamental starting point when you’re thinking about a conflict. Yet it is very difficult to answer.”

Seven different organisations – from the Center for Documentation of Violations in Syria to the Syria Shuhada – had gathered data sets. But it wasn’t as simple as adding all the names together. Some databases recorded the same people, but one might include a middle name where the others didn’t, or spelled a name incorrectly. And only some of the databases included gender, age, occupation and location of death.

So Price’s team built a machine-learning algorithm to spot such inconsistencies and used this to provide revised figures to the UN. Their first report in 2013 identified 59,648 deceased individuals, fewer than the 147,349 recorded across the separate databases. In 2014, that had risen to 191,369; the databases recorded 318,910.

These numbers are an important step in getting a clearer picture of what’s happening in Syria and the UN says it will use them in future investigations. Still, they should be treated as a lower bound, says Price. “There are always going to be victims whose names we don’t know.”

This article appeared in print under the headline “Phoning in refugee aid”

Reprinted with permission from New Scientist, issue 3069 published 16 April 2016


Posted in Uncategorized

How to train your Agile

Modern Scrum is a certification-laden minefield of detailed practises and roles. To legitimately describe oneself as a Scrum Master or Product Owner involves an expensive two day certification class taught by someone who in turn took an eye-wateringly expensive Scrum Trainer class, from one of the competing factions of “Professional” or “Certified” (but ironically not both) schools of Scrum training. But it was not always so.

What led to the plethora of practises, religion and superstition that surrounds modern “agile” methods? What follows is an amalgam of what may have happened. It is the result of my conversations with a number of early agile practitioners along with my own experiences as both an in-house and contract developer during the 1990s. It is, as they say, “based on real events”.

A long time ago…

The earliest agile projects, or at least those projects whose participants would later describe them as agile, started with a single constraint:

We will deliver something, fully-functional, into production, in 12 weeks. What’s more, we won’t just fly blind for that time, we will sprint to halfway, pause, course-correct, then sprint to the finish.

So the first sprints were six weeks long. One sprint, pause, another sprint, release what we have. Nowadays this seems like an insane amount of time to run without checking in with the plan. Six weeks without even a showcase? That’s irresponsible! Back then, in the early 1990s, it was considered equally insane but in the other direction. Six weeks? You can’t possibly do anything meaningful in six weeks! This was in an era when 18 months between releases was pushing the envelope, and a multi-year software project on a monster Gantt chart, with a single release at the end after many months of integration and further months of testing, were the norm in large organisations.

Breaking the model

Chris Matts, product and portfolio management consultant and father of Real Options, uses the term “breaking the model” for introducing a constraint that exposes inadequacies in the status quo. “I’m sure we could improve this system of work, so how could we break the model?”

If you ask a team to target 16 months instead of 18 months for the release, they will try to do whatever they do now but harder. They might start working longer hours or occasional weekends, cutting corners here and there, squeezing a few percent more out of their practises at the expense of their health or sanity. When you introduce a constraint of a 12 week release with a showcase halfway through, they have to radically rethink their approach. They expect a feature to take months to analyse, design, code and test. All these activities are specialised and we batch them up, so we do all the analysis and then start on all the design. Frameworks like RUP blurred the boundaries, so “construction” was supposed to start while “elaboration” was still ongoing, but the all-or-nothing thinking was still steeped in its civil engineering roots and RUP was distorted into another heavy gated process.

New tricks for old dogs

Waiting for the analysts to finish all the analysis and the architects and senior programmers to finish the high-level design and functional specifications clearly wasn’t going to work. “12 weeks? This is crazy!” People assembled themselves into cross-functional teams that could autonomously analyse, design, code and test a single feature. The features themselves were sliced into work bundles that could be reasonably achieved in six weeks with some kind of business outcome at the end. Monthly status meetings weren’t going to cut it in a six week “sprint” so they started meeting more frequently. Weekly at first, and then daily as they realised how much they could drift in a week. “Six weeks? This is nuts!”

These people had never had to collaborate with the other disciplines before. Requirements were handed from analyst to technical architect in a formal ceremony involving the shedding of blood and the summoning of the Governors. Similar ceremony surrounded the hand-off of detailed functional specification from architect to humble programmer, and so on down the line. There was suspicion, mistrust, but mostly ignorance of the other roles.

A little help from our friends

The mavericks who had suggested the 12 week release found themselves in a coaching role, helping the people work together as a team, identifying and removing impediments, making suggestions as the team organised itself around this new way of working. If the daily huddle was like a rugby Scrum, then this person was the Master of the Scrum.

Similarly, most of the team had never thought about the end users of the systems they were building. The programmers were too busy converting the functional specifications in their in-tray into code modules in their out-tray, the testers were too focused on working through the test specifications and keeping to the testing schedule, and so on. So another role emerged, owning the holistic view of the software product, a Product Owner if you will. This person would help the team members understand how their work contributed to the product as a whole, and how this product would deliver value to the wider business. This meant the team could make trade-offs of options for the technical solution, prioritise which features made sense to deliver first, and which ones went together.

The first release wasn’t an impressive affair, but it was a release, and it contained actual working features. And the team was hooked! They had transformed a business need into a set of features that met that need in less time than they used to spend writing the requirements document! No wonder they started calling themselves “hyper-performing”. Nowadays we might think of a six week sprint or only releasing once per season as primitive, but back then it was truly game-changing. And then a funny thing happened.

The start of a religion

There are two ways a community defines itself. A centred community forms around a set of values or ideals. You can be closer or further from the centre but there is no sense of “exclusion”. A bounded community defines itself by boundary markers. These may be specific words they use, clothing they wear, ceremonies they carry out or foods they eat or avoid. Adherence to these boundary markers determines whether you are inside or outside the community.

Bounded communities tend to obsess about the boundary markers and can lose sight of the original values and goals of the community. It is easy to attach a political agenda to the boundaries, which is when religious or tribal factions emerge, then they use the boundaries to justify censure or even violence. More extreme factions adopt more extreme boundary markers, and any violation of this increasingly involved code is denounced as heresy. This is also an effective way to grow the community. Membership of the community is seen as desirable, or in extreme cases as necessary for survival. “Swear allegiance to us or die, heretic!”

Bringing this back to software methodology, one of the most effective boundary markers is certification. You either have a certificate or you don’t. You are one of us or you are not. Once the tribe grows large enough, certification is seen as a valuable end in itself. The more certified professionals we have, the more capable we are, surely? The lucrative nature of providing certification means the certifying body are happy to reinforce this belief.

The what without the why

Boundary markers often start out as good advice that a community adopts. Eating pork or shellfish in the Middle East in biblical times was a fairly risky thing to do! And draining the blood from an animal before eating it–a trait common to Jewish and Muslim faiths–would have been a good way to remove most of the dangerous bacteria in an age when people knew little about food hygiene or health.

Checking in with the team every day makes sense to keep on track, and having a short list of upcoming work means everyone can see what the latest priorities are. But these good ideas have morphed into rigid structures and ceremonies.

These days Scrum has become the dominant agile method. For anyone who has been in the industry less than 15 years, “Agile” has always existed, and mostly as some variant of Scrum. Teams made up of testers, analysts and developers are normal in many companies, and most people have a decent idea of what they are building, why and for whom. Having a Scrum Master in this context is anomalous, as is the idea of a Product Owner, so we find ourselves in a situation where the tail starts to wag the dog.

A team with a Product Owner absolves itself of responsibility for product prioritisation decisions because the Product Owner does all that. The Scrum Master takes on more of a traditional project manager role, tracking and reporting progress, and cajoling the team to go just a bit faster, try just a bit harder, as though they wouldn’t think to do that on their own.

That doesn’t mean we don’t need coaching, or we don’t need product prioritisation. Product ownership is a team activity, in the same way code ownership is a team activity. If the entire team doesn’t have a sense of ownership of the product and its purpose, how can they be genuinely self-organising around that purpose? Having a product specialist to coach the team is as valuable as having a testing specialist to coach the team in testing. The failure mode is to absolve responsibility onto that specialist, which systemically depletes the team’s capability in that area.

Inspect and adapt

The original motto of Scrum was “inspect and adapt”. These days I see little inspecting and adapting and much blind adherence to process. Maybe it is time to cast a critical eye over each of your “agile” practises and ask yourself a few questions:

What is the intent of this practise? What should it give us? Is the way we are practising it giving us that outcome? How else could we get that outcome in this team, in this context? Is it even relevant to us?

Once you start asking these questions you will see your process through a different lens. Now you can inspect and adapt. Now you can start to train your Agile.

Tagged with: , , ,
Posted in Uncategorized

Agile Education Workshop for Schools

This year will see the début of an educational workshop introducing the next generation of young people to agile practices. School students, Agile educators, and teachers will come together to take part in this hands-on digital skills workshop.

Over 3 days, 120 school students from across Scotland will travel to the conference to take part. The workshop is created in partnership with Digital World.


During the 90 minute sessions, young people will be introduced to agile methods and practices in a fast, fun, and sociable setting. Working in teams they’ll solve problems, and gain an insight into non-technical aspects of software development.

In the workshop, students will work together to decrypt a secret message using BBC micro:bits. Only by working in an agile way will they be able to to crack the code in time! They’ll reflect on their work, as well as suggesting ways to improve their processes before the next iteration.


There has been a fantastic response from schools across Scotland. Over 100 groups registered interest and all workshop slots are now fully booked. However, for those who aren’t attending, all the learning materials (including notes, slides, lesson plans) will be shared online after the event.

It’s hoped that this new approach to introducing students and their teachers to agile techniques will result in a better understanding of modern software development practices. Also, it will emphasise the importance of the softer, non-technical, skills needed for working in the digital industry.

(Photo credit: Claire Quigley, CoderDojo Scotland)


Posted in Uncategorized

The Programmers Oath

I wrote this blog some months back.  I’ve been thinking about it a lot since then.  It’s also the topic of the latest episodes of my Clean Code video series at

Posted in Uncategorized

On Thinking

by Rebecca Wirfs-Brock

Daniel Kahneman, in Thinking Fast and Slow, introduces two “systems” of thinking: fast or type 1, and slow or type 2.  We don’t actually have two different parts to our brains—but we do have two distinct types of thinking mechanisms, each with their respective strengths and drawbacks.

Fast thinking happens automatically with little or no effort or sense of voluntary control.  Quick, what’s your first reaction to this photo?

My immediate visceral reaction: “That dog is ugly! It looks crazed, angry…. scary.”

The dog is Peanut, winner of the 2014 Ugliest Dog contest. His wild hair, bulging eyes and protruding teeth are at odds with his sweet personality. Holly Chandler of Greenville, North Carolina, Peanut’s owner says he was seriously burned as a puppy, resulting in bald patches all over his body. Peanut is healthy now and nothing like my first impression.

In a nutshell, fast thinking is automatic (we do not have to work at it), impulsive (we can’t easily control it) and emotional (once I’ve told you a little about Peanut you probably feel sorry and sad and more positive towards Peanut, despite your initial reaction). Fast thinking draws on our amazing abilities to quickly form associations between related things. When it works well, we easily come to conclusions, draw out inferences, and confidently decide without breaking a sweat.
It’s sweet when your associative memory clicks along in high gear providing ready answers. But fast thinking can be subtly and easily biased. The variety of cognitive biases we have is astonishing.

In contrast, slow or system 2 type thinking requires energy. We get tired when we do a lot of slow thinking. We use slow thinking to reason logically, compute, or, surprisingly, when paying attention to someone speaking to us in a crowded noisy room. Both writing code and writing prose are slow thinking tasks for me. Reasoning about the cause of a bug is too. The fast cycles of strict TDD help some with breaking up the necessary slow thinking into more manageable chunks. For me, deciding what the test should be and how to implement my design ideas are almost always slow thinking tasks. Writing code may or may not be, depending on how familiar I am with the programming language, tool set and design context.
It is too simplistic to say that our brains are wired to be either emotional or logical. We don’t always get to choose which form of thinking we use. Even more interesting is how the two systems interact. Our system 2 constantly monitors our system 1 thoughts, and kicks in when it notices an inconsistency, saying, “Hmm…that doesn’t seem right,” perhaps leading to some conscious system 2 thinking and problem solving.

But as this two-star Amazon reviewer observes, Kahneman’s book doesn’t contain easy-to-digest pop psychology advice for how to be a better thinking being:

“Peace to all…The idea of system 1 and 2 for the brain was the twist. (System 1 is impulsive autopilot, system 2 reflective and analysis oriented)
Other than that, the book is filled with too many experiments that i felt didnt add practical value to me. I was hoping for practical solutions to help make those two systems work together in harmony…the book did NOT deliver that which was disappointing.”

Kahnman won’t fill you with sound-bite sized advice on how to sharpen your thinking. So what can you do now that you are aware of how you think? Are there ways to counteract the bad things about these systems and amplify the good things? I think so.

Since reading Kahnman, I’ve observed how my environment affects my thinking and how my thinking demands shift from task to task. Sometimes fast thinking trips me up because what I assumed made it difficult for me to really see things as they were. I keep working to counteract cognitive biases of my own and those I work with. I’ve become more aware when others don’t react as I expect or aren’t making “logical” decisions. I’ve become more understanding and less impatient.

I am experimenting with ways to support and enhance system 2 thinking in others and myself. I find that I need to carve out a space where I can work without distraction and have enough time to get deeply engaged in a challenging system 2 type task. I am easily distracted by noise or visual stimulation. I also find the Pomodoro technique doesn’t help me get more work done. I don’t have a problem with focus. My problem is knowing when to take a break. And I don’t easily get back on task after a 5 minute break.

Your experience no doubt varies. Our brains don’t work the same way. Let’s continue exploring how our daily work practices enhance our thinking and where we need to take extra care and pay more attention.

Posted in Uncategorized

Introducing Example Mapping

Before you pull a user story into development, it’s crucial to have a conversation to clarify and confirm the acceptance criteria.

Some people do this during their backlog refinement or planning poker sessions. Other teams have a specific three amigosmeeting, specification workshop or discovery workshop.

Whatever you call this conversation, many teams find it hard; it’s unstructured, it takes too long and gets boring. The result is they don’t do it regularly or consistently, or maybe they just give up on it entirely.

I’ve discovered a simple, low-tech method for making this conversation short and powerfully productive. I call it Example Mapping.

How it works

Concrete examples are a tremendous way to help us explore the problem domain, and they make a great basis for our acceptance tests. But as we discuss these examples, there are other things coming out in the conversation that deserve to be captured too:

  • rules that summarise a bunch of examples, or express other agreed constraints about the scope of the story.
  • questions about scenarios where nobody in the conversations knows what the right outcome is. Or assumptions we’re making in order to progress.
  • new user stories we discovered or sliced and deferred out of scope.

Example Mapping uses a pack of 4-coloured index cards and some pens to capture these different types of information as the conversation unfolds. As we talk, we capture them on index cards, and arrange them in a map:

We start by writing the story under discussion on a yellow card and placing it at the top of the table.

Next we write each of the acceptance criteria, or rules that we already know, on a blue card and placing those across the table beneath the yellow story card.

For each rule, we may need one or more examples to illustrate it. We write those on a green card and place them under the relevant rule.

As we discuss these examples, we may uncover questions that nobody in the room can answer. We capture those on a redcard and move on with the conversation.

We keep going until the group is satisfied that the scope of the story is clear, or we run out of time.

And that’s it. I told you it was simple!

Instant Feedback

As the conversation flows, we quickly build up a visual representation on the table in front of us reflecting back our current understanding of the story:

  • A table covered in red (question) cards tells us that we still have a lot to learn about this story.
  • A table covered in blue (rule) cards tells us that this story is big and complicated. Perhaps we can slice it? Take another yellow (story) card and put the sliced story on the backlog.
  • A rule with many examples might be over-complex. Are there multiple rules at play that need to be teased apart?

You’ll find that some rules are so obvious you don’t need examples at all. It’s clear from the conversation that everyone understands the rule. Great! You can all move on with your lives without forcing yourselves to grind out examples like BDD-brainwashed automatons.

Thinking inside the time-box

A small group of amigos should be able to map out a well-understood, well-sized story in about 25 minutes.

If you can’t, either you’re still getting the hang of this (which is fine), the story is too big (definitely not fine), or it still has too much uncertainty in it. Listen to that, and either try and slice the story, or let the product person go off and do some homework before you put story back into another example mapping session at a later date.

At Cucumber, we use a quick thumb-vote after 25 minutes to determine whether we think the story is ready to pull into development. Even if there are some questions remaining, you might think they’re minor enough that you can resolve them as you go. Let the group decide.


Example Mapping helps you zoom in and focus on the smallest pieces of behaviour inside your story. By mapping it out you can tease apart the rules, find the core of the behaviour you want, and defer the rest until later. With this level of scrutiny, example mapping acts like a filter, preventing big fat stories from getting into your sprint and exploding with last-minute surprises three days before demo-day.

It also saves time, and so helps maintain busy product people’s interest in the process.

Many teams assume that the three amigos should write acceptance tests (e.g. Cucumber scenarios) during this session, sitting around a projector while someone types formal gherkin scenarios into an IDE. There are occasions when this is valuable, but generally I think it’s a bad idea. It can actually be distracting from the true purpose of the conversation.

It’s easy to see why people make this mistake: the apparent purpose is to take a user story, which already has some pre-definedacceptance criteria, and come up with examples that can be turned into acceptance tests.

I think the true purpose, however, is to reach a shared understanding of what it will take for the story to be done. You can move much more quickly towards this goal by staying low-tech.

Friends episodes

So instead of going for full-blown formal Gherkin scenarios, just try to capture a list of rough examples, using the friends episodenaming convention.

For example:

  • The one where the customer forgot his receipt
  • The one where the product is damaged
  • The one where the product was bought 15 days ago

Sometimes, when uncertainty lurks, you’ll instinctively want to be more concrete than this. You still don’t need to resort to the rigid structure of Given When Then just yet:

When the outcome (Then) is unclear, you don’t have an example, you have a question.

Known unknowns

Whenever a conversation like this is going round in circles, it’s because you don’t have enough information. Probably someone is missing from the conversation, or maybe you need to do some user research, or a spike.

Instead of letting everyone share their opinion about what they think the outcome should be, simply capture the question and move on. Congratulations! You’ve just turned an unknown unknown into a known unknown. That’s great progress.

Many people tell me that just this one aspect of example mapping has transformed their discovery workshops from dull ramble-athons into snappy productive mind-melds.

Who should come?

The bare minimum is your three amigos: a developer, a tester and a product person. That’s just a minimum though. By all means invite your operations, user experience people or whoever else is relevant to the story being discussed. Anyone likely to help you discover new questions, or to turn questions into decisions during the conversation will be useful.

While you’re learning this technique, it can help to have someone in the formal role of facilitator, whose job it is to make sure everything that’s being said is being captured on a card. Examples and questions fly around the room quickly, and it takes discipline to capture them on the table so you can see what you’re talking about.

So when do we write Gherkin?

Don’t let this post confuse you: there is immense value in writing Gherkin together too, especially during the early days of a project. That’s where you develop your ubiquitous language, and it’s vital to have those scenarios expressed in a way that everyone on the team believes in.

But expressing examples in that way requires a different mode of thinking from deciding which examples are in scope, and clarifying the underlying rules.

For a team that’s up and running, with a fairly mature domain language, my preference is for the product person to spend their time and energy in the example mapping session, and leave the actual writing of Gherkin to their other two amigos. Once they’ve drafted a Gherkin specification, the product person can give them feedback.

Is that how I would have written it?

This gives you an opportunity to test how effective the example mapping conversation was in transferring the product person’s knowledge to their amigos.

How often should we do this?

Product people are often busy. Respect their time by scheduling these sessions in a way that they’ll be able to give you their full attention.

My recommendation, based on what I’ve seen work for several teams in practice, is to run them frequently: every other day is often a good rhythm. Just pick one story and give it 25 minutes of attention, then go back to work. Trying to do more in a big batch will just drain your energy.

But my team is distributed!

I’ve seen innovative hacks on this already: some people use bullet lists in a shared Google doc, I’ve seen people using a spreadsheet with coloured cells to represent the cards. You could also use a mind-map. The key is to keep it quick and easy to work with, so you can focus on the conversation.

Some final tips

It’s important to clearly understand the distinction between rules and examples before you can make use of Example Mapping. I have a fun exercise for teaching this that I’ll share in a future post.

Remember that the whole purpose of this conversation is to discover the stuff you don’t already know. So there are no stupid questions. Have some fun and really explore the problem.

You’ll find that rules make natural fault lines for slicing your story. Try to feel comfortable deferring as much as possible, so that you can focus on solving the core of the problem. You can add more sophistication (and complexity) later.

This article was originally published by Cucumber Limited

Posted in Uncategorized

Pair Programming, The most Extreme XP Practice?

I was an early adopter of XP. I read Kent’s book when it was first released in 1999 and though skeptical of some of the ideas, others resonated very strongly with me.

I had been using something like Continuous Integration, though we didn’t call it that, in projects from the early-1990s. I was immediately sold when I saw JUnit for the first time. This was a much better approach to unit testing than I had come across before. I was a bit skeptical about “Test First” – I didn’t really get that straight away (my bad!).

The one idea that seemed crazy to me at first was Pair Programming. I was not alone!

I had mostly worked in good, collaborative, teams to that point. We would often spend a lot of time working together on problems, but each of us had their own bits of work to do.

With hindsight I would characterise the practices of the best teams that I was working with then as “Pair Programming – Light”.

Then I joined ThoughtWorks, and some of the teams that I worked with were pretty committed to pair programming. Initially I was open-minded, though a bit skeptical. I was very experienced at “Pairing – Light”, but assumed that the only real value was at the times when I, or my pair, was stuck.

So I worked at pairing and gave it an honest try. To my astonishment in a matter of days I became a believer.

Pair programming worked, and not just on the odd occasion when I was stuck, but all the time. It made the output of me and my pair better than either of us would have accomplished alone. Even when there was no point at which we were stuck!

Over the years I have recommended, and used, pair programming in every software development project that I have worked on since. Most organisations that I have seen try it, wouldn’t willingly go back, but not all.

So what is the problem? Well as usual the problems are mostly cultural.

If you have grown up writing code on your own it is uncomfortable sitting in close proximity to someone else and intellectually exposing yourself. Your first attempt at pair-programming takes a bit of courage.

If you are one of those archetypal developers, who is barely social and has the communication skills of an accountant on Mogadon1 this can, no-doubt, feel quite stressful. Fortunately, my experience of software developers is that, despite the best efforts of pop-culture, there are fewer of these strange caricatures than we might expect.

If you are a not really very good at software development, but talk a good game, pair-programming doesn’t leave you anywhere to hide.

If you are a music lover and prioritise listening to your music collection above creating better software, pairing is not for you.

There is one real concern that people ignorant of pair-programming have. That is that it is wasteful.

It seems self-evident that two people working independently, in-parallel, will do twice as much stuff as two people working together on one thing. That is obvious, right?

Well interestingly, while it may seem obvious, it is also wrong.

This may be right for simple repetitive tasks, but that isn’t what software development is about. Software development is an intensively creative process. It is almost uniquely so. We are limited by very little in our ability to create the little virtual universes that our programs inhabit. So working in ways that maximise our creativity is an inherent part of high-quality software development. Most people that I know are much more creative when bouncing ideas off other people (pairing).

There have been several studies that show that pair-programming is more effective than you may expect.

In the ‘Further Reading’ section at the bottom of this post, I have added a couple of links to some controlled experiments. In both cases, and in several others that I have read, the conclusions are roughly the same. Two programmers working together go nearly twice as fast, but not quite twice as fast, as two programmers working independently.

“Ah Ha!”, I hear you say, “Nearly twice as fast isn’t good enough” and you would be right if it wasn’t for the fact that in nearly half the time it takes one programmer to complete a task, two programmers will complete that task and do so with significantly higher quality and with significantly fewer bugs.

If output was the only interesting measure, I think that the case for pair-programming is already made, but there is more…

Output isn’t the only interesting measure. I have worked on, and led, teams that adopted pair-programming and teams that didn’t. The teams that adopted pairing were remarkably more effective, as teams, than those that didn’t.

I know of no better way to improve the quality of a team. To grow and spread an effective development culture.

I know of no better way, when combined with high-levels of automated testing, to improve the quality of the software that we create.

I know of no better way to introduce a new member of the team and get them up to speed, or coach a junior developer and help them gain in expertise or introduce a developer to a new idea or a new area of the code-base.

Finally, the most fun that I have ever had as a software developer has been when working as part of a pair.

Successes are better when shared. Failures are less painful when you have someone to commiserate with.

Most important of all the shared joy of discovery when you have that moment of insight that makes complexity fall away from the problem before you is hard to beat.

If you have never tried pair programming, try it.

Give it a couple of weeks, before assuming that you know enough to say it doesn’t work for you.

If your manager asks why you are wasting time, make an excuse. Tell them that you are stuck, or just “needed a bit of help with that new configuration”.

In the long run they will thank you, and if not find someone more sympathetic to what software development is really about.

Pair programming works, and adds significant value to the organisations that practice it. Give it a try.

     Dave Farley 2016

1 A Medical Drug used as a heavy sedative.

Further Reading:

‘The Case for Collaborative Programming’ Nosek 1998

‘Strengthening The Case for Pair Programming’ Williams, Kessler, Cunningham & Jeffries

‘Pair Programming is about Business Continuity’ Dave Hounslow

Posted in Uncategorized