Tag Archives: Agile

Working with Usability in Scrum Projects – what Usability Activities are Used in Practice?

A few years ago Yuan Jia worked with Marta Larusdottir and me as a master student doing her master thesis study in our research project on Agile development and UCD.

There was lack of studies describing to what extent different user centred methods were used in Scrum projects, so this became the topic of Yuan Jia’s master thesis, and which resulted in a conference paper. I remember that we had a very good collaboration with Yuan Jia, who now is a PhD student in the US.

When designing the study we quickly ran into problems with the number of respondents to our web based questionnaire. We did not have the mail contact information to people in organisation working with Scrum and user centred design. First we distributed the survey through the Uppsala Tax Office and LokaIdelen which is a website offering information to companies in Sweden. I also remember Yuan Jia’s long lists of company names and phone numbers as she systematically contacted company after company. Tedious work, but to be honest research work can be very much administration from time to time. In the end we had around 50 people who answered the survey 🙂

The survey has some interesting results, se Figure below. The most commonly used usability technique in Scrum projects is workshops, followed by lo-fi prototyping, interviews and meetings with users, all used by more than half of the participants.

One can note that all these usability techniques are informal, meaning that these techniques can be used quickly without much preparation. Formal usability evaluation with users is a highly ranked technique by the participants but not commonly used by them.

 

the-usage-of-usability-techniques

 

We presented the paper at the Human Centred Software Engineering Conference (HCSE) in 2012.

You find the paper here.

 

On the Future of Software Engineering by Ivar Jacobson

I listened to a very interesting key note by Ivar Jacobson on the future of software engineering. Many of the things he said were spot on true, and some were a bit provocative and I disagree, but the talk was still very interesting.

Ivar Jacobson starts his key note with a historical overview of the history of software engineering, and the presentation included reflections on organisational learning and good practices. According to Jacobson there has been a few different paths in software engineering, but very little learning from past experiences. Software developers are not trained in learning from the past, and to rework and improve. They are trained in doing new things. I think he has a point here, and this is a wider phenomena than something unique for software engineering:

“Every new path starts by throwing away what you had and starting all over with new vocabulary, “new” practices, new gurus”

When talking about Agile, Ivar Jacobson claims that it is definitely a good practice. He claims that if you are a methodologist you need to be out of marketing, otherwise you are out of the game, and Agile has succeeded here. The method also needs to be accepted and appreciated by the software developers, and there is where Agile is successful. However, he also claims that many of the good practices and things we learned about software development was thrown over board when moving to agile:

“I am a firm believer in Agile, but lots were lost when we moved to Agile.”

One cornerstone of learning in an organisation, according to Jacobson, is the common ground and a common vocabulary. And we need methodologies, processes and a common vocabulary to coordinate the work with ITC in organizations. Work that includes several thousand people cannot be only creative design.

We also need to know more about how software developers learn, and how the marketing of new methods work. I really agree with this, and studies of learning in relation to software engineering is really a part of my interest. Ivar Jacobson continues by  saing that people learn through using, and working with methods, and he is reflecting on the use of books as a source of learning:

“People buy the books, but they don’t read them. How do we know what they know?”

Finally Ivar Jacobson presents the concepts of Essence, which is built on previous methods and ideas. According to Jacobson Essence is:

Essence – a standard that defines the smallest set of concepts that are common to all software projects – helps embed agile professional practices and governance across an organization for sustainable, scalable and responsive solution delivery.

The future of software engineering is human centred, of course, but there is still some way to go before we are there . According to Ivar Jacobson the way forward is to create a learning organisation, that includes a kernel of common concepts and knowledge. I agree with him completely, and the problem is how to create this situation. Perhaps action research and practice oriented research is the answer to this question?

 

The Volkswagen Scandal: Values and Software Development

