=Paper= {{Paper |id=Vol-3414/paper-2 |storemode=property |title=Systematic Literature Review of Agile Framework Application for IT System Development in Public Sector |pdfUrl=https://ceur-ws.org/Vol-3414/paper-2.pdf |volume=Vol-3414 |authors=Jolanta Graudone,Mārīte Kirikova |dblpUrl=https://dblp.org/rec/conf/caise/GraudoneK23 }} ==Systematic Literature Review of Agile Framework Application for IT System Development in Public Sector== https://ceur-ws.org/Vol-3414/paper-2.pdf
Systematic Literature Review of Agile Framework Application for
IT System Development in Public Sector
Jolanta Graudone 1, Mārīte Kirikova 2
  Riga Technical University, Ķīpsalas iela 6A, Riga, LV-1048, Latvia
1,2



                 Abstract
                 Agile methods support an iterative, communication based and flexible way of IT software
                 development that reduces the traditional software development risks. This paper addresses the
                 aspects of Agile application in public sector that is seen challenging and still lacks enough
                 knowledge and practice to be addressed in the formalized way. A systematic literature review
                 was done with the aim of providing insights into the most critical aspects highlighted in the
                 related work by mapping these aspects over the project lifecycle phases thus giving a broader
                 view on the problem in general; furthermore interrelated aspects are discussed on the basis of
                 existing suggestions and practices from other studies. Collected solutions could help
                 researchers and practitioners to resolve some of the issues of Agile application in IT
                 development in Public sector.
                 Keywords 1
                 Public sector, software development, project management, Agile.

1. Introduction
    With creation of Agile manifesto in 2001, the formal approach to mitigate and address the most
common IT development challenges of that times was created. Even though Agile approach was widely
used in private sector, the public sector [14], because of several specifics existing in these organizations,
are still often using the traditional ways of working and that also applies to the IT development [15].
The Agile presents many benefits but the conflict with public sector regulations, organizational
structure, and other characteristics has slowed down, or in some cases stopped, the introduction of Agile
[15].
    There are many real-life examples that have shown that it is possible to introduce Agile practices
and get benefits from them in public sector, but Agile also brings new risks and challenges that need to
be addressed [5]. Considering the high complexity IT systems and the problems in availability
requirements, and the scale of the systems that are needed in governmental organizations [16], it is
understood that the iterative approach, business value prioritization and the constant communication
facilitated by Agile practices is the key to ensure success of these projects [13], [14]. And, by addressing
the challenges of Agile application in the public sector, it is possible to help ensure the benefits of Agile
that it brings [7].

2. Research methods and data collection
    To address research questions systematic literature review was done. For the literature review the
articles of last 6 years were considered based on the high increase of digitalization processes in public
sector organizations, especially in period of 2016 – 2022 that would also include the latest tendencies
in the IT system development field. There is not much research available on Agile practices for software
development in public sector. The articles provided by search engines using such keyword
combinations as ''application of agile in public sector'', ''challenges with Agile in public sector'' in
Scopus database provided 34 and 56 results respectively, from which approximately 70 % were

Agil-ISE23: 2nd Intl. Workshop on Agile Methods for Information Systems Engineering, June 13, 2023, Zaragoza, Spain
EMAIL: Jolanta.Graudone@rtu.lv (A. 1), Marite.Kirikova@rtu.lv (A. 2)
ORCID: 0000-0002-9369-3744 (A. 1), 0000-0002-1678-9523 (A. 2)
              Copyright © 2023 for this paper by its authors.
              Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0)
              CEUR Workshop Proceedings (CEUR-WS.org)



                                                                                    10
relevant, similar results were achieved in databases of Web of Science with less results but the same
distribution. From all articles those found the most relevant were handpicked, that were relevant in topic
of outsourced (contracted) software development and risks, challenges that are related to working under
Agile framework.
    The selected articles could be grouped by the type of research method applied. Most of articles
consist of a specific country case studies [1], [2], [3], [4], the second group is the research that
considered several or one case in sample area, using surveys, interview, questionnaires [5], [6], [7], [8],
the last group, [9], [10] is systematic literature review articles.
    The main aspects of the Agile application in public sector will be identified based on the analysis of
related work. An aspect is understood as an area of improvement, challenge or risk in Agile application
that is significantly contradicting to the traditional ways of working and organizational characteristics
existing in public sector.
    The research questions of this paper are:
    1) What are the most contradicting aspects of Agile application in public sector IT development
         projects?
    2) Is it possible to observe interrelations between several contradicting aspects?
    3) What are the improvement suggested for addressing the aspect contradicting the traditional ways
         of working in public sector?
    The goals of this analysis are by addressing the research questions to, firstly, detect the scope within
