Applying Scaled Agile Frameworks in a Small Company to Engage in Large-Scale Software Development Projects as a Supplier

(1)

Applying Scaled Agile Frameworks in a Small Company to Engage in Large-Scale Software Development Projects as a Supplier

Raimo Ainla

Bachelor’s Thesis Degree Programme in

(2)

Abstract

29 November 2018

Author(s) Raimo Ainla

Degree Programme in Business Information Technology Report/thesis title

Applying Scaled Agile Frameworks in a Small Company to Engage in Large-Scale Software Development Projects as a Supplier

Number of pages and appendix pages 44 + 7

Having been successfully adopted in many different fields, agile is becoming increasingly popular. In order to build on the tangible success of traditional agile, for instance in customer-centricity, several frameworks have been developed for larger scale, such as Scaled Agile Frameworks (SAFe). Larger-scale agile transformation has been researched, however the topic of smaller supplier companies fitting into SAFe has not yet been studied ad- equately. The paper attempts to fill the research gap mentioned. Several large-scale agile methodologies are considered in the theoretical background, however the main focus of the study is SAFe. The aim of the research is to map out areas of strength and weakness of the company in taking part in projects as a supplier utilizing SAFe.

The main questions that the empirical research answers are: to what extent do the company values agree with those of agile; what are the capabilities of the company in engag- ing in large-scale agile projects as a supplier. One of the included studies employs mixed methods in the form of a questionnaire, having mostly closed-ended questions, in order to give a more accurate picture of certain performance indicators. The rest of the research is qualitative, having open-ended questions, in order to highlight common themes. Results will be analyzed accordingly, with statistical figures presented for the closed-ended questions as well as a thematical analysis provided for the open-ended questions.

The findings indicate that the company possesses strength in certain key areas that are considered important for agile, such as: management support, flexibility to change and customer involvement. However, the company also displays noteworthy shortcomings in the matter: a lack of coaching and training of agile values; weaknesses in the cross-functional aspect of teams; inconsistencies in the processes, tools and practices across the company. Therefore, the company can do well in projects where the scope is smaller and the iterations shorter. Yet, it is not quite ready to take on larger-scale projects using SAFe as a supplier, before improving on the vital areas mentioned.

The thesis can be a valuable asset in mapping the readiness and capabilities of a company in both traditional agile as well as large-scale agile. Also, it can help a company pinpoint the critical areas needed for greater customer satisfaction, higher operational efficiency and thus advancing the competitive position on the market.

Keywords

Software Development, Agile, Lean, Systems Thinking, Scaled Agile Frameworks

(3)

1 Introduction

The main goal of the thesis is to carry out a study in a small-to-medium sized digital marketing and software company on the use of Scaled Agile Frameworks. In the research, the experiences of the employees in past projects that have applied agile methodology are analyzed. The experiences reflect the successes and failures of past agile projects, which are investigated and elaborated on. Therefore, the performance of the company is evaluated against the core principles of agile. Based on the latter, the research investigates what the requirements of applying Scaled Agile Framework (SAFe) methodology in either software development, digital marketing projects or business strategy consultations are.

Consequently, the research examines the preparedness and the capacity of the company for larger-scale agile projects in terms of, for instance, the roles of team members, team structure, industry-specific expertise, business processes and management support.

Ultimately, this study focuses on the relevancy of experiences of past agile projects on de- termining to what extent the company is prepared to participate in larger-scale agile software development or various marketing consultation projects, especially regarding SAFe.

The study does consider several of the most common frameworks of scaling agile projects, however, it mainly focuses on the SAFe methodology.

The company in question is in the field of digital marketing and operates in Finland, Swe- den, Norway, Denmark and Poland. The main headquarters is located in Helsinki, Finland.

In this report, the name of the company or other details related to projects have not been disclosed due to privacy concerns. The researcher is employed by the company at the time of writing this report. The type of projects at the company that are a part of this study can belong to, for instance, digital marketing execution, software development, business strategy consultations. The company's role in customer projects, to name a few, is to develop software, the execution of digital marketing, business strategy or insight consultation, graphical design and media production. For digital marketing and software, the business units and teams that are responsible for customer experience and brand strategy, often collaborate with the digital teams, as the company is an advocate of transparency and alignment within the organization. The customer projects at the company can often be part of a cross-industry service, where for example business consultation is paired with analytics or the implementation of online advertisements. Also, for example, software development teams often work together with media artists or business consultants, to meet the growing demand of the customers to bring about digitalization or growth. Regarding

(5)

software development, the company has also been part of slightly bigger software development projects for its customers in different fields, such as healthcare, fashion, energy, wholesale, sports. At its core, the ethos of the company is to bring about business growth, success and positive effect as a result of improving the processes, services or the brand strategy of the customer. The company also believes in customer-centricity, regardless of the type of project or customer. The ultimate goal, as it were, that the company aspires to, is to help the customers of the company reach their end-customers in terms of sales and thus improving their efficiency and productivity.

It is worth mentioning that at the company, as far as agile projects are concerned, projects with customers from different industries require specific approaches, based on the needs of the customer. The agile ways of working can differ, depending on, for instance, the structure of the customer company, goals of the project, teams involved and resourced al- located to the project. Generally, in software development, the approach tends to be more in line with Scrum, however strict adherence to a certain method is atypical. Also, elements from Kanban and eXtreme Programming (XP) are applied in most projects. In digital marketing, the applied agile method could be either Scrum, XP or Kanban. Often, it can also be a mixture of the three. In business consulting, where agile is applied, elements of Kanban are utilized most often. Nonetheless, for the majority of projects, a hybrid method consisting of the most common agile development practises are exercised.

The project has been set in order to provide value for the company, so to gauge the performance of the teams utilizing agile as well as assess the readiness to engage in larger- scale agile projects. In addition, the research is conducted with the intention of enhancing the workflow, bringing higher customer satisfaction and optimizing the project management practices. Accordingly, the objective of the project is to bring awareness of problem areas as well as to provide steps in how to improve the company’s readiness and compet- itiveness on the market in terms of agile know-how and practices.

1.1 Significance of the study

After the outset of agile in 2001, with its idea to favor individuals and their interactions over processes and prioritize collaboration with customers, its different implementations have been widely accepted and adopted in many different industries (Agile Manifesto, 2001). The success and benefits of Agile can be seen in many different fields, including

(6)

