Category Archives: Agile

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?

 

Robots Instead of Health Care Professionals??

I listened to the introductory key note from the conference Human Centred Software Engineering by the very inspiring Danica Kragic on social robotics.

Clearly robots such as avatars of humans will influence work very much in the future. One of the areas of application is health care. Danica Kragic mentioned health care services such as Cognitive Behavioural Therapy, and research has indicated that this might be a possible future avenue. Physicians would collaborate with robots in their work, and part of the work would be replaced by robots such as some part of the therapy.

Hmm. One can wonder what the reactions from physicians would be if we start doing research on replacing them with robots or machines? And how would the patients react to robots? Perhaps not as negative as one could think?

One can also wonder how the professional competence of health care professionals can be transfered to robots?  Is this possible?

BTW: If you haven’t listened to Danica Kragic’s Sommar, I highly recommend it (in Swedish only, though) 😀

“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 “

 

Visit to the Visualization Studio at KTH

The conference reception for Human Centred Software Engineering yesterday was at the KTH Visualization studio.

We got the possibility to try different Virtual Reality Games. Of course I tried all available devices!

planetarium

The visit also included a 3D planetarium demonstration with an extremely interesting presentation of the possibilities of technology.

Very cool indeed!!

If you ever get the chance – go there and try it! 🙂

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.