the IT development project where the contradictions exist, and, secondly, to investigate the interrelation
of aspects and elaborate more on group of aspects that, if being resolved, could improve the Agile
practices in public sector.
    As there is a limited amount of research work in the topic of interest, this analysis gives a new
uniform view on the already presented information that has been provided as success factors, challenges
and risks (aspects - previously defined) while also considering interrelation between them.

3. Contradicting aspects of Agile and tradition project management practices
   in the Public sector
   To provide and organized and clear view on information available in related work and to determine
the most problematic phases and aspects of the Agile practice application in projects developing IT
systems for the public sector, each, even small, area of elaboration in any source used was (1) identified,
(2) grouped by commonalities, and (3) mapped to 5 phases of project lifecycle. The results are shown
in Table 1. The five phases of project lifecycle are chosen according to PMBOK Guide [11]. Each of
the phases have defined content and activities to be performed that were cross-referenced with the
activities and characteristics highlighted in the analysed articles.
Table 1
Mapping of Agile application aspects to Project lifecycle phases
                                                                                                                             Aspects considered in related work
                                                                                                                                                                                                                                                      Monitoring and
             Initiation                                                                Planning                                                              Execution                                                                                                                                     Close
                                                                                                                                                                                                                                                      control
                                                             Evaluation of potential




                                                                                                                                                                                                                                                                                       Change management
                                                                                                                                                                                                        Business and IT team




                                                                                                                                                                                                                                                                                                                                      Evaluation of project
                                                                                                                                                             Practices and Scrum




                                                                                                                                                                                                                               Knowledge and skills

                                                                                                                                                                                                                                                      Progress monitoring
                                                                                                                                           Risk management




                                                                                                                                                                                    Collaboration and
                                                                                       Scope and price




                                                                                                                                                                                    communication




                                                                                                                                                                                                                                                                                                                      Documentation
                              Innovation and




                                                                                                                        responsibilities
             Organizational



                              business case




                                                                                                         Project plan
                                               Contracting



                                                             contractor




                                                                                                                                                                                                        alignment
                                                                                                                        Roles and




                                                                                                                                                                                                                                                                            Feedback
             hierarchy




                                                                                                                                                                                                                                                                                                           Delivery




                                                                                                                                                                                                                                                                                       [2],
                                                                                                                                                                                                                                                                                       [3],
                                               [1],                                                      [1],                                                [1],                                       [2],
                                                                                                                                                                                    [2],                                       [4],                                                    [4],
                                               [2],                                                      [2],                                                [2],                                       [3],
 Reference




                              [6],                           [3],                      [3],                             [3],               [2],                                     [4],                                       [7],                                         [1],       [5],                [2],
             [2],                              [3],                                                      [3],                                                [6],                                       [4],                                          [1],                                                            [6],
                              [7],                           [8],                      [6],                             [6],               [5],                                     [5],                                       [8],                                         [4],       [6],                [4],                       [1]
             [10]                              [7],                                                      [4],                                                 [7]                                       [5],                                          [6]                                                             [7]
                              [10]                           [9]                       [8]                              [7]                [9]                                      [6],                                       [9],                                         [8]        [7],                [5]
                                               [8],                                                      [6],                                                [8],                                       [8],
                                                                                                                                                                                    [7]                                        [10]                                                    [8],
                                               [10]                                                      [10]                                                [10]                                       [9]
                                                                                                                                                                                                                                                                                       [9],
                                                                                                                                                                                                                                                                                       [10]



                                                                                                                                                                               11
    3.1.          Initiation
    The challenges that are related to the organizational structure can be linked with several project