needs, agile is always focused on results (Machuca, 2018). When adopting agile, projects tend to be much more versatile, objective-oriented, customer-centric and transparent (Ma- chuca, 2018). In Larman and Vodde’s book, titled Scaling Lean & Agile Development, they define being agile as the ready ability to move with quick and easy grace (2009). This statement describes the idea to embrace change, to compete through adaptability and being able to change more quickly than the competition can. On top of that, faster delivery and higher quality can be achieved. The raison d’être of agile, implemented either on a big or small scale, remains agility, or the ability to change and to be flexible. (Larman &

Vodde, 2009.) When implemented correctly, agile innovation can certainly result in higher productivity, morale, faster time-to-market, better quality and lower risk than traditional approaches (Harvard Business Review 2018, 16). Significant motivators for agile transformation, especially in large companies, have been: issues regarding software project management (Long and Starr, 2008), the challenge of people management and managing schedules (Chung and Drummond, 2009). If a company chose to launch many agile teams, could whole segments of the business benefit from agile? Yet in practice, implementing this change in different parts of the business can be challenging, given that it is becoming increasingly common to either outsource parts of software development or even to hire external companies to be a part of the bigger solution. Furthermore, it is crucial to address what is needed for instance for smaller or medium-sized vendors and suppliers to participate in larger-scale agile customer projects, while preserving the benefits of agile and maintaining the needed efficiency in the bigger picture.

In the XP2010 conference, a backlog of topics was created of questions that industrial practitioners thought ought to be studied (Freudenberg and Sharp, 2010). According to Freudenberg and Sharp, the question that received the most support was “agile and large projects” (2010). Over the past 17 years, there are numerous studies, methodologies and frameworks that have been developed to address a growing need to cater to larger-scale projects while preserving the benefits of agile. As Paasivaara, Dikert and Lassenius point out in their systematic review of large-scale agile development, the topic had not yet been comprehensively studied at the time of writing their article (2016). There is research on the topic of large-scale Agile transformation or case studies on how certain companies have applied different methodologies on large-scale agile projects (Paasivaara, Dikert, Lassenius, 2016). Regardless, the topic of how smaller companies as suppliers are af- fected in SAFe, has not yet been studied to a significant extent.

As one of its core goals, SAFe aims to overcome the above-mentioned challenges – how to provide the benefits of agile and optimize the workflow on a larger-scale (Leffingwell, 2017). In this research, the scope is largely SAFe, where some parts of more traditional

(7)

agile models are also analyzed. What SAFe attempts to accomplish, Kruchten argues, is not to introduce yet another agile process to add to the long list of existing ones, but to show how to scale these agile approaches beyond their existing sweet spot (2007, in Leff- ingwell 2007, 18). Also, the principles of SAFe add to the lower-level practises, such as found in Scrum, by extending it with a set of practices that reside in the higher level, both technical and managerial (Kruchten, 2007, in Leffingwell 2007, 18). As mentioned above, one of the goals of SAFe is to tie all the best practises of agile together and expand on them to craft a model that suits larger-scale projects. By so doing, it claims to shorten time-to-market, produce higher return on investment and increase customer satisfaction.

(Leffingwell, 2007, 25). Therefore, this research is a crucial means to aid and provide tools for overcoming the significant challenge of successfully adopting the above-mentioned practises in smaller to medium-sized companies and teams, especially as a supplier company. The study gives insight on how smaller companies and organizations could be more successful in partaking in larger agile projects as well as contributes to the success of the whole value stream in the big picture.

The benefits of this research are not limited to only small and medium-sized software development companies or teams looking to improve their practices and organizational flow.

The findings of this study could also be utilized by, for instance, larger-scale companies practising agile, which have not yet reached the peak of their efficiency. Also, the research process or the findings of it could be advantageous for academic purposes in educational institutions. The implications of the results of the study may be relevant for other industries and areas of expertise, as well. Regardless, the primary focal point of this study is software development and the implementation of SAFe, as opposed to other methodologies.

1.2 Research questions

The study question has been explored by employing the following research questions below, where participants are expected to rate to what degree they agree with the statements (appendix 1). The questionnaire is based on the Likert scale, from 0 to 4, where 0 indicates that the participants disagrees completely with the statement and 4 indicates that the participant completely agrees. If the question is not a statement, the participant is expected to give an answer, where 0 indicates negativity and 4 positivity.

(8)

The main summed up questions or topics that the research questionnaire presents to the respondents are:

− To what extent are the organizational culture and values in line with the values and practices of agile.

− Therefore, what are the capabilities and capacity of the company to successfully participate as a supplier in large-scale projects utilizing SAFe.

(appendix 1.)

Also, findings of an externally conducted employee satisfaction questionnaire are analyzed, in order to highlight possible areas of growth and improvement that could affect the performance and capability of the company to partake in agile projects.

The questions of the external research that are included in this study are:

− Please list what you consider to be unifying and separating factors at the organization level.

− Areas needing change in client and project work structures.

(table 4; table 5; table 6.)

2 Theoretical Background

In this section the theoretical background of the main concepts in this research is presented. Firstly, classic agile is introduced. Secondly, the most well-known methodologies and frameworks for large-scale agile are introduced in more detail, as they build on the success of traditional agile. Finally, the chapter looks at the core principles of SAFe and how it is used in different projects, especially in software development. Also, the strengths and weaknesses of each of the methods are discussed.

(9)

2.1 Traditional Agile

Figure 1. Agile workflow (Ivanecky, 2016)

Agile is an iterative, yet incremental way of carrying out different types of projects, such as software development (figure 1). Work is divided into small tasks and time-boxed events, usually referred to as iterations or sprints, rather than delivering the work all at once (Agile Alliance, 2018; figure 1). With the most popular applications of agile being XP, Kanban, Scrum, Feature-Driven Development (FDD) and Lean Software Development, these iterative and incremental approaches have been used widely over the years (Leffingwell, 2007, 6). In Scrum, the most used agile method, three roles are called for in a team – the Prod- uct Owner (PO), a Scrum Master (SM) and a cross-functional team. The work is managed through four artefacts: a product backlog, a sprint backlog, a product increment and defini- tion of done. In Scrum, it is expected that the leadership is engaged enough to provide a broader vision for the project as well as supporting the self-organizing teams. (Vaidya, 2014, 2.)

In Kanban, however, the practices are defined in a less specific manner. Generally, a Kanban board is used, which visualizes the project progress and workflow, with different statuses for each task. In addition, the work is carried out by imposing a work-in-progress limit for each step located on the Kanban board. Similarly to Scrum, a self-organized team and involved leadership are expected to co-operate in Kanban. (Vaidya, 2014, 2.)

Extreme Programming (XP) is an agile methodology that encourages frequent version releases in short development cycles. XP builds heavily on the idea of teamwork, given that the development team is regularly expected to perform pair programming and negotiation.

Also, it encourages communication between managers, customers and developers, as customer involvement and satisfaction are one of its paramount attributes. (Educba, 2018). In practice, many agile development implementations combine Scrum and XP in some way (Fitzgerald et al., 2006).

(10)

While the benefits of agile are still debated in some societies or schools of thought, there is a clear trend towards going agile and applying extreme methods (Leffingwell, 2007, 6).

