Lots to learn from the Norwegian Public Sector's IT success
There’s been no lack of scandals in the IT industry. When NAV, the Norwegian Labour and Welfare Administration, experienced difficulties in the middle of a major project, they changed their methods – and came up with a successful solution.
IMAGE: NAV, THE NORWEGIAN LABOUR AND WELFARE ADMINISTRATION, IS ON FACEBOOK, WHICH ALLOWS THE AGENCY TO QUICKLY ANSWER GENERIC QUESTIONS ABOUT BENEFITS. RECENTLY THE PUBLIC AGENCY CHANGED ITS WORKING METHOD IN THE MIDDLE OF IMPLEMENTING A NEW SOFTWARE SOLUTION FOR PAYING PARENTAL BENEFITS. NOW IT TAKES MERE SECONDS TO PROCESS AN APPLICATION FOR PARENTAL BENEFITS AND MOST CAN BE PROCESSED AUTOMATICALLY. view more
CREDIT: THE NORWEGIAN LABOUR AND WELFARE ADMINISTRATION
Major delays, costly overruns and severe dissatisfaction among users have often characterized the introduction of new software solutions.
The industry has been learning, but there’s still room for major improvements, says Torgeir Dingsøyr, a professor at Norwegian University of Science and Technology (NTNU).
He has studied what transpired when NAV (the Norwegian Labour and Welfare Administration) changed its working method in the middle of implementing a new software solution for paying parental benefits.
From waterfall to evolution
The old Waterfall method in software development was a linear step-by-step process.
First, the project requirements were comprehensively defined, followed by major design and architecture choices, extensive testing, and finally – far down the line – delivery to the customer. Each step was dependent on the previous ones.
“The Waterfall method involves unnecessary waiting and great risk. The model’s sequential phases require the person handing off one phase to explain what happened to the next. Extensive documentation is often involved. Not an easy task. Experience shows that project staff working on different stages don't even sit together at lunch,” says Dingsøyr, who works at NTNU's Department of Computer Science.
“Even with extensive documentation, in practice the process can turn into a whispering game. The original message can be completely derailed,” he said.
Small groups
“Another well-known problem is that the IT team sits and waits for decisions in other parts of the organization. Today, the software industry has largely moved away from the Waterfall model towards the more flexible Agile methods,” says the professor.
Agile methods were developed as a response to what the industry experienced as a crisis in IT projects. Most people thought these methods only worked for small, co-located groups creating a small software product, but today they are also used in large IT projects.
NAV success
The professor thinks that most organizations today are working with what he calls first-generation large-scale agile methods for large IT projects.
When NAV started to create a computer system to simplify the processing of parental benefits in 2016, they chose a variant of the first-generation agile method.
In the middle of the project, despite a hard deadline, NAV switched over to the second-generation agile method.
The project was completed within both the deadline and budget – and to resounding success.
The processing time for applying for parental benefits was shortened from months to seconds, and 99.8 per cent of the applications were processed using self-service.
In 2019, NAV basked in the glory of being awarded the annual prize for digitalization in Norway.
Management – a support function
“In contrast to the first generation agile method, the second-generation version places the product at the centre right from the start. Work is carried out in cross-functional teams with much more freedom.”
Overlapping competence within the group means that clarification takes place continuously, instead of in large meetings that take up unnecessary time and resources.
“Less time is spent on administration and coordination, and more on product development. Management has to ensure that they set the direction for what the groups are to do – and that productivity is high. The management also becomes more of a support function for the professional work. The working groups are freed from the straitjacket of sequential phases,” Dingsøyr says.
Test immediately – learn as you go
Instead of working out a detailed and comprehensive requirement process with user participation at the beginning of a project, developers start with the most important things right away and let the users give immediate feedback, which has been found to be more effective.
“Not enough consideration has been given to user friendliness and the fact that it takes time to learn new systems. Early interaction with users can help the developers quickly understand what’s important about the system and what the customer really wants. This enables the developers to more effectively prioritize what should be included in terms of functionality,” Dingsøyr says.
“First you try a simple solution and then expand if necessary. Second-generation methods facilitate flexibility and learning along the way,” says Dingsøyr.
Effective coordinating between groups is key
Coordination is a challenge in large projects when several groups are working to create a computer system, and where there are many dependencies between the tasks.
The risk is that changes made by one person create unexpected problems for someone in another group. International studies show that work has stopped on projects where coordination between groups is problematic.
“The study of the Parental benefits project is important because it shows how the project managed to coordinate the work in a more efficient way with a second-generation method,” says Dingsøyr.
Avoid Big Bang launches!
The professor thinks it is a waste of time to wait for one big launch:
“A Big Bang launch is really risky. Technical problems can be difficult to detect before the system is deployed,” he says.
And for users, knowing what the new systems will be like is difficult before they see how the new system works in tandem with other systems they use.
It’s better to create something, test it straight away, present it – and perhaps even put it into operation before gradually launching it to more users.
The professor says that the streaming service Spotify has several groups working on functions for the app. New versions are first tested internally and then among several test users before they are released on a large scale.
“Thanks to cloud solutions, sending out new versions has become a lot easier, and different users can get different versions. We’re gaining completely different opportunities with the new technology and new methods.”
Others want to learn
Agile development methodologies are not only used by a number of large IT companies.
More and more industries are being digitized. Tesla thinks like a software company and has challenged the entire car industry. A modern car can have up to 100 million lines of software code.
“I’m seeing, for example, that Volvo Cars is adopting large-scale agile software development. Project management is showing great interest in what’s happened in the IT industry, as well as in fields such as management,” says Dingsøyr.
He believes that Norway and the other Nordic countries are leaders in software development methods. Several environments are now ripe for second-generation methods after many years of discussing software development practice.
“The study done on the Parental benefits project is the first to describe a transition to the second-generation large-scale agile development method while implementing a major IT project, and that shows how the transition led to more effective coordination practices,” says Dingsøyr.
Reference: Dingsøyr, T., Bjørnson, F.O., Schrof, J. et al. A longitudinal explanatory case study of coordination in a very large development programme: the impact of transitioning from a first- to a second-generation large-scale agile development method. Empir Software Eng 28, 1 (2023). https://doi.org/10.1007/s10664-022-10230-6
JOURNAL
Empirical Software Engineering
METHOD OF RESEARCH
Case study
SUBJECT OF RESEARCH
Not applicable
ARTICLE TITLE
A longitudinal explanatory case study of coordination in a very large development programme: the impact of transitioning from a first- to a second-generation large-scale agile development method
No comments:
Post a Comment