lifecycle phases. In its essence this challenge is related to the differences in the organizational structure
that is usually existing in public sector. Agile principles manifest the teamwork and collaboration and
most importantly self-organization that conflicts with the hierarchical structure, control and command
approach in organizations of public sector [10].
    Innovation and adaptation process in public organizations is also discussed and found to be slower
than in the private sector that could rise some difficulties to start project and determine the business
use case [6], [7], [10].
    The major issue discussed in [1] is the contracting of IT system development services. In public
sector, the public procurement law, especially in EU countries, adapted from EU legislation [12], limits
the organizations of applying a flexible scope, options of changes in requirements, budget, or project
plan as it should be set prior as required by procurement regulations [3] , [10].
    The procurement limitations rise another issue related to the evaluation process of possible vendors
and choice of contractor [3], mostly it is question of the lowest bid that not necessarily is the best way
to choose the partner for system development and that also rises another problem ⸻ the lack of trust
[8], [9].

    3.2.          Planning
    The public sector software acquisition method through procurement defines that the scope and price
of the software development is fixed, as the requirements need to be set before the tender and it directly
contradicts with Agile that manifests the flexible scope [3], [6], [8]. The specification of the system
being developed should be presented at the start of the tender process and cannot be changed if special
conditions are not foreseen. From legal point of view that is also emphasized in article [1]. Contractor
is providing the cost offer based on presented requirements that as in any initiation phase are still under
limited to the current understanding [8]. Accurate definition of requirements is important, but cannot
save from external impact and complexity risen effects on software requirements.
    The research results of [6] show that the second most common challenge of agile application in
public sector is the planning and initiation of the project. But for cases where agile is applied, on the
opposite to all benefits, it is reported that the predictability of the project is reduced [10], [2], that is not
well perceived by public organizations. Together with the fixed scope and price, at the start of the
project the project plan is determined, and go-live date is set based on assumption that the scope and
cost is not changed. The principle of magic triangle of project management manifests that these three
aspects (scope, price, time) are closely linked and changing one of them leads to changes in others. In
practice, usually, these are not fixed values leading to overstepping of one or another aspect and risking
with a very low-quality result [1], [3], [4].
    Setting the roles and responsibilities is important for successful project management and execution
and should be agreed between parties prior the active development phase is started. The authors of [3]
suggest defining roles and responsibilities in agreement between parties, in other sources more
traditional roles in Agile are discussed. Different setups exist, but the problem with public sector is the
lack of knowledge about agile practices leading to not understanding of the role assigned [6], [7] and
low dedication of organization’s employees assigned to project, as it is, most commonly, an additional
responsibility to everyday tasks and is not properly respected by the organization [7].
    Especially with high complexity projects, the risks of not meeting the goals of the project increase.
Even though the Agile software development covers most of the IT critical success factors, there is still
a need for continuous identification and analysis of risks [5]. The research presented in [3] emphasizes
the need for early risk estimation by client and dividing of responsibility of risks between parties. Early
identification and mitigation of risks reduces the need for costly mitigation afterwards [9].




                                                        12
    3.3.            Execution
    To facilitate agile type of development different practices in public sector have been adopted. Most
of them are associated with successful project. The practices covered in more than one of the articles
are summarized in Table 2. Controversially to the benefits of client involvement, the authors of [5]
report about risks of technical debt and not meeting non-functional requirements in case of too high
involvement of a business side increasing the pressure on development team on delivery of new
functionalities. The practices also mostly contradict the usual way of working in different public
organizations. The Scrum is one of the Agile based methodologies that is most commonly applied in
the public sector to facilitate agile practices [2], [6].
    Traditional risk of development is poor communication with users and stakeholders, which is