As mentioned earlier, the benefits of the agile approach, such as faster time to market, better responsiveness to changing customer requirements and higher quality are undenia- ble, especially in the software development industry (Leffingwell, 2017).

2.2 Other Common Large-Scale Agile Methodologies

One of the main challenges with more traditional agile approaches, such as Scrum, is that it is very well-suited for smaller projects with teams of limited size (Eickmann, 2009). Most agile methods are primarily recommended to smaller teams and environments due to their nature and structure (Leffingwell, 2017). Moreover, in more popular agile ways of working, such as Scrum, it is more difficult to measure progress than in waterfall, as progress is spread out across cycles. The latter further complicates scaling to bigger projects. (Olic, 2017.) Are the benefits of agility thus unattainable to larger software teams or projects?

Can these principles be applied to larger-scale development or marketing projects that require hundreds of team members? In terms of the structure, different roles, actors and teams, it is quite typical in a larger-scale agile project, that certain parts of the work are outsourced (Leffingwell, 2017). If a smaller company or team is hired to play a certain role in the larger project, it is certainly prudent to carefully consider the requirements and expectations that concern the outsourced teams or companies.

Paasivaara et al. define large-scale projects as those that include at least 50 people and 6 teams, based on a systematic literature review the authors have published (2008). In the 12^th annual State of Agile Report, one of the most common methodologies for scaling Ag- ile are reported to be: SAFe, Scrum of Scrums, Disciplined Agile Delivery (DAD) and Large-Scale Scrum (LeSS) (Versionone, 2018). In the past 10 to 15 years, there have been a number of rather successful cases of scaling up agile methods (Leffingwell, 2007, 7). In BMC software, during a very large-scale agile project, productivity was reported to have gone up by a large margin (BMC and Rally, 2006). In Larman & Vodde’s Scaling Lean & Agile Development, an example of a successfully scaled agile project is mentioned, which took place at Yahoo (2009, 325). Over a period of more than three years, over 200 teams were migrated to large-scale Scrum. There was a significant boost in productivity, team morale, adaptability, accountability and collaboration reported. (Larman

& Vodde, 2009, 326.) The method in question, as argued by the authors, is LeSS (2009,

(11)

289). Based largely on § & Vodde’s work, LeSS specifies organizational changes, which aren’t addressed in standard Scrum (2009, 326). Larman & Vodde define LeSS as argua- bly being a larger-scale version of Scrum, including an additional set of tips and best practises (Larman & Vodde, 2009). By eliminating the traditional team lead and project manager roles, LeSS advocates cross-functional, cross-component and end-to-end feature teams.

Figure 2. Large-Scale Scrum for up to 10 teams with One Product Owner (Larman &

Vodde, 2008)

The LeSS framework recommends two frameworks. Framework-1, where a product owner is common to all teams, should be used for solutions of up to a 100 people. The framework-2, however, scales up using sets of framework-1 groups. For framework-1, three more practices are introduced. The Inter-team coordination meeting can be organized in different formats, mainly consisting of a Joint Light Product Backlog Refinement and Joint Retrospective meeting (figure 2). The Scrum Masters and one representative for each team identify and plan improvement experiments for the organization (Larman & Vodde, 2013). In framework 2, all the framework-1 meetings continue for each product area. The pre-sprint product team meeting is introduced, where product-level sprint review meeting view is held (figure 2). Also, an overall sprint retrospective meeting is organized with different team representatives present (figure 2; Larman & Vodde, 2013). LeSS gives several valuable insights on how to scale agile operations, however, it doesn’t fully address certain concerns. Namely, having a single product owner for up to ten teams can prove challenging as the attention is shared between the teams (Vaidya, 2014, 10). This case study is perhaps not a universally ideal way to scale agile, as there are limitations on how many teams it can support. Nonetheless, it can serve as a necessary building block for valuable experience on the topic.

Another widely-adopted framework is Scrum of Scrums (SoS). It is recommended that the methodology would be used for teams of 5-10 (Agile Alliance, 2018). The intention of SoS is to help coordinate and synchronize the work of multiple Scrum teams so that common goals could be achieved more easily (Bowes, 2016). The meeting is called Scrum of Scrums, which aims to do the coordination work (Agile Alliance, 2018; Bowes, 2016). The meeting allows clusters of teams to encourage a discussion about their work, especially on overlap and integration (Cohn, 2007). The focus of SoS is on aiding the development team members to coordinate and collaborate in a self-organized manner, without it be-

(12)

approach is that each daily scrum within a sub-team ends by designating one member as a so-called ambassador to partake in a daily meeting with such ambassadors from other teams (Agile Alliance, 2018). Often, the person chosen is a technical contributor – for instance, a programmer, tester, database administrator, designer. A challenge that persists with the SoS meeting, is that it is frequently kept rather short. With the meeting being short, not enough time or consideration is necessarily given to certain type of issues, such as those that happen on the lower level. Especially if the number of ambassadors is large, the way of dealing with issues becomes more complex. (Cohn, 2007.)

While the SoS technique can be a relevant way of scaling Scrum in a large organization or setup, it’s insufficient in and of itself. The main drawbacks of it are the limit on the number of developers and teams it supports. Also, self-organization of teams remains a challenge in a bigger setup. (Bowes, 2016.)

An analysis of agile companies by Berruti, Chandratre and Rab reveals that there are many complications when applying agile methodologies to digital environments, especially in larger and more complex settings (2018). It is increasingly difficult to integrate modern tools and technology, such as Artificial Intelligence (AI) and automation, with the scope becoming untenable, McKendrick argues (2018a). Jeffries, one of the co-founders of Agile Manifesto, goes as far as to say that the Agile Manifesto has been used to put more pressure on developers to ‘pump’ out sustainable results even faster, raising the intensity of a pressure cooker environment (in McKendrick, 2018b). In a modern environment, where companies are increasingly adopting agile at a larger scale, more challenging hurdles emerge.

In Dikert, Paasivaara and Lassenius’ systematic literature review, several hindrances and obstacles to large-scale agile adoption are listed (2016). For instance, one of the most significant differences between small and large agile project adoptions is the number of de- pendencies between projects and teams (Dikert, Paasivaara & Lassenius, 2016). There- fore, the adoption of agile, especially at scale, often requires change of the entire organizational culture (Misra et al., 2010). In Dikert, Paasivaara and Lassenius’ research, the main success factors as well as challenges are identified as: general resistance to

change; scepticism towards new way of working; unwillingness to change in management;

lack of training and coaching; following old ways of working; misunderstanding of agile concepts; lack of guidance; coordination challenges in multi-team environments; global distribution challenges; different interpretation of agile between teams; management hierarchy; keeping internal silos; high-level requirements management missing; estimation of user stories; quality assurance; unclear roles (2016). On the other hand, some of the more

(13)

