Working as a leader in agile is challenging. You need to find a balance between being the authoritative leader and being that supporter of the teamwork. A few years ago we did a study to try to understand the products owners and their work, looking at the following questions: .

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 the product owners found it hard to measure 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 the Product Owners struggled with

The abstract of the paper:

In Scrum, the Product Owner (PO) role is crucial for the team to be successful in developing useful and usable software. The PO has many responsibilities and challenges, including being the link between customers, other stakeholders and their development teams. This exploratory case study conducted at the software development company Spotify focuses on POs three responsibilities: (a) Identification of customers, (b) Estimation of value of their teams’ work and c) Forming a vision for the product. Additionally, challenges perceived by the POs are studied. Data was gathered through five interviews and on site observations. Results show that the POs activities are divided between daily work, such as making sure that their teams are functional and long-term activities such as making a vision for the product. The main challenge of the POs is to inspire and encourage team members to collaborate and communicate within the team and with stakeholders.

 You find this paper and research gate if you’re interested in reading it.

One can claim that Agile development has positive attitudes towards continuously improving work practices of IT professionals and the quality of the software. There is a clear focus on learning and teamwork, as well as communication in Agile.

A few years back we did a study on Agile with a focus to understand continuous improvement and how it works in practice.

This study focused on value adding activities such as user involvement and gathering metrics. We also looked at non-value adding activities, such as correcting defects.

Interviews were conducted with 10 IT professionals working with agile development in Iceland.

Results show that IT professionals emphasise communication with users both through direct contact and using email. Results also show that they rarely use metrics to make improvements measurable. One can wonder why this is the case in the ara of New Public Management when everyting needs to be measured to be visible?

You find more about this in our paper:

Lárusdóttir M.K., Cajander Å., Simader M. (2014) Continuous Improvement in Agile Development Practice. In: Sauer S., Bogdan C., Forbrig P., Bernhaupt R., Winckler M. (eds) Human-Centered Software Engineering. HCSE 2014. Lecture Notes in Computer Science, vol 8742. Springer, Berlin, Heidelberg

One can conclude that uses centred systems design (UCSD) has much to gain when integrated into Agile systems development. Agile is the de facto Standard of systems development whereas UCSD is it not at all as commonly used. However when looking into the UCSD activities in agile processes in practice one can see that this integration it’s not that easy.  In a paper by Jan Gulliksen, Marta Larusdotter and me we therefore conclude that UX professionals need a more explicit role and more authority when working in the agile projects.

We have contacted numerous interviews studies and survey studies on agile and UCSD, and we decided to bring together all these published studies together with additional experiences to make some general conclusions about agile and UCSD.

In the paper we analyse how findings according to th for values presented in the agile manifesto To understand the constraints that the scrum process imposes.

If you want to know more you find the paper here:

Larusdottir, M., Gulliksen, J., & Cajander, Å. (2017). A license to kill–Improving UCSD in Agile development. Journal of Systems and Software, 123, 214-222.

Scrum is seen by many as user centred, but how does it really work in practice? Me and Marta Larusdottir set out to investigate this question through an interview study with 21 people who worked with usability in Scrum projects. Marta came from the field of usability evaluation, and she was especially interested in what usability techniques they used in industry.

When we started doing the interviews we were really surprised to find out that the answer to the question: “What usability techniques do they use in practice?” is that there are very few formal evaluation methods that are used at all, and that the methods used are indeed all very informal. The user perspective in Scrum Projects in Practice was indeed only existing, and not explicit.

Conclusions from this study are also that the responsibility for the user perspective is very unclear in Scrum projects. Often the user perspective is neither discussed nor described in the projects. However, the user perspective is often present through informal feedback used to understand the context of use and inform design.

You find these results in this study:

Åsa Cajander, Marta Larusdottir, Jan Gulliksen. Existing but Not Explicit – The User Perspective in Scrum Projects in Practice. Paula Kotz´e; Gary Marsden; Gitte Lindgaard; Janet Wesson; Marco Winckler. 14th International Conference on Human-Computer Interaction (INTERACT), Sep 2013, Cape Town, South Africa. Springer, Lecture Notes in Computer Science, LNCS-8119 (Part III), pp.762-779, 2013, Human-Computer Interaction – INTERACT 2013. .

There are a whole bunch of usability methods out there, and we teach many of them in our courses. However, one can wonder what methods are really used the context of Scrum?

We investigated this question in the paper:

Jia, Y., Larusdottir, M., & Cajander, Å. (2012). The usage of usability techniques in scrum projects. Human-Centered Software Engineering, 331-341.

Not surprisingly the most used method is “Workshops” according to the survey we sent out. The second most common method was lo-fi prototyping. 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.You see the whole table from the paper below:

The technique that is most frequently used is lo-fi prototyping used by more than half of the participants two to four times a month.

When we asked practitioners what is the best usability method they answered that formal usability evaluation is one of the best methods, but one can note that few use it!

Conclusions from the study are that the most popular usability techniques are informal. They can be used quickly without much preparation. Formal usability evaluation with users is a highly ranked technique. HOwever, it is not commonly used.

I will kick off the fall by writing a series of blog posts on Scrum, Agile and User Centred design. This was one of my favourite research topics a few years ago, and I collaborated with excellent Marta Larusdottir from Reykjavik University in a studies around this.

Without doubt Scrum is the dominating systems development method in Sweden today. The name “Scrum”, is borrowed from Rugby where a Scrum formation is the one in the image of this blog post. The team is supposed to work tightly together as in this formation, one could guess :-). One can also guess that you are supposed to be male as a member of the team, as the majority of people who play rugby are male 😛

Scrum is really a very simple set of rules, as defined by for example Mike Cohn and presented in the image below:

Scrum contains a whole set of roles and procedures too that you are recommended to follow, and of course these have unique and special names to make the concept more unique.

Many companies say that they use Scrum, or a Scrumish method. This could mean that they use one part of Scrum, or all of Scrum. We really did not know how organisations used Scrum, so we set up a study to find some answers.

In one of our studies Marta Larusdottir, Yuan Jia and I therefor tried to find out what parts of the Scrum method people use and hos usability is incorporated in the work. You find the below presented results in the following publication:

Yuan Jia, Marta Kristin Larusdottir and Åsa Cajander. (2012). The Usage of Usability Techniques in Scrum Projects. International Conference on Human-Centred Software Engineering, Toulouse, France.

We found out that the usage of the different fundamental activities and roles varied quite a lot. This is presented in the table below. A very large majority used sprint planning, whereas quite few used the burn-down charts. However, one can conclude that the percentage of people who said they used the different methods was generally quite high. There were no companies that claimed that they used Scrum, and then skipped large parts of the fundamental activites.