In 2015 it was revealed that Volkswagen had deliberately cheated with environmental tests, and that their engines did not fulfil the requirement of pollution. This was indeed a big scandal! But one can wonder how it could happen that such a well reputed company makes such bad and unethical decisions? The presentation that I listened to at the Human Centred Software Engineering conference did not give an answer to this question, but instead talked about what we should do in software development to ensure that these things do not happen. The paper is called: “Do you own a Volkswagen? Values as Non-Functional Requirements”

Friedman’s ideas of Value sensitive design has been around since the 1990’s, and the idea behind it is really good. We should be aware of our values and incorporate them in systems development. Cockton has also made some contributions in the field of value, but he looks more at the value perceived by customers than the value of the systems developers. I also worked some with values as my first area of research, and did my licentiate degree on Values and Perspectives Affecting IT Systems Development and Usability work. My focus was on what values are at the core of the decisions made in companies when it comes to software development. Not surprising money, time and automation were values that collided with the values of user-centred design.

One can wonder why this way of thinking is not present in software development processes such as agile development? It feels like the value sensitive design and the ideas behind that are completely off, even though agile generally has a very strong focus on working teams, humans, communication and leadership – not to mention speed. 

Perhaps it would be easier to discuss values in software development today than ten years ago due to the discussion about sustainability? Perhaps things have matured and we have another way of thinking than before? Hmmm. Or perhaps not?

“How do we design Work 4.0? “

 

Technology change human work, changes responsibilities, change decision making and we are losing knowledge and competencies, according to a paper by Holger Fischer and Björn Senft presented at the Human Centred Software Engineering Conference. Their research is then on how organisations should work to ensure that the systems build to support this work are usable, and conform with standards. Unfortunately the paper does not present the silver bullet to how this should be done ;-).

This research is indeed very relevant for my research group as it is a complex issue to design ICT that works well. Hmm. But after a few years in the area of ICT and work, we are getting a bit disillusioned about the state of the art when it comes to ICT at work. Or as one of my colleagues in the group joked :

“I do research on how to introduce new ICT systems for work in organisations without breaking the organisation down “

 

Responsibilities and Challenges of Product Owners at Spotify – Conference Paper

Today we presented our paper Responsibilities and Challenges of Product Owners at Spotify at the Human Centred Software Engineering Conference at KTH in Stockholm. The paper is written together with Sigurhanna Kristinsdotti and Marta Larusdottir. 

The Product Owner is responsible for the list of requirements and the work in the team together with the Scrum Master in the context of agile development. 

What did we do? 

In 2014 we did a study at Spotify. They have used agile development since 2006, and they focus much on usability as their slogan is “It’s easy”. Spotify reached 39 million subscribers in 2016!

The main research questions in the paper were:

  1. What are the main responsibilities of the Product Owners
  2. What are the challenges of a Product Owner, and how does he or she cope with them?

What did we find? 

  • Most of them found it hard to mesure the value when developing new features
  • Some Product Owners use the number of users as their main parameter of success
  • To lead the vision was a difficult responsibility that Product Owners struggled with
  •   “I think it‘s important that the POs see to it that the team has a vision – that they know what it is – but i don‘t thing it is solely the PO who creates that vision, I think that the team does that together, but the PO is responsible for having it.“

 

The visions needs to be understood and appreciated by the teams, and the product owners do not want to use their authority to make decisions:

 “You can ususally see when the team has set the goals as a whole rather than the goals being delivered from someone else.“

The main results 

The Product Owner role is very diverse. The challenges are many, and the job is very multifaceted.

The Product Owners need to have one foot in the daily work of the Scrum teams, and one foot in the future.

 

Publication: Contextual Personas to Understand Digital Work Environments

We have developed a new method for including the user perspective and the user’s digital work environment in software development.

The method is an adoption of the persona’s method where work environment aspects are included, and can be used when designing or procuring IT systems.

The method describes the holistic uses situation of a person with the 10-20 different IT systems that are used at work. It is based on a well known theory by Karasek and Theorell regarding control, demand and support in relation to stress.

For further reading see our book chapter on the topic. It is published in a Springer book.