notable success factors were listed as: management support; education of agile within the management; commitment to change; engagement of change leaders; picking the most suitable agile approach; abundance of agile coaching; engagement throughout the organization; clear communication of process management and the agile change thereof; con- centrating on agile values; alignment of organization; self-organization and empowerment of teams; emphasizing the crucial role of the product owner. (Dikert, Paasivaara & Lasse- nius, 2016.)

2.3 SAFe

All the benefits and strengths of agile notwithstanding, it is not necessarily simple to take any of the large-scale methodologies into use, let alone master. A research titled the State of Agile survey, mainly looks at employees of large organizations that have adopted agile (Versionone, 2018). The study brings out the reasons for adopting agile, which apply to both smaller-scale as well as large-scale companies. The top reasons for adopting agile were reported to be: speeding up software delivery; managing changing priorities, maxim- izing productivity; to better align IT or the business; improved software quality. (Ver- sionone, 2018.) To fulfil the above-mentioned requirements and achieve the stated benefits, meticulous customization is needed to achieve efficacy across the solution and make the approach suit the needs of the organization (Dikert, Paasivaara & Lassenius, 2016).

Depending on, for instance, the structure, nature, size and industry that the company operates in, a suitable methodology or approach is indeed essential. Also, as Leffingwell points out, simply following certain recommended practises does not necessarily address the must-win battles of a company looking to scale up their Agile operation (2007, 7). To create the Agile enterprise, additional work is required. Therefore, for a company to achieve more benefits regarding software agility, especially those with large, distributed teams, certain crucial practices are to be followed. Instances of such could be: intention- ally set up architecture; harmonizing the vision and the roadmap of the company; having a process in place to manage different value streams and guiding both physically co-located teams and highly distributed ones (Leffingwell, 2007, 8). The above-mentioned practices are part of SAFe, addressing the challenges that certain other frameworks do not. In terms of practical application, the application of SAFe is followed by an increasing number of companies, being the most widely-used approach for larger-scale agile projects (Ver- sionone, 2018).

(14)

SAFe is defined as a framework that aids businesses in addressing the most notable challenges of developing and implementing software and systems in the shortest sustainable lead time, on an enterprise scale. The approach builds on and combines the ideas of agile development, Lean-Agile leadership and systems-thinking, forming a framework that specifies a set of principles, best-practices and a body of knowledge on how to bring the best of agile into larger projects. In the framework, alignment, collaboration and delivery for multiple Agile teams are synchronized. The fundamental benefit of SAFe is that it is ar- guably suitable to be used by up to thousands of people belonging to different teams. Re- gardless of its complex nature, SAFe takes into account and tackles important questions, such as: how to align the company toward the business and technical goals; improving the quality of solutions to the benefit of the customer; scaling operations to deliver value effi- ciently and avoiding delays as well as traditional bureaucracy; how to do away with exces- sive hierarchy; creating an environment that cultivates collaboration, innovation and continuous improvement. Moreover, addressing the above-mentioned challenges, the four core values of SAFe are defined as alignment, built-in quality, transparency and program execution. (Leffingwell, 2017.)

Figure 3. Full SAFe configuration (Leffingwell, 2017)

The largest SAFe configuration, Full SAFe, can be used by enterprises that build and maintain large integrated solutions, requiring hundreds of people to execute. The full configuration includes different levels, configurations and views: the team, program, large solution, and portfolio (Leffingwell, 2017; figure 3).

Firstly, the team level is a low-level organizational unit that is mostly responsible for developing features, releasing working software and following the common program increment time constraints (Leffingwell, 2017; figure 3). One of the most critical attributes for the development team is to ensure that quality is built into each solution element at every increment throughout the development. In fact, the philosophy of built-in quality applies to the whole system, across the entire value stream, effectively making it everyone’s job. (Leff- ingwell, 2017.) It is important to note that the work that the development team produces is built around the agile approach. The top three agile frameworks that are utilized in SAFe are XP, Scrum and Kanban. Alignment within the organization dictates that agile principles are followed throughout the enterprise. Thus, the work that development team deliv- ers is the basis to the team level, like an engine to a car. The agility achieved on the team level consequently lays the foundation for all other levels, to a large degree. (Leffingwell, 2017.)

(15)

The program level, on the other hand, is responsible for, among other aspects, DevOps, which is a mindset that provides communication, integration, automation and tight cooperation between all the actors of the solution (Leffingwell, 2017; figure 3). The most notable actors on the program level are, for example, business owners, system architects, product managements and release train engineers. More importantly, the events that are significant in the program level are: Program Increment (PI) planning event; System demo, which provides a view of new features by all the teams in ART; Inspection & adaptation – a noteworthy event where the current state of the solution is demonstrated and assessed by all the teams involved. The PI are typically 8 – 12 weeks long and the most common pattern for a PI is four development iterations. (Leffingwell, 2017.)

Figure 4. Cross-functional Agile Release Train (Leffingwell, 2017)

The heart and framework of SAFe are the team and program levels, which forms an organizational structure referred to as Agile Release Train (ART). Teams are dedicated to the ART and a potentially shippable increment (PSI) is synchronously developed and released (Vaidya, 2014, 9). Key stakeholders, agile teams, business owners and other resources all contribute to the ongoing solution mission. By delivering a continuous flow of value, the ART describes the teams, roles and activities, each delivering value incremen- tally. The ART operates using fixed-length iterations, which are defined within the program increment timebox. The most pivotal assignment that the ART focuses on is to define new functionality, implement, test and deploy. The ART as well as solution trains follow a synchronized and aligned program increment (figure 3). Therefore, if implemented correctly, the benefits of agile apply to the development team and in turn, the ART and the solution train. (Leffingwell, 2017; figure 4.)

The Large solution level refers to higher-level resources, such as solution architects, solutions managers and the solution train (figure 3). The solution train is an organizational construct, which tackles one of the most difficult tasks – building and delivering large- scale multidisciplinary software or systems. The solution train calls for the coordination of multiple ARTs, as it brings them into agreement with the solution vision, backlog and roadmap. Also, the solution intent, the repository for storing, managing and communicating the knowledge for the current solution is to be kept up-to-date and shared between all different ARTs and supplier(s), if applicable. More importantly, the role of suppliers, internal or external, can play a central role in solution development. (Leffingwell, 2017.)

(16)

On the portfolio lane, however, the high-level content authority is introduced, such as those that define business strategy, investment goals and vision (figure 3). It contains principles, practices and roles that are required to set up development value streams and meet the strategic objectives of the enterprise. The goal of the portfolio SAFe configuration is to help align high-level business processes and portfolio execution to the whole enterprise. The idea is to organize the entire agile development solution around the flow of value via value streams. The contributors of the SAFe portfolio level define the specific business objectives and value stream key performance indicators (KPIs). They also provide assessments of current state of the solution as well as address the strategic themes and facilitate business success. (Leffingwell, 2017.)

