About agile and other stories

Post navigation

Recently, many of my software research projects have boiled down to questions about value. In some senses this seems straightforward. It’s about money, isn’t it? Well, ostensibly it is yes – because it seems ‘we all know’ that when managers talk about ‘business value’ they mean improving the bottom line for the business. But, why is the word value used rather than yield or profit?

Value is not a simple concept. It only tangentially refers to finance. Even when it does there is an added aspect to it which suggests something more than simply money. It is broadly defined. It can mean importance, esteem, usefulness, benefit, good. So, when it is used it picks up all those meanings in some way. The similarity of ‘value’ to ‘values’ resonates throughout, so it is has a positive feel.

Why is this relevant to software work? It’s relevant because software has many repercussions in the real world. Reading about the recent criminal investigation into Uber in the US, is a good example. Uber has been using software known as Greyball to help it identify and avoid government officials in areas where its service was not approved (Guardian 4 March 2017). As well as doing checks to protect its drivers from harm (which seems reasonable), the software mined credit card information and social media to investigate whether the owner was in law enforcement. Uber no doubt used this to increase its value – its customer base – whilst trying to avoid being caught. Facebook has also been in the news recently for reporting to its advertisers that it can identify teenager’s mental states. Again, this will add value for Facebook in terms of revenue, but reactions to the news indicate that many people find this disturbing (Guardian 2 May 2017).

As these stories emerge it will be interesting to see what effect they’ll have. There’s no doubt that customers value honesty and transparency, and they don’t like feeling they’ve been tricked. This is particularly true when it comes to covert use of personal information. But at the same time people seem oddly inured to technology companies behaving in this way. Maybe this is because technology is novel, and there is a feeling it can’t be controlled. It would be nice if there was a wider debate about software value, and more code transparency, so that customers could start making conscious choices. Uber has had so many problems recently they may face a backlash, but Facebook seems like a juggernaut that can’t be stopped.

Integrating UCD into Agile software development is a persistent challenge for many reasons, even though it’s generally considered to be desirable. A couple of years ago I was involved in organising a workshop about Agile UCD at NordiCHI 2014 with some great colleagues. The paper presentations at the workshop were so interesting we decided they merited being put together in an edited book, on Integrating User-Centred Design in Agile Development. The result has just been published. It’s a fascinating mix of in-depth research studies, action research studies and theoretical papers. Each paper untangles a different aspect of the Agile UCD conundrum. The introduction gives a detailed overview.

I reckon that anyone who works in an academic Computing department is aware of the clashing world views that can be found between HCI and software engineering. As someone who works in academia I often assume we’re in a bubble and our concerns are not the same as those of others. But this is a case where the academic bubble is a mirror of other working environments. While reading and editing the book chapters I kept finding threads in the narratives that I recognized from my own experience– holism versus reductionism, creativity versus precision, building for experience versus building for stability … and more. What is intriguing is that while these dichotomies are persistent, they are not always what you’d expect. Is it the sense of the software engineer and the sensibility of the designer, or vice versa, or both? Ah, Elinor and Marianne Dashwood, the perfect exemplars. And it’s difficult to know which one we warm to most.

The best bit about the workshop was meeting some fantastic people and getting to talk to them about their work. At the end of the day I sat with one of the participants over a glass of wine to talk about the workshop, her work, and travelling in Finland. Eighteen months later she came over to the UK to join the Agile Research Network as a Research Associate. A great workshop, and great connections.

I’m just back from XP2015 in Helsinki. It was my first time at XP and it was great. Obviously this was partly because our paper won the Best Research Paper Award :-). But it was more than that. There was a great energy about being at a Conference where there was a good mix of academics and industry practitioners. The conversations were interesting, and people were engaged. So, it feels like a good time to start a blog about my academic journey. As much as anything I want to keep track of the ideas I come across and generate through my work. I want to be able to look back at them, and see how they grow.

The first thing I read on returning from XP was this article about Why Some Teams Are Smarter Than Others. This is about research into team ‘smartness’ done by researchers from MIT, Carnegie Mellon and Union College. They put 697 people into groups and discovered that some of the teams were ‘smarter’ than others. When they investigated further, they found this wasn’t linked to the IQ of the participants, but other factors. Smart teams, it seems, have three characteristics: a) members contribute more equally to discussions rather than letting one or two people dominate, b) members are better at reading complex emotional states of others, and c) they have more women members. What a fascinating result, and one that makes me think about the woeful lack of women working in software development. Software is transforming every aspect of our lives, so we need to ensure that smart teams are building it. Agile methods are transforming the way people work together to design and build software. Sounds to me like we need more women involved!