mitigated by Agile practices [2], [4], [5]. The adaptation of communication practices is challenging as
the public organizations usually relay on thorough documentation and indirect communication [7].
Also, the communication and collaboration are important between development teams [6].
    Specifically in Public sector, where requirement list is set at the start, there are cases where the
dispute between Business and IT teams is caused on the specifics of the requirement, business side is
trying to include more than expected, but the IT side is trying to provide minimum of what is required
[8]. The mutual understanding of the tasks can be a challenge. Most of research describes Agile
practices to improve the alignment of Business and IT teams [2]-[5], [9].
    Appropriate knowledge and skills are a challenging aspect across all the participants, but most
problems arise in the public organizations, as the client competence contributes to success of the project
[4] as well as of other stakeholders and users. The problem may arise if stakeholders are not familiar
with Agile practices and their own roles and responsibilities [8]–[10]. Even with training, it can still
cause issues in the practice [7].
      Table 2
      Agile practices in public sector
       Practice considered in more                   Reference article indication               Number of
       than one article                  [1]   [2]         [4]          [5]         [6]   [8]    articles
                  Estimation              x     x           x                        x             4
                 Daily stand-up                 x                                         x        2
               Frequent delivery                x           x                                      2
                Short iterations                x                       x                          2
        Iteration and release planning          x                       x           x              3


    3.4.            Monitoring and Control
   The progress monitoring in article [1] is related to contractual relationships of parties, providing
insights of public sector and need for monitoring result reliant payment and planning methods. On other
hand, the authors of [6] present the Scrum methods for monitoring of each sprint with progress report.
   In Agile the frequent deliveries with short time-boxed iterations enables the possibility to receive
feedback continuously and assure that the functionality implemented matches the needs of business
[2], [4]. The availability of this feedback, more or less, relies on the involvement of client, other
stakeholders, and users in the testing of provided functionality [8].
   Change management is facilitated within the Agile framework but is clearly contradicting the
traditional ways of project management in public sector (because of early set requirements and fixed
scope and price). Flexible scope within Agile is a huge benefit in dynamic environment and complex
systems and is widely elaborated in the articles used in analysis of Agile approaches [2]–[8], [10].

    3.5.            Close
    The authors of [2] report that reason for implementing Agile is the delivery predictability, which is
interestingly contradicting the project predictability that usually is evaluated as decreased. Delivery to
user is not an aspect that is resolved within the framework, but also it does not contradict the traditional


                                                         13
project management in public sector [4], [5]. In the [5], an example is provided where dedicated sprint
for dealing with deployment and operability issues was introduced to improve the situation.
   Documentation in public sector has a much higher importance than it is positioned in Agile
practices and methodologies based on Agile that can arise some challenges within the public
organization [6], [7].
   Evaluation of a project is mentioned in [1] as a basis for the settlement with contractor, but in
general, the whole project with all involved parties can and should be evaluated regardless of the applied
development method.

4. Analysis of ways of handling interrelated Agile application aspects
    Clearly not all activities of a project lifecycle are represented in each phase, but it is safe to conclude
that these are the activities and aspects that are already identified in previous research to be significant
for success of the project and most importantly, in this specific case with Agile practices, in the public
sector.
    From analysis it is possible to conclude that seven of the aspects were mentioned at least in the half
of the articles reviewed, these are mostly connected to the execution of the project, where the actual
development takes place. That also could be an indicator that, even if the public organizations are not
working with Agile principles in their usual business, it is still explored how this could be applied in
the execution phase exclusively for IT system development projects.
    By looking back on the summary provided in Section 3, it is possible to indicate at least one group
of interrelated aspects. If considering public organizations applying Agile, there is a strong
interdependency between practices applied, collaboration and communication, roles and
responsibilities, knowledge and skills and organizational hierarchy that can be concluded from the
summary of the aspects collected and the commonalities of issue representation in the related work.

    4.1.         Collaboration and communication
   This is one of the main attributes associated with Agile ways of working. The questionnaire results