2.3.1 Suppliers in SAFe

Within a large setting, in the solution train, which is part of a bigger value stream, the smooth flow of operation is dictated by how well the different ARTs are coordinated. As Leffingwell points out, hiccups in the solution train could have unacceptable economic consequence, as it handles the roles, events, and artefacts necessary to coordinate complex and sizeable systems (2017). In addition to the other agents and actors on team and program level, suppliers are part of the solution train. A supplier could be defined as an internal or external company or another ART, which is an expert in a certain technology and can thus speed up the delivery of value for the organization. Suppliers partake in most solution trains, making the overall smooth operation of the organization revolve around their performance, as well. Therefore, suppliers play a critical role in SAFe. How they are integrated into the solution, however, is up to the organization and their setup.

Since external companies could have their own values and economical goals, it is paramount that close cooperation and trust is present for both the product-owning organization as well as the supplier company to achieve adequate performance. In practice, however, it can often happen that suppliers are frequently switched and kept at arm’s length from the enterprise’s processes and are shared information only on a need-to-know basis. As per SAFe, if the supplier has adopted Lean-Agile methodologies, they would be treated like an ART, cooperating with other ARTs in the solution train (figure 3). The suppliers would participate in PI planning and Post-PI planning meetings. Essentially, they are held accounta- ble for continuous delivery, akin to the ARTs within the product-owning company. The supplier is also expected to participate in the inspection and adaption event, to enhance the value stream as a whole and to cultivate their Lean-Agile practices. In effect, suppliers are expected to be involved in the development value stream on a regular basis. Provided

(17)

that the supplier is using traditional methodologies, more pre-work is needed. Also, it can be anticipated that the suppliers may have limited flexibility to accommodate changing requirements. (Leffingwell, 2017.)

In order to better work with the suppliers, the relationship and trust needs to be built.

Based on Liker and Choi’s work, the terms genchi genbutsu and gemba (actual location and actual parts or materials) are used (2004). The terms refer to the practice of having executives visit and identify the way in which suppliers work. Thus, to allow for timely integration and facilitate superior quality, suppliers and other ARTs are to collaborate closely by sharing common practices and information as part of the bigger solution. (Leffingwell, 2017; Liker and Choi, 2004.)

2.3.2 Metrics used in SAFe

In SAFe, various metrics are used to evaluate how well the organization is progressing in the goals that it has set. With SAFe, progress is more easily trackable and measurable, largely thanks to, for instance, work physics, timeboxes, fast feedback, feature cycle times and HR statistics. The primary measure of work efficiency in SAFe is the measurement of working solutions, as it is in the Agile Manifesto (Schwaber et al., 2001). On the portfolio level, there are other critical attributes that can be achieved through various metrics.

Examples of such could be employee engagement, customer satisfaction, agility, time-to- market and quality.

Figure 5. Lean portfolio metrics (Leffingwell, 2017)

Employee engagement is measured via different employee surveys and HR statistics.

Customer satisfaction is measured via net promoter score surveys. Productivity can be measured, for instance, with the help of the time that it takes to complete a feature cycle.

Agility, in turn, could be measured through self-assessments at different levels across the enterprise. Time-to-market, however, shares a direct correlation between the number of releases per annum by the ARTs. The amount of support calls, bug reports and time spent giving support could explain the quality of the released software. (figure 5.) Many organizations undergo a large-scale agile transformation, yet they face challenges measuring the progress made when compared to the goals set for the organization. In addition,

(18)

there are challenges communicating the expectations on what kind of results are anticipated. In Laanti’s study, she helps employees of a large company going through a SAFe transformation examine and realize the challenges, impediments and goals of said process (2017). Based on the results, an analysis of the current state is drafted as well as recommended next steps given, in keeping with the philosophy and principles of SAFe.

Essentially, this enabled the respondents and the company to pinpoint and map agility in the whole organization. The latter is a notable example of gauging and measuring different performance levels in a large organization following agile. (Laanti, 2017.)

2.4 Research Gap

According to Dikert, Paasivaara and Lassenius, the published number of scientific literature of different large-scale agile frameworks and their use cases is low (2016). Most of the primary studies conducted, if not all, are experience reports. Moreover, there seem to be few case studies published, too. Although many of the studies address the issue of the process of transformation to some extent, there is, regardless, not that much research conducted, having it as the primary focal point. (Dikert, Paasivaara & Lassenius, 2016).

Several prominent questions have not perhaps yet been entirely answered. In which way are and should these frameworks be used? To which kind of circumstances would each be suitable? How well can they be customized and tailored to the needs of the customer as well as the needs of the end-user? What are the downsides of each approach and how the company should overcome them? Most of the theory behind the frameworks does not necessarily address all the above-mentioned concerns, including those of SoS, LeSS and SAFe.

In a case study at Ericsson, the process of agile transformation of a globally distributed organization working on a large and intricate product is researched (Paasivaara et al. 2018).

The case gathers information on how a sizeable corporation takes agile into use as well as the steps needed for the change. Given that the organization had decided not to apply any well-known agile framework, the teams could operate and decide on how the work was carried out. In addition, the teams could determine the way in which the way agile was implemented and organized. Similarly, it is up to the large organizations adopting the change to tailor the frameworks and methodology to fit their specific needs. As agile methods usually provide little guidance on how agile teams are to interact with the environment in a large-scale setting, there are still aspects of the topic that have not yet been studied to a significant degree. Despite the relevance of the frameworks in helping businesses

(19)

grow and bring about more agility in their processes, it appears that academic research regarding how it pans out in practice is lagging behind. (Paasivaara et al. 2018.) Moreo- ver, the studies, publications and articles of research mentioned in this paper mostly con- centrate on the processes of the product-owning large-scale enterprise, without much focus on the supplier teams or companies. As mentioned above, within the solution train in SAFe, there are many different variables within a large enterprise that are a part of the solution in the big picture (figure 3). Most of the work carried out in this field do not directly address the way in which the transformation process and ways of working thereof ought to be carried out by the different actors in the solution train. It is especially the case with different vendors, agents, outsourced companies and suppliers.

As mentioned earlier, suppliers partake in most solution trains, which means that their performance affects the solution train to a large extent (Leffingwell, 2017). In the State of Ag- ile survey in 2018, 45% of the respondents reported using agile practices to manage outsourced development projects (Versionone). 40% of responded that they were planning on expanding the adoption of agile in outsourced projects in the upcoming 2 years (Ver- sionone, 2018). Given that the use of suppliers, experts in their field, is in demand, the lack of information of how smaller suppliers tie into SAFe should be addressed.

Therefore, more research is needed on how smaller companies and organizations could be more successful in partaking in larger agile projects as well as contribute to the success of the whole solution. In addition, the success factors and challenges of it could bring valuable insight to a range of industries, especially to software development.

3 Research Methodology

The company in question works with a variety of customers in a range of different industries, such as software development, business strategy, graphical design, digital marketing and media production. Due to the variety of the types of customers, the nature of the projects varies, too. In terms of business strategy and consultancy projects, a more traditional Software Development Life Cycle (SDLC) model can be utilized, such as the Water- fall model (Lucidchart, 2017). Regardless, there are also business strategy projects which are more in line with Agile values and practices. Due to the latter not necessarily pertain- ing to the software development industry, the terminology related to the methodologies used can differ. As far as software development and digital marketing projects are concerned, they almost exclusively work with Agile methodologies. As the company is small or medium-sized, the projects it undertakes tend to be smaller in scale. In fact, there have

(20)

been a lot of smaller successful software development projects, contributing to the growth of the company.

Often, prior to the commencement of software or digital marketing projects, customers re- quest an estimation of, for instance, the resources required to complete the project. It is then decided at the company whether it is feasible to take on the project at all. There have been instances of rejected projects, for example, since they require more resources to complete. Also, certain software projects as suppliers have been rejected either due to insufficient experience in larger-scale agile projects or not employing enough developers.

Regardless of the reason of rejecting projects, the limiting factors or fear of certain type of projects could prove detrimental to the opportunities in growth for the company. As the company has made significant growth in the past 2 years, the research on how to better prepare for being a supplier in larger-scale agile projects, and as improving its agile practices may provide a great deal of value for the company.

3.1 Methods selected

The internal research, referred to as research A (table 1), is carried out as a mixed methods research study (Yin 2011, 133). The empirical part is drafted as a structured quantita- tive survey in the form of a web survey with mostly closed-ended questions where attitudes of the employees at the company in question are measured (Lavrakas, 2008). As there are mostly closed-ended questions and one open-ended question, the results are analyzed using qualitative methods. (Yin 2011, 292.) The replies given by the respondents are analysed so that each Likert item has a summed score to provide an average measure of the overall replies given. The results of each question in the survey are evaluated and compared against the core values of agile as well as SAFe. The results of the empirical research are presented and summed up in a table (table 2). The individual charts are also in the appendix (appendix 1). There are also mathematical calculations done in Mi- crosoft Excel, which are also presented in the appendix for each question (appendix 1). In addition, there is a thematic analysis carried out for the open-ended question, to bring out different themes, categories and points that emerge from the responses (Braun & Clarke, 2006).

Table 1. Structure and overview of the research conducted

(21)

Research Number of respondents

When it was conducted

Researcher Other Comments

Research A (internal)

20 October 2018 Author of the thesis

Mostly closed-ended questions with some open-ended questions Research B

(external)

95 December

2017

External research agency

Open-ended voluntary questions (not everyone filled them)

Being based on the Likert scale, from 0 to 4, the objective of the questionnaire is to rate to what degree the participants agree with the given statements (appendix 1). Each Likert item utilizes a symmetrically balanced negative-to-positive response, indicating different extents to which the respondents can agree. Most questions inquire whether the respondent agrees or disagrees with the question, expressing an attitude or opinion. The questions use fixed choice response formats, assuming that the experience or opinion can be measured in a linear scale utilizing progressive steps. Respondents were offered a choice of five responses, where the middle option usually expresses neutrality or a lack of strong opinion or attitude in the questions. In terms of the results, points are given from 1-5, where the response 0 corresponds to 1 point and the response 4 corresponds to 5 points.

In addition, there was an external research carried out by an independent research company in the organization in question, mostly referred to as research B. The survey was an online survey questionnaire based on a mixed survey format, with mostly closed-ended questions. Some of the questions were open-ended, where the employees were asked their experiences or opinions on certain matters. The latter are included in this study. The research was anonymous, where only the level of experience of the employee was asked – either junior, senior or manager. The survey was conducted in December 2017, with around 95 respondents participating in the survey (table 3; table 4; table 5).

The main objective of the study of research B was to research the working culture at the target organization including the study of employee satisfaction. Secondly, the employees were asked to rate the most important factors in their daily working life as well as their most prominent career goals. In addition to a range of secondary topics, there was a pos- sibility for the respondents to answer an open-ended question about themes and aspects of the organization that required change or improvement in their opinion. It was also possi-

(22)

ble to leave general or more particular feedback about the topics. The open-ended feedback is interpreted through a thematic analysis in this research to bring out possible improvement points and problem areas that relate to customer projects (Braun & Clarke, 2006).

As the company where the research is carried out in is a rather small company, there are not many respondents. Due to the amount of responses being low, a qualitative analysis method is better suited in order to illustrate and explain the responses. A traditional qualitative survey with only open-ended questions would not have provided the most accurate measure of the experiences. As pointed out above, the goal of the internal research was to determine the performance of the company in the mentioned areas. Therefore, it felt prudent to draft the survey using mostly closed-ended questions, as it is less complicated to analyse the data and draw conclusions on the topic at hand. In this case, a closed- ended survey questionnaire helps provide a more accurate picture into the attitudes or opinions of the respondents on their experiences at the company. Based on the results, the given methodology and the use of a Likert scale aids in mapping problematic areas and challenge factors in adopting SAFe as a supplier. A mostly closed-ended mixed research utilizing qualitative analysis also better highlights possible shortcomings and facets of the company structure and as culture in achieving the research objectives.

3.2 Surveys

With the primary objective of studying the capabilities and preparedness of the company to participate in larger-scale agile projects as a supplier, the empirical study of research A was carried out by the researcher. Also, the extent to which the company values match with agile principles were studied. The major focus of the research in terms of the larger- scale agile methodology studied was SAFe. The survey was conducted in a structured manner, as mentioned above, by asking members of different teams to participate. The survey questionnaire was anonymous, with no indication of the identity of the respondents. Employees with experience in agile projects or projects that had employed agile practices at the company in question were selected. Thus, the primary target group of the survey was the software development team as well as employees who had experience in for example, project management, account management, business consultancy, media creation and digital marketing execution. Most of the employees at the organization who are included in the research have an experience of 2-3 years within the company. A smaller number of employees have an experience of 4-5 years within the company. The

(23)

employees of lower-level teams, such as software developers and digital media market- ers, have a better understanding of the processes, methodologies and practices within the projects. The managers, coaches and team leaders, on the other hand, have a broader overview of the organization. Also, the higher-level employees have more insight on the project specifics and customer relations. Employees at different levels of the organization, with varying skills and backgrounds were asked to fill the survey. Consequently, a more well-balanced view of the experiences and projects at the company was given.