reported in research in Brazilian public sector [2] show that more than 80% of respondents have
responded that the Agile practices have improved the collaboration and communication within and
among the teams that is also the aspects evaluated to be improved the most. The authors of [9] categorize
collaboration and communication issues under the cultural change category. Although, the high
elaboration on the issue effects on project and its importance are present in several of reviewed articles,
none of them provide clear suggestions to facilitate better collaboration and communication. But from
the Brazilian research results it could be speculated that the Agile itself is the main solution and some
practices within the Agile approach should be more strongly followed to gain improvements.

    4.2.         Roles and responsibilities
    On the roles and responsibilities aspect the research [7] on Finnish government organizations IT
projects with Agile approach has provided several insights. In the research semi-structures interviews
were conducted with participants and the results were structured and analyzed. In the results, roles and
responsibilities were one of the categories of challenges. As of outsourced software development and
organizations structure, some additional roles were included in the framework, e.g., business product
owner and ICT product owner, and administrational project manager that caused additional confusion
about responsibilities, but reduced the risk of incompetent participant in the role in some cases. They
also emphasize the work-load of a product owner: as nominated from the organization, it was a big shift
in the amount of work they needed to deal with in comparison to traditional project management causing
insufficient communication possibilities because of overload. In conclusions the authors connect the
issues with organization structure also and provide suggestion to manage it with the change in
organization values and culture, while the participants suggest better training to be ready for Agile [7].

    4.3.         Knowledge and skills

                                                       14
   Lack of knowledge and skills is identified as a challenge in several articles. It can be divided in the
knowledge and skills in Agile practices and knowledge [3], [4], [7], [9], [10] and skills necessary for
development of system under the question. From the latter one, development team’s lack of knowledge
about operations is highlighted, and also the unwanted effect of new teams that usually cause more
defects [5]. The need for Agile knowledge once again justifies the necessity of Agile training. Some
suggestion is presented in already mentioned Finnish organizations research [7], where participants
respond that the communication is the key to overcome the lack of knowledge, in some responses they
mention the valuable contribution of RACI matrix.

    4.4.         Organizational hierarchy
    The Agile approach is more suited for organizations that are not hierarchical and using command
and control type of work process. [2]. The research about Brazilian government identifies this as a risk
and applying Agile ways of working includes under the cultural change challenge [2]. In literature
review done in [10] it is also indicated that, regardless the benefits of Agile, it does not guarantee
success in hierarchical organizations. Authors suggest that the management should show the initiative
in cultural change giving an impulse to employees to shift from individual to more collaborative way
of working. With management involvement in cultural change together with well-defined roles and
responsibilities within project there is a way to minimize the risk of organizational structure impact.

    4.5.         Practices
    Practices in Agile realization differ but, as previously stated, the Scrum methodology, together with
all the practices coming with it, is the most popular within public organizations. The limitations of
contracting are provided in research of Agile practices in public sector in Italy [1]. The authors are
suggesting using the estimation as one of practices not only for sprint planning but also as a reference
for payments for delivered functionalities in result creating a specific contract framework. Additionally,
the practices as such include not only the processes but the roles already mentioned. Different
approaches exist here, for example, [7] suggest creating several product owner roles but, as for [3], to
create a team that collectively represents the product owner.

5. Conclusions
   By search of related work, it is evident that there is still a lack of appropriate level of understanding
of the practices of Agile application in public sector and many challenges to be faced that calls for
appropriate in-depth research. The Agile application impacts all of the project lifecycle phases and,
even though it is mostly discussed in the execution phase, the linkage and impact to all other project
phases should be considered.
   From suggested solutions to manage these aspects, the common one is the cultural change that needs
to be undergone to implement the Agile practices because of the hierarchical structure in public
organizations, command and control way of working, high documentation level and formal ways of
communication that contradict the Agile practices in different ways. From more practical perspective,
a strict role and responsibility definition was suggested that should also be effective to manage
identified aspects. The importance of appropriate knowledge is stressed and calls for a need of
appropriate Agile training in public organizations that can significantly improve the project success.
   In conclusion, there is still a need for more in depth analysis of the aspects identified to see how