The data collection of research A took place in October 2018 through the use of an online survey questionnaire. A total of 20 respondents had answered the survey at the time of writing the research paper. The questionnaire was sent to firstly the software development team. Secondly, it was sent to project management, digital marketing teams and media teams. Thirdly, it was shared to be filled by business consultants and people of other teams, such as management. Then, it was posted to a general board of information, asking volunteers who had participated in agile projects who had not yet filled the survey to do so. (appendix 1.)

3.3 Research Questions

In research A, before the survey questions, a brief introduction on the main concepts, such as agile and SAFe, was presented. The full list of questions is listed in the appendix (appendix 1). The summed up main research questions in the survey questionnaire were:

− To what extent are the organizational culture and values in line with the values and practices of agile.

− Therefore, what are the capabilities and capacity of the company to successfully participate as a supplier in large-scale projects utilizing SAFe.

(appendix 1.)

Also, findings of an externally conducted employee satisfaction questionnaire are analyzed, in order to highlight possible areas of growth and improvement that could affect the performance and capability of the company to partake in agile projects. The questions of the external study, research B, which are included in this study are:

− Please list what you consider to be unifying and separating factors at the organization level.

− Areas needing change in client and project work structures.

(24)

(table 4; table 5; table 6)

3.4 Limitations, Scope and Validity

As mentioned above, the research A primarily tackles traditional agile; methodologies per- taining to agile in general; larger-scale agile frameworks. The most significant portion of the research narrows down on SAFe, whereas other alternatives to large-scale agile are introduced and evaluated in the theoretical part. Regarding the employees who filled the survey, the main goal was to involve lower-level professionals, such as software developers, media artists, business consultants. This research did not involve people of other po- sitions, such as HR, accounting or company executives. As most of the respondents were software developers, the implications of the research are therefore inclined to mainly apply to the software development industry. Regardless, some relevance to application in cross-industry and multidisciplinary fields can be observed. It is also worth noting, as mentioned earlier, most of the software development projects have not strictly followed any one given agile methodology, such as Scrum, XP or Kanban. Most projects, if not all, have applied principles, ideas and practices that are a mixture of the three. Thus, a more customized and mixed approach in terms of the aforementioned methodologies has been utilized in the projects. So, this study does not explicitly concern an organization’s transformation or the improvement process of any one traditional smaller-scale agile methodology. Consequently, research A does not discuss the pre-work that is needed for an organization to carry out, provided that the supplier does not follow Agile. Also, the study does not necessarily cover the transformation process of using any other large-scale framework, except SAFe.

It is possible that the views or experiences of the respondents run some risk of appearing biased, due to perhaps, personal opinions or social pressure, even though the survey was anonymous. The questions were written in a manner where the true opinion of the respondent is asked, rather than the correct answer. The small likelihood of respondents demonstrating acquiescence bias, however, cannot be ruled out (Sarniak, 2015).

In terms of the number of respondents, which was 20, the study included a relatively small number of people. However, due to the size of the company, the small sample size was expected.

(25)

Therefore, the strength of this research is to provide insight into the current state, future opportunities and ways in which an organization could be better prepared to apply large- scale agile methodologies or participate in them as a supplier company. However, the limitations of this study are ultimately narrow focus on one large-scale agile methodology, smaller sample size of the respondents as well as a distinct emphasis on software development.

4 Results

The results of the closed-ended questions are varied. A few of the questions received 19 submissions, whereas the vast majority of the questions received 20 submissions, which was the highest number of responses. As far as research A is concerned, questions 1-6 in the survey relate to classical agile and the performance of the company in its key areas.

Research questions 7-15 in the survey relate mostly to SAFe, whereas some questions may also share relevance with traditional agile. Question 16 in the survey asks for general feedback relating to both topics at hand plus to the survey itself. The main statistical figures for questions 1 to 15 of research A are presented in the table below (table 2). The thematic analysis for question 16 of research A is presented in a table, as well (table 3).

All questions of research A, along with the individual submission values of each respondent can be found in the appendix (appendix 1).

All three questions of research B pertain to the overall structure and operation of the company. The questions of research B are also stated in the tables that include the thematic analysis. (table 4; table 5; table 6.)

4.1 Traditional Agile

Table 2. Research A: Statistical figures of answers survey questions (RQ 1-15) of the internal research on agile and SAFe

(26)

Research Question

Points Arithmetic Mean

Standard Deviation

Submissions

RQ 1 60 3 0,86 20

RQ 2 71 3,55 0,69 20

RQ 3 71 3,55 1,05 20

RQ 4 45 2,25 0,91 20

RQ 5 58 2,9 0,97 20

RQ 6 64 3,2 1,1 20

RQ 7 53 2,79 0,79 19

RQ 8 62 3,1 0,79 20

RQ 9 58 3,05 0,97 19

RQ 10 65 3,25 0,72 20

RQ 11 68 3,4 0,88 20

RQ 12 71 3,55 0,83 20

RQ 13 65 3,18 0,79 20

RQ 14 64 3,2 0,89 20

RQ 15 71 3,55 0,51 20

Of the traditional agile part of the survey of research A, the first question, “1) Based on past projects and experiences, the organizational culture and values have been in line with the values of the Agile Manifesto. [Please select a value]” had 20 submissions. It received 60 points, the mean was 3 and the standard deviation was 0,86. The lowest point given was 1 and the highest one was 4.

The second question, “2) Based on past projects and experiences, the organization’s adaptability and flexibility to change has been: [Please select a value]” received 20 submissions. The question was answered by 20 employees. The points received were 71, whereas the mean was 3,55 and the standard deviation was 0,69. The lowest point given was 2, whereas the highest point given was 5.

Question number three, “3) Based on past projects and experiences, the management

(27)

support overall to the working team(s) has been: [Please select a value]” received 20 submissions, with an overall score of 71 points, mean of 3,55 and a relatively high standard deviation of 1,05. This means there was a high dispersion between the different values of points received. The lowest score received was 1 and the highest one received was 5.

For the fourth question, “4) Based on past projects and experiences, there has been enough coaching and teaching of agile principles to stay in line with Agile values and concepts (or project management principles that are in line with agile values) [Please select a value]”, the highest amount of points given was 4 and the lowest was 1. The points received were the lowest among the questions – 45, the mean was 2,25 and standard deviation was 0,91. There were 20 submissions for this question.

The fifth question, “5) Based on past projects and experiences, the practices, processes and use of common tools in work delivery have been consistent throughout a project, across teams. [Please select a value]”, did not score very high, either. The lowest score given was 1 and the highest one was 4. There were 20 submissions and the amount of points was 58, the mean was 2,9 and the standard deviation was 0,97.

Question number six of the first part of research A had 20 submissions, the amount of points given was 64, the mean value was 3,2 and the standard deviation was a relatively high result of 1,1. The question was titled “6) Based on past agile projects and experiences, in all of our teams and projects, the product-owning customer has been involved and engaged in the whole development process. [Please select a value]”. The highest amount of points given for the question was 5 and the lowest was 1. (table 2.)

4.2 SAFe

Of the questions relating to SAFe, the seventh one was titled “7) According to (SAFe) the most common and most recommended Agile ways of working are Scrum, XP (Extreme programming) and Kanban. Based on prior experience, the capability and preparedness of the company and its teams to use such ways of working are: [Please select a value]”. It was answered by 19 respondents. The mean value was 2,79, amount of points received was 53 and the standard deviation was 0,79. The top points given by a respondent were 4 and the lowest were 1.

(28)

For the eight question, titled “8) One of the characteristics of SAFe is long program increments or iterations. The team structure, mindset and flexibility of the production team is well-suited for long program increments (8-12 weeks) in terms of efficiency and productivity. [Please select a value]” received 20 submissions, with 4 as the highest and 2 as the lowest amount of points given. The mean was 3,1, the standard deviation was 0,79 and the total amount of points were 62.

The ninth question received 19 submissions, with 58 points, standard deviation of 0,97 and a mean value of 3,05. The title of the question was “9) For larger-scale agile projects, the Agile Release Train (a team of teams) is to work well with all the capabilities: hard- ware, software, firmware, and other - needed to define, implement, test, and deploy new system functionality. I would rate the different professionals and teams at the company to be very cross-functional, able to perform any task. [Please select a value]”. The lowest points given by a respondent were 1 and the highest were 5.

The tenth question was titled “10) One of the key values for SAFe is organizational alignment throughout different departments, business units and levels. For the supplier or con- tractor company, alignment suggests that all aspects of the project team are in line with each other and following the same goals and objectives. This can manifest for instance in the project management, project vision, roadmaps, team structure and backlogs of tasks to be done. Based on prior projects, the different parts and levels of the project team have been in line with each other. [Please select a value]” and received a total of 20 submissions. The mean was 3,25, standard deviation was 0,72 and the total amount of points was 65. The biggest amount of points a single respondent gave was 5 and the lowest one was 2.

Question number eleven received 20 submissions, with the mean value being 3,4, the standard deviation 0,88 and the total amount of points were 68. The highest amount of points given were 5 and the lowest were 2. The title of the question was “11) W. Edwards Deming once stated: ‘Inspection does not improve the quality, nor guarantee quality. In- spection is too late. The quality, good or bad, is already in the product. Quality cannot be inspected into a product or service; it must be built into it’. At the company, it is ensured that every result produced reflects quality standards all around. To what degree would you agree with this statement? [Please select a value]”.

For the twelfth question, titled “12) To what extent do you agree with the next statement:

As the supplier company in customer projects, the company is able to execute working

(29)

systems, deliver continuous value and have the end-customer in mind at all levels throughout the project team(s). [Please select a value]”, 20 replies were submitted. The mean value calculated was 3,55, the standard deviation was 0,83 and the total amount of points were 71. The most amount of points given by a respondent was 5 and the lowest was 2.

The title of the thirteenth question was “13) In cross-functional team projects, I feel that the company is adaptive, sharing transparency and trust. This allows those that produce value to make autonomous and decentralized decisions, when needed. [Please select a value]”, which received 20 submissions and a total score of 65 points, where the highest single value was 5 and the lowest was 2. The mean value was 3,18, the standard deviation was 0,79.

The fourteenth question was answered by 20 respondents, the mean was 3,2, the standard deviation was 0,90 and the amount of points received was 64. The highest value as- signed was 5 and the lowest was 2. The title of the question was “14) Approximately how big of a percentage of agile projects have you participated in, where product-owning customer satisfaction has been positive? [Please select a value]”.

The last closed-ended question, the fifteenth, was titled “15) Our culture statements are at the core of what we do and believe in. The value statements are: approach work in a seri- ous manner, yet not taking ourselves too seriously; we value teamwork as it allows for us to be stronger as one; we cultivate a deeper understanding in our judgment; we believe in inspiring and exciting others in every-thing we do; at the company, I can be myself. In theory, they mostly seem to correspond with Agile values quite well. However, in practice, how well would you rate the statements to agree with Agile values? [Please select a value]”, receiving 20 submissions. The standard deviation was the lowest of the questions of 0,51, which indicates that it received quite a similar value of points by all the respondents. In total, it received 71 points and a mean value of 3,55. (appendix 1; table 2.)

(30)

Table 3. Research A: Thematic analysis on answers of survey question 16 (RQ 16) of the internal research on agile and SAFe

Question / topic Responses Categories, possible im- provement areas

RQ 16 “The mindset and philosophy is there. However, there should be more adaptability in certain projects. Also, the tech team needs more cross-functionality and senior work- force.”

Adaptability, versatility in expertise, number of experienced employees

RQ 16 “After the merge people are still learning how to best work together between diffrent business units and shared projects. More time is still needed to master those processes in agile way.”

Co-operation between different business units, internal processes

RQ 16 “The company has a great potential to live up with Agile and SAFe methodologies and it would be of great benefit for all at the company to be trained especially in SAFe.”

Lack of coaching, training

As for the open-ended question of research A, the themes that emerged from the internal agile study conducted by the researcher were mostly related to the processes, the structure as well as the culture of the company. The responses here indicated that the company has the philosophy and values that are in line with agile principles in order to successfully participate in larger-scale agile projects, however some areas need attention, such as internal processes, cross-functional expertise, learning and training. The categories that came up based on the answers were: adaptability; versatility in expertise; the number of experienced employees; co-operation between different business units, internal processes; lack of coaching and training. (appendix 1; table 3.)

Table 4. Research B: External employee satisfaction research - RQ1: Please list what you consider to be unifying factors at the organization level

(31)

Question / topic Responses Categories, possible im- provement areas

RQ1 “Professional development fo-

cus: the company provides huge potential for professional development – we just need the structure for it”.

”How can we learn from others when I am not working with them?”

Potential for professional development, structure, more opportunities for co- work

RQ1 “From small to bigger → the

fears and excitement are the same

Community is the key and everyone wants that

People are truly excited about the integration and the possi- bilities around that → concrete things need to happen!”

More focus on community, tighter integration

RQ1 “Relaxed talents that love to

work and focus on quality All of the companies are pas- sioned about their customers Love for marketing and growth”

Employees enjoy their work

RQ1 “People are afraid of bureau-

cracy but they scream for structure!”

Low bureaucracy, improvement in structure needed

RQ1 “People really appreciate the

fact that the owners are working in the companies”

Executives present, low hierarchy

RQ1 “Low hierarchy and warm cul-

ture”

Low hierarchy, positive culture

For research B, which was carried out by an external research company earlier, in 2017, there were more emerging themes. Firstly, what the employees reported as common positive and desirable phenomena were related to professional development; community;

Applying Scaled Agile Frameworks in a Small Company to Engage in Large-Scale Software Development Projects as a Supplier