Agile in the public sector practically could be improved as the information on the Agile practices in the
public sector is still limited, but development of complex IT systems in the public sector is still
problematic and that could be resolved with application of an appropriate Agile framework.

6. References
[1] D. Russo, G. Taccogna, P. Ciancarini, A. Messina, and G. Succi, “Contracting Agile Developments
    for Mission Critical Systems in the Public Sector,” in Proceedings of the 40th International


                                                      15
     Conference on Software Engineering: Software Engineering in Society, 2018, pp. 47–56. doi:
     10.1145/3183428.3183435.
[2] R. M. Fontana and S. Marczak, “Characteristics and challenges of agile software development
     adoption in Brazilian government,” Journal of technology management & innovation, vol. 15, no.
     2, pp. 3–10, 2020.
[3] A. KACZOROWSKA, “Traditional versus agile project management in public sector in Poland,”
     Scientific Papers of Silesian University of Technology. Organization and Management Series, vol.
     2020, no. 149, pp. 287–302, 2020.
[4] P. Mohagheghi and M. Jørgensen, “What Contributes to the Success of IT Projects? Success
     Factors, Challenges and Lessons Learned from an Empirical Study of Software Projects in the
     Norwegian Public Sector,” in 2017 IEEE/ACM 39th International Conference on Software
     Engineering Companion (ICSE-C), 2017, pp. 371–373. doi: 10.1109/ICSE-C.2017.146.
[5] A. Elbanna and S. Sarker, “The Risks of Agile Software Development: Learning from Adopters,”
     IEEE Softw, vol. 33, no. 5, pp. 72–79, 2016, doi: 10.1109/MS.2015.150.
[6] A. Ribeiro and L. Domingues, “Acceptance of an agile methodology in the public sector,” Procedia
     Comput Sci, vol. 138, pp. 621–629, 2018.
[7] J. Nuottila, K. Aaltonen, and J. Kujala, “Challenges of adopting agile methods in a public
     organization,” International journal of information systems and project management, vol. 4, no. 3,
     pp. 65–85, 2016.
[8] Y. Lindsjørn and R. Moustafa, “Challenges with lack of trust in agile projects with autonomous
     teams and fixed-priced contracts,” in ACM International Conference Proceeding Series, 2018, vol.
     147763, pp. 1–5.
[9] B. Shahzad, K. M. Awan, M. Ikram-Ullah Lali, and W. Aslam, “Identification of Patterns in Failure
     of Software Projects,” Journal of information science and engineering, vol. 33, no. 6, pp. 1465–
     1480, 2017.
[10] I. Mergel, Y. Gong, and J. Bertot, “Agile government: Systematic literature review and future
     research,”      Gov    Inf     Q,    vol.    35,   no.    2,    pp.    291–298,    2018,     doi:
     https://doi.org/10.1016/j.giq.2018.04.003.
[11] The standard for project management and a guide to the project management body of knowledge
     (PMBOK guide)., Seventh edition. 2021.
[12] “Directive 2014/24/EU of the European Parliament and of the Council of 26 February 2014 on
     public procurement and repealing Directive 2004/18/EC,” European Parliament, European
     Council, Jan. 01, 2022.
[13] K. Beck et al., “Manifesto for Agile Software Development,” 2001. Retrieved March 6, 2023, from
     http://www.agilemanifesto.org/ .
[14] J. L. Cooke, Agile: an Executive Guide : Real Results from IT Budgets. Ely, UNITED KINGDOM:
     IT Governance Ltd, 2016. [Online]. Available: http://ebookcentral.proquest.com/lib/rtulv-
     ebooks/detail.action?docID=4519661
[15] A. Ribeiro and L. Domingues, “Acceptance of an agile methodology in the public sector,”
     Procedia         Comput       Sci,      vol.     138,     pp.       621–629,     2018,       doi:
     https://doi.org/10.1016/j.procs.2018.10.083.
[16] K. Balka, B. Heslin, and S. Risse-Tenk, “Unlocking the potential of public-sector IT projects,”
     McKinsey & Company, 2022.




                                                   16