Key success factors for
Autonomous Agile Software Teams
at the small-scale
Kevin Berg
Anton Karlsson
This thesis has been executed at the School of Engineering in Jönköping within the area of Computer science. The authors take full responsibility for opinions, conclusions and findings presented.
Examiner: Ulf Seigerroth Supervisor: Rob Day Extent: 15 hp Date: 2020-05-24
Acknowledgment
This thesis represents the final part of our degree of Bachelor of Science in Computer Engineering, specialisation in Embedded Systems. We would like to thank our supervisor at Jönköping University, Rob Day, for your engagement and willingness to help. A big thank you to the participants of this study. We are also grateful for the experiences that we have had at Jönköping University, and our time in Jönköping will be cherished.
Abstract
Purpose – This thesis is to identifying key success factors for autonomous agile teams at the small-scale. Furthermore the purpose leads to an improvement of their working process.
Method – This study is based on a comparative case study of a company with offices located in Jönköping and Ängelholm. The data is gathered by semi-structured qualitative interviews and by a survey with qualitative and quantitative answers.
Findings – The results from RQ1 shows that there exists a difference between established and non-established autonomous agile teams in order to achieve success for projects. The findings from RQ2 present six themes that each represent key success factors in an autonomous agile team-based IT project at the small scale. The themes are Customer Oriented, Architecture, Individual Development, Team Setup, Entirety and Privilege. The findings from RQ3 resulted in six different elements (Freedom and Flexibility, Trust and Responsibility, Clear directions, Environment, The work gives
value and Shared knowledge) that make an individual team member satisfied in an autonomous agile team.
Limitations – A fair limitation of this study is too few people to answered the survey. More respondents would have increased the trustworthiness of the results.
Keywords – Autonomy, Self-organizing, Success factor, Agile development, Small-scale, Job satisfaction
1. Introduction 1 1.1 Delimitations 3 2. Theoretical background 5 2.1 Types of organizations 5 2.1.1 Large Scale 5 2.1.2 Small Scale 6 2.1.3 Distribution of literature 6 2.2 What is Agile Software Development? 7 2.3 Autonomous teams 9
2.3.1 Benefits 10
2.4 Autonomy Success Factors 10 2.5 Agile Success factors 11
2.6 Individual Satisfaction 12
3. Method and Implementation 13
3.1 Research Approach 13
3.2 Systematic literature review 14
3.3 Data gathering 15
3.3.1 Interviews 15
3.3.2 Survey 16
3.4 Connection between research questions and method 17 3.5 Choice of interviews 19 3.6 Data analysis 21 3.6.1 Analysing interviews 21 3.6.2 Analysing survey 23 4. Findings 25 4.1 RQ1 25 4.1.1 Customer focus 26 4.1.2 Time 26 4.1.3 Test 27 4.1.4 Small deliveries 27 4.1.5 Employee satisfaction 27 4.1.6 Technical value 27 4.1.7 Business value 27 4.1.8 Planning 28
4.1.10 Learn by mistakes 28 4.1.11 Quality 28 4.1.12 Business focus 28 4.1.13 Good culture 29 4.1.14 Budget 29 4.2 RQ2 29 4.2.1 Customer oriented 29 4.2.2 Architecture 31 4.2.3 Individual development 32 4.2.4 Team setup 34 4.2.5 Entirety 35 4.2.6 Privilege 36 4.3 RQ3 37
4.3.1 Freedom and flexibility 38
4.3.2 Trust and responsibility 38
4.3.3 Clear directions 38
4.3.4 Environment 38
4.3.5 The work gives value 38
4.3.6 Shared knowledge 39
5. Discussion and conclusion 40
5.1 Limitations and future research 41
Figures
Figure 1: Large-scale agile development - Definition by workshop participants at XP2014 [29]. 6 Figure 2: Agile Software Development [4] - Four core values. 8 Figure 3: Agile Software Development [4] - Twelve guidelines. 8
Figure 4: Organisation structure of the company. 16
Figure 5: Interviews analysis. 21
Figure 6: Survey analysis. 23
Figure 7: Comparison of organizational aspects between established and non-established autonomous
teams. 26
Figure 8: Customer Oriented - Theme derivation. 30
Figure 9: Architecture - Theme derivation. 31
Figure 10: Individual Development - Theme derivation. 33
Figure 11: Team Setup - Theme derivation. 34
Figure 12: Entirety - Theme derivation. 35
Figure 13: Privilege - Theme derivation. 36
Tables
Table 1: Mapping references with focus areas in the articles. 7
Table 2: Success factors for Autonomous Teams. 10
Table 3: Success factors for Agile teams. 12
Table 4: Mapping interview questions with RQs. 18
Table 5: Mapping survey questions with RQs. 19
Table 6: Mapping interview questions with origins and position at the company. 21
1. Introduction
In the 1960s a new crisis arose often referred to as the “software crisis” [1]. The crisis emerged due to an unbalance between the software development technology and the hardware technology. To overcome this crisis, a number of software development methodologies and techniques have been constructed. During this time period the need of the application changed in regard to requirements and systems. In some cases, the whole business changed, which meant that projects were cancelled halfway through. In 2006, 65% of all software projects were unsuccessful and 46% faced cost challenges or time overruns
[2]. Previous popular software techniques such as “The waterfall model” are not fit for such projects where requirements change frequently [3]. The frustration led to the Snowbird meeting in Utah 2001 where 17 representatives from Scrum, DSDM, Extreme Programming and other heavyweights software development processes convened. In this symbolic meeting, the Manifesto for Agile Software Development was created where the focus on iterations and customers collaboration was prioritised [4],
[5]. These methods have tremendously enhanced the quality of product development as well as the process of product releases to the market [6].
Using an agile method is a valid and beneficial counteract to inevitable changes involved in most of the development projects. Small organizations are profoundly more affected than large organizations by change despite their process strategy [7]. It is confirmed that agile methodology is suitable for small-scale, time-intensive software projects [8].
There are several words for autonomy such as self-managing or self-organizing [9]. The meaning of being a self-organized team is defined as a small group of team members who are determined to plan and manage their everyday work and activities under reduced or no supervision [10]. To succeed in today's agile environments, companies and organisations must find a way to assist and regulate teams’ autonomy according to the environmental demands and limitations [11].
investigation. The most established one, which also is the headquarter, has today developed an autonomous working routine. The Jönköping office, which is newer, is in the middle of a transfer of becoming autonomous. The research is made between these two, aiming to find and understand what and how the Jönköping office can go fully autonomous just like the headquarters. Both offices work in team-based projects where Tech Managers, Tech Lead, Software Developers and System Architects work close to each other. The company's ambition is to have autonomous agile teams that can be independent but at the same time help and take advantage of each other where the employees feel motivated and satisfied. It is believed by the company that adapting an autonomous agile method will lead to a higher success rate and a happier work environment for the workers. It is not clear for the company what parts in working autonomously, in an agile team, that makes the employee satisfied. This research will look further into the subject.
To successfully keep up against competitors in the software industry, companies today have to change their way of thinking. The importance of this research is significant because of the number of failing projects. There is today room for improvement in how agile teams work around IT projects. Research about key success factors for autonomous agile teams has been explored to a large extent, there are many articles on autonomous agile teams in general, and also a lot of articles about autonomous agile teams at the large-scale (amongst others, [12], [13], [14], [15]). There are also articles about success factors for agile teams[16]. However, our research will investigate at the small scale, which is an area that has not been thoroughly looked in to. Therefore, an investigation on how agile autonomous agile teams at the small scale can potentially increase their success rate will be done.
The purpose of our research is to construct key success factors for autonomous agile teams at the small-scale. This will be done by conducting a case study on software development teams. The purpose leads further to an understanding of how agile teams' working process, in a small-sized IT company, can be improved for an overall increase of the success rate. In order to fill the gap in the research area, this thesis will answer the following questions to further contribute to the research.
RQ1. Is there any difference in organizational aspects prioritization between established and non-established autonomous agile teams in order to achieve a successful project?
● The research question relies on how autonomous agile teams are adapting to new environmental demands and limitations. In order to survive the fast-changing industry, the company has to prioritise what is the most important in order to achieve their goals.
RQ2. What key factors are important in order to achieve success in an autonomous agile team-based IT project at a small scale?
● The degree of change and unpredictability is one big obstacle that companies have to face in order to fit into an agile autonomy approach. One proven way of working might be useful for one team or company but in the same way be ineffective for another. There is no such thing as one-size-fits-all [17]. Therefore, we are looking for key factors instead of a complete model.
RQ3. What makes an individual team member satisfied in order to work as efficiently as possible in an autonomous agile team?
● If the satisfaction for the employees increases, the effectiveness of the employees grows [18],
[19]. Therefore, there will be an investigation on what makes individuals satisfied in their work environment.
1.1 Delimitations
The study is delimited to examine the agile working process to find a way for teams to become autonomous. Depending on the limited time the research is delimited to focus on literature and mixed combination of qualitative and quantitative data. A fair delimitation of this study is that we only conducted the study at one company. Supplementary interviews at other companies would increase the generalisation of an investigation such as this one. Additionally, the company in this study only works with small-scale projects and this can affect the results. Therefore, additional qualitative studies with other companies that also work with autonomous agile teams but at large scale would increase the
surveys. The first surveys should be in the Jönköping office, that is in the middle of the process of becoming autonomous, before the process starts. The second survey should be at the end of the process of becoming autonomous. This is because, in our survey, we have nothing to compare with except for comparing our survey with literature. In order to achieve an optimal result of this survey, there should be a before and after survey.
2. Theoretical background
Since we already knew the research is about agile methods and autonomous work, we could start working on a theoretical background and search information about our topics. The theoretical background lays the ground for the research and helps us form the base knowledge and understanding of the research scope and give proper validation of the results.
This section will present relevant success factors for autonomous agile teams as well as agile teams. This has been done to make our analysis, where we discuss the success factors presented here, and the success factors that are found from our investigation to answer RQ2. RQ1, which will investigate how to
prioritise different organizational aspects as well as RQ3, which will investigate individual satisfaction will also be answered in our findings.
2.1 Types of organizations
2.1.1 Large ScaleThe definition of “Large-scale agile development” described in Dingsøyr, T., & Moe, N. B [20],
has been used to outline agile development in everything from large teams to large multi-team projects to making use of agile principles in whole organisations. They also did a workshop where participants defined large-scale agile development. Figure 1 presents the definitions conducted from the workshop. From this workshop they could see that many defined large-scale agile development as:
Figure 1: Large-scale agile development - Definition by workshop participants at XP2014 [29].
2.1.2 Small Scale
The definition of small scale in this thesis is both related to the team size and the number of developers. Zhang & Dorn [8]define their small-scale investigation on teams that are between 3-5 people. The definition in this thesis of small-scale is that the number of developers shall be less than 50 and the teams shall be between 3-5 people.
2.1.3 Distribution of literature
Autonomous agile teams at the small-scale is an area that has not been researched to a large extent. Table 1 has been created to show that most of the papers are referring to large-scale or general information about the subject. In this thesis, there are only three papers that refer to small-scale investigations. This shows the significance of this thesis.
Table 1: Mapping references with focus areas in the articles.
2.2 What is Agile Software Development?
Agile software development is a method that is centred around iterative development. The teams working with agile methods shall be cross-functional teams. Cross-functional teams are teams that possess different experiences working towards the same goal. The members of these teams can originate from all levels within the organization.
Agile software development is based on the four core values ( Figure 2) and the 12 guidelines ( Figure 3) from the agile manifesto.
Figure 2: Agile Software Development [4] - Four core values.
Figure 3: Agile Software Development [4] - Twelve guidelines.
It is not mentioned in the core values or the guidelines that agile software development shall have autonomous agile teams. The two guidelines that are highlighted in Figure 3 are touching upon the subject. Guideline five says that the employees should be supported and trusted to get the job done, but it does not say how to get there. The subject is also touched by guideline eleven, but they are referring to the architecture and not the development. However, the manifesto is open for interpretation and we believe that autonomy goes hand in hand with guideline number five and eleven.
2.3 Autonomous teams
Autonomous teams have become progressively prevailing in the latter part of the 20th century into the 21st century. An autonomous team can be designed in different styles and sizes depending on the company as well as the project. The team groups have been given different responsibilities and control of one or several specific tasks where freedom and decision making is granted for every participant. Aside from monitoring and evaluation from any chief or manager, autonomy focuses on complete independence from any hierarchy.
The broad explanation of autonomous work is when several individuals, together in a group or a team, are working toward a shared task or project goal.
Autonomy means that someone is setting strategic direction and destination for the employee but the path of getting from point A to point B is decided by the employee. An easier definition of autonomy is described as a team that has the freedom and the authority to make their own determination in order to fulfil a goal [21]. At the core of teams being autonomous, self-organizing and self-managing is the idea that team members work at a pace that sustains their productivity and creativity [22]. Autonomous teams should aspire to set up their own goals and try to find their limitations in order to achieve better goals
[14].
Companies must take into consideration the degree of change and unpredictability together with the fact that there is no such thing as a one-size-fits-all autonomy approach [17]. Additionally, implementing autonomous teams can be very costly due to the organizational changes that have to be made. This shows the importance of understanding that implementing autonomous teams have to be done gradually and with carefulness [23].
2.3.1 Benefits
Since every team works in its own favour, every individual becomes more involved in every taken step. Working autonomously gives more freedom to the participants since they work independently and do not rely on a leader or manager to tell them what to do. This gives the team members more room to think for themselves and increase both their productivity and creativity. Knowledge in the team can be shared as the team sees fit. This makes it easier for new and existing employees to learn from each other.
2.4 Autonomy Success Factors
Tabel 2displays success factors for autonomous teams from literature and the authors that propose them. All the success factors in Table 2 are discussed.
Table 2: Success factors for Autonomous Teams.
Clear, engaging direction
Autonomous teams have to have a sense of the existence of the team and what the team wants to accomplish. The team's purpose has to be clear but not how to get there. To enhance team motivation, the leader shall set the goal, and the team shall decide by themselves how to get there [12].
Cross-functionality
Having a successful autonomous team is highly reliant on the team possessing expertise in multiple areas. A cross-functional team helps the team improve their flexibility and enhance their communication
and collaborative process. They continue to add that cross-functional teams are able to help each other efficiently, and thus remain autonomous [13].
Self-transcendence
Teams shall form their own goals and find “their limit”. This is to continuously improve themselves and find better ways to reach their goals. They shall be encouraged to self-evaluate their own performance to gather information about how to improve their own work [14],[12].
External support
Using external support leads to an increase in decision making authority and power for the team [15].
Corporate culture and policies
Implementation of autonomous teams shall promote autonomous behaviors, accountability, team orientation, continuous learning, risk taking, and change. Autonomous teams are also more effective under low levels of organizational formalization[12].
Team and organizational goals
Goal clarity is a significant factor of performance in autonomous teams. Even though autonomous teams have the freedom of having their own goals, they rely on feedback from the organisation. This is to make sure that team effort aligns with the organisational goals. The organisational goals and the team goals shall be aligned to achieve a strong relationship[12].
2.5 Agile Success factors
Tabel 3displays success factors for agile teams from literature and the authors that propose them. All the success factors in Table 3 are discussed.
Table 3: Success factors for Agile teams.
Training and learning
Agile teams should be built on motivated individuals. There should be an emphasis on training and continuously learning during projects [16].
Customer involvement
Delivering frequent releases of working software and to be open to change in requirements depend mostly on the customers. The more involved the customers are, the more satisfied they will be with the results [16].
Communication
Individuals should be eager to share information with each other, to spread knowledge in the team. It also requires effective communication between customers and project members to achieve a successful project [16].
2.6 Individual Satisfaction
There is a model called “Job Characteristics model” made by Hackman and Oldham [19] that defines five different job characteristics that affect employees' attitude to their work. This model describes the characteristics - task significance, task identity, skill variety, autonomy, and feedback.There is some initial evidence of impacts that these characteristics may be directly related to agile methods [24]. The company that plays a role in the investigation believes that working in an autonomous agile team correlates to job satisfaction, which is one of the characteristics in the previous described model. However, this characteristic can be narrowed down, and this investigation wants to find out what parts in working in an autonomous agile team that makes the employee satisfied.
3. Method and Implementation
To undertake the three research questions, “Is there any difference in organizational aspects prioritization between established and non-established autonomous agile teams in order to achieve a successful project?”, “What key factors are important in order to achieve success in an autonomous agile team-based IT project at a small scale?” and “What makes an individual team member satisfied in order to work as efficiently as possible in an autonomous agile team?” a mixed methodology case study was conducted [25]. The mixed methodology approach consists of strategies to assemble, analyse and merge both quantitative and qualitative data in different stages of the research process in the study [26]. Justification to use and mix both quantitative and qualitative methods and data is that neither of the methods alone can adequately cover the scopes and depth of questions on “how”, “what” and “why” pertaining success factors. The two methods in combination can complement each other and contribute a comprehensive and detailed view of the research problem [27]. The method section declares, detailedly, the methods that were used to answer all research questions.
3.1 Research Approach
A case study research, chosen for this thesis, has been delved into by several authors in different contexts
[28], [29]. This type of study is commonly used in social science and in-depth investigations on single individuals, groups or events to explore the cause of underlying principles. The reason why we have constructed research based on case study methodology is that individuals and teams within the company’s experiences are crucial for the outcome of the investigation. By taking the mixed methodology approach, two principal connotations have to be understood. Firstly, an understanding of how Autonomous agile processes are implemented are received by the company. Secondly, key success factors from literature are discussed in order to understand its relevance. In the case of this investigation, the participants are employees at the company. Since the case study interacts with a mixed methodology
description of the qualitative approach, where the roles of each employee interacted, is presented in the interview section. A fundamental understanding is grounded upon existing literature, which we further wanted to expand and clarify. Within this strategy, qualitative text data from the interviews and the survey are gathered and analysed first. Subsequently, numeric quantitative data from the survey is then gathered and analysed. From the survey, a qualitative method is used to expand and evolve on the quantitative results gathered first. In this study, the quantitative data is to verify the participants’ satisfaction at work.
3.2 Systematic literature review
A systematic literature review is a method used to identify, evaluate and synthesize all available research that is relevant to the suggested research question through a systematic search and data extraction process
[30]. There are examples of systematic reviews in agile software development that include a comprehensive review on agile empirical studies [31]. However, we could not find any reviews on autonomous agile teams at the small scale. We used a search strategy aimed to identify english language studies on autonomy, agile and software development mainly at the small scale. We mainly use two sources when gathering literature. Most of the literature is gathered from the library of Jönköping University (PRIMO), in the form of peer reviewed articles and books. The second source is Google Scholar which provides a simple search of school literature. The reason why Google scholar was used is because it allows us to see papers related to the subject, how many times the article is cited and by whom. The Google scholar also allows us to save both citations and papers for later use. PRIMO is mainly used because it is the database for our university. PRIMO is a good starting point when we are looking for multidisciplinary information. The reason why Google scholar and PRIMO are used as our databases and not any other databases is because the university has recommended these two. The search was executed by using the following search terms (the search terms were adapted to suit the requirements of each of the search engines): ((Agile) AND (Autonomous OR Self-managing OR Self-organising) AND (Success factors OR Satisfaction) AND (teams) AND (small-scale)).
3.3 Data gathering
The collection of data is dependent on a literature review which we considered to be relevant for our subject of the study, qualitative interviews and a quantitative/qualitative survey. Therefore, our research will be, as mentioned before, a mixed methodology to gain breadth and depth in our investigation. It also provides a complete and comprehensive understanding of our research problem [32]. There also exist some disadvantages of using mixed methodology. For example, it might make the research more complex than using qualitative or quantitative methods [32]. However, we believe that our research will be more reliable when using both rather than choosing from one another.
3.3.1 Interviews
We use qualitative interviews to answer the question of how success factors are defined. Additionally, interviews are used to analyse how a team becomes autonomous and successful. It is also used to collect text data on how the team prioritise different organizational aspects to achieve higher results. Therefore, qualitative interviews are directly linked to answer RQ1 and RQ2. Justification for the reason why we are using interviews is to assiduously understand the circumstances that the practitioners existed in [33].
Interviews are used to gather deeper information about the topics that are investigated. Unlike quantitative research like surveys, interviews will dig deeper into the subject and answer questions such as why, how and what if. One of the reasons why interviews were chosen is that it can facilitate obtaining detailed information about the participants personal feeling, perceptions and opinions. The second reason is that vagueness can be clarified, and incomplete questions can be followed up. Another important reason is that interviews are not influenced by other participants in the research group.
Conducting interviews can induce biases. A respondent’s answers might be affected by his reaction to the interviewer’s appearance, race or age. It can also cause inaccuracies due to the reaction from the interviewer. Unlike surveys, interviews grant less anonymity which can concern some participants. All
carefully to be as natural as possible in order to not lead or mislead the respondent. The interviews have been made through an online platform. We choose to do interviews with one participant at the time. There are a total of seven employees that are participating in the interviews. Of these seven people, there are two Tech Managers, two Tech Lead, one System Architect and two Software Developers.
The questionnaire is dependent on which role the participant has. This is made to get the whole picture and different perspective within the same teams. The participants come from two different offices, which gives us an expansive view of answers to the questions. Since we did the interviews remotely, there is no specific order or arrangement. Figure 4 presents the structure of the company.
3.3.2 Survey
The benefits from doing surveys are that they provide a simple way to do research to an extensive number of participants. It is also an easy way to collect and illustrate descriptive data in numeric form. We used a survey as a method to capture an overall view of the opinions and perspective of the participants. The survey is made to measure how satisfied the employees are at work. The questions are designed into two categories where one is Likert scaled while the other questions are open-ended and designed to give room for an explanation for the participants.
The Likert scale is a pre-populated numeric form with a scale from 1 to 7. The reason why Likert scale is chosen instead of binary questions is that Likert scale provides more granular feedback about whether the employees are just “satisfied” or “not satisfied”. Another reason is that it also brings deeper information into a specific topic, where the questions are grouped together to get a final score.
Total, 67 emails were sent out to the Tech Department. A hyperlink with the questionnaire was included in all emails. When the hyperlinked was clicked, it led the respondent to Google Form where they could fill in the survey online. The survey was completed in two weeks. Only 11 respondents had filled in the form, making the sample of 11. We have chosen Google Forms as the platform because of our previous experience of the tool and because it provides the answers to be anonymous. The reason why we choose to do the form anonymously is that we believe that the participants will answer the questions about their work satisfaction more honestly.
By making a survey, the collection of data can be done quickly, and the information gathered is relatively easy to analyze. The survey also provides easy use for the participants. Since everyone who is answering the survey has access to the internet, the participants can choose a moment that suits them best to complete the form. Furthermore, this form of data gathering does not always provide authentic information. In some cases, the participants' unwillingness and human bias of respondents can occasionally carry out inaccurate information. The difference in understanding can also affect the result in consideration of that the formulation of each question is hard in such a way that it will mean exactly the same for all the participants.
3.4 Connection between research questions and method
In order to answer RQ2, we choose to do interviews as our qualitative data. The reason why interviews fit these research questions is that in order to collect answers on what key factors are important, we need descriptive and well formulated answers. Since the definition is a broad variety of answers with different organizational aspects, the choice of method will answer questions such as what and why. The interview questions are shown in Table 4.
RQ1 and RQ3 are answered by both interviews and a survey. The survey is formed to answer questions from an individual perspective while the interviews answer in a team-based perspective. Although, the interviews touch upon both subjects. The survey will also be answered by a larger number of individuals, which makes the answers more solid. The survey questions are shown in Table 5.
Table 5: Mapping survey questions with RQs.
3.5 Choice of interviews
There are three different types of interviews: Structured, Semi-structured and Unstructured. A structured interview is an interview where the questions are prepared beforehand. This means that there cannot be any follow-up questions. All the candidates are asked the same questions in the same order and then compared on the same scale. Semi-structured interviews on the other hand are a meeting in which the interviewer has prepared a set of questions but does not strictly follow the questionnaire. The order of the questions does not matter, and they are more used as a guide for a conversation. Unstructured interviews are the opposite to structured interviews. The unstructured interview has no questions prepared before the meeting. An unstructured interview is more like an everyday conversation and tends to be more informal and free flowing.
The choice of interviews in the research was semi-structured interviews because the set of questions needed to be different depending on the position of the participant. In semi-structured interviews there can also be follow up questions i.e. a participant is giving a very short answer in a question. The follow up questions have been a tool for us to get more detailed answers. The semi-structured way of doing the interviews has also given us the possibility to construct new questions during the interview. Which questions that are added and which that are original is shown in Table 6.
3.6 Data analysis
3.6.1 Analysing interviews
The unit of analysis has been conducted by using the method of analysing content from interviews described in Graneheim and Lundman, 2004 [34], but with some customization. In the text, they describe how they analysed data from interviews in the medical area. Figure 5 presents the analysing steps.
Figure 5: Interviews analysis.
The first thing that we did was to re-listen the recorded video tapes of the interviews and write down every word that had been said by the participants. By doing this we could re-read the transcribed interviews to get a sense of the gathered data.
Step 2: Generating codes
After getting familiar with the data, and getting a sense of it, we started to narrow down the quotes into codes. Codes are descriptive labels of segments in the transcript [35].
We worked through the gathered data in order to find interesting findings that could be converted into codes. For example, we found facts from the participants on tips on how to become autonomous, although the teams are self-going, they still have to take advantage of other teams by rotating people to spread knowledge. This data was translated to the code “Importance of teamwork”. If several quotes could be narrowed down into the same codes, prioritization can be made. If more answers are generated into the same codes, the higher prioritisation it will get.
Step 3: Converting codes into sub themes
When the codes have been constructed from the transcript, the codes are divided into sub themes. A sub theme in this aspect is when several codes have the same common ground. By doing this division, the sub themes are directly related to the research questions and will be easier to discuss. Key factors on how to become autonomous could also be sorted out from the codes.
Step 4: Create themes from literature and our research
In this process, the key factors we have sorted out in step 3 will be combined with key factors from relevant literature. The combination of the sub themes from our research and literature will be the context of our findings.
Step 5: Present the results
In the last step we will present the result of our findings in a logical way. The findings of our report is from step 4, when the combination of our sub themes and literature occurred.
3.6.2 Analysing survey
First off, the survey is divided into two segments where the first one is a quantitative Likert scale from 1 to 7. The second segment is the qualitative questions. The analysis of the survey is following a method shown in Figure 6 in order to make sense of the quantitative and qualitative data collected. Both of the segments are following the same analysis procedure with slight differences between the two. To calculate the survey results more effectively these are the following steps:
● Looking at RQ3
RQ3 for the thesis obeys “What makes an individual team member satisfied in order to work as efficiently as possible in an autonomous agile team? ” In order to answer this question, it was divided into three split questions touching the subject.
- How satisfied are you with the projects that the company is working on? - How satisfied are you with working in an autonomous agile team?
- How much would you recommend other companies to work with autonomous agile teams?
● Filtering
Depending on the type of questions, the data will be filtered into one of two ways.
- If the data is from the open-ended questions, the results will be filtered further into codes and sub themes exactly as the interview results are analysed.
- Additionally, the Likert scaled questions will be analysed to create scores on each item for each participant [36]. The measure developed is a 3-item scale, produced to one final score. Each item is scored 1 to 7, so that the total range is 3 to 21. The higher the scores the higher satisfaction for each participant.
● Results
To use the answers with confidence as a basis for a conclusion, proper results are needed. To get the results needed from the data, a statistical significance is often taken into consideration. But due to the fact that the number of participants was less than 30, the results are not proven by a statistical significance.
4. Findings
This section will present the findings from our investigation. In order to answer RQ1 and RQ2, the qualitative text data was analysed first. The findings from the qualitative text data recommend six different themes where all of them include key success factors to achieve success in an autonomous agile team-based IT project at the small scale. The themes Customer Oriented, Architecture, Individual
Development, Team Setup and Entirety consist of a combination between key success factors from existing theory from literature and with findings from our case study. The theme Freedom and
Flexibility is exclusively based on findings from our investigation. These themes are set out to answer RQ2. The figures present the themes with each definition.Moreover, RQ1 was answered based on the findings from the interviews. Since RQ1 was made to find and prioritise different organizational aspects in order to achieve a successful project, only the two first steps in the analysis described in section 3.6.1 were needed. The section will describe all themes and what they contain, as well as what segment that is from literature and what segment that is from the case study findings. Lastly the section will also describe findings to RQ3.
4.1 RQ1
Is there any difference in organizational aspects prioritization between established and non-established autonomous agile teams in order to achieve a successful project?
This section will answer RQ1 on if there is any difference between established autonomous agile teams and non-established on prioritizing different organizational aspects according to the interviews. A list will be shown on the prioritizing order of the organizational aspects, ranked from the most to the least important. Even though some organizational aspects have low priority, does that not mean that it is not important. The organizational aspects ranked is the aspects that the participants in the research found most important for having a successful project. Figure 7 shows all the organizational aspects with prioritizing order. All the organizational aspects are explained in this chapter.
Figure 7: Comparison of organizational aspects between established and non-established autonomous teams.
4.1.1 Customer focus
The most mentioned aspect to achieve a successful project is to have customer focus. This is not only to have a successful project, but also to have a successful team, as explained in 4.2.1. The aspect means that the customers shall be involved in the project, and to have effective communication with the customers. This is an aspect because when the customers are involved in the project, they will be more satisfied with the end result.
4.1.2 Time
The time aspect means how time consuming different parts of the project is. If some parts of the projects are very time consuming and give low value, then that part of the projects has low priority. This is an aspect because if there is no time estimation, then there will be much time spent on parts of the project that gives low value, that can cause delay in the delivery.
4.1.3 Test
To make sure that there is nothing wrong with the software delivered to the customers, tests are implemented. This is an aspect because the tests prevent faulty functionally to be delivered to the customers.
4.1.4 Small deliveries
Small deliveries means that the team shall do iterations and release small deliveries frequently. This is an aspect because releasing small deliveries leads to higher effectiveness and the team is more open for change to fit the customers demands.
4.1.5 Employee satisfaction
Employee satisfaction is important for the team because it leads to effectiveness. This aspect is more described in chapter 4.3.
4.1.6 Technical value
Technical value is counted as an aspect because contributing with technical value to the project is important for having a successful project. Technical value leads to higher quality on the service, which makes the customers more satisfied.
4.1.7 Business value
Business value does not only mean that the project shall make profit, but also to deliver solid solutions which makes the firm look good in the industry. Business value is counted as an aspect because it determines the health and the well-being of the firm in the long run.
4.1.8 Planning
To make the project delivered in time and not exceed the budget, planning of the project has to be done. Planning makes sure that everything is structured and on the right track, and are therefore counted as an aspect.
4.1.9 Help each other
To make a project successful it is important that the employees share knowledge with each other. If someone is stuck in their work there might be someone else in the team that the employee can take advantage of. In the end, all team members are working towards the same goals.
4.1.10 Learn by mistakes
If employees are not allowed to fail, they will never learn to grow or develop. This is an aspect because if you are making the same mistakes over and over again, the results will not be better. By learning from the mistakes, the project will become more successful.
4.1.11 Quality
The higher the quality of the product is, the more satisfied the customers will be. A project with high quality is counted as more successful because it lasts longer and is grounded on more solid solutions.
4.1.12 Business focus
A project’s success does not only rely on making good products and services. In the end, the company has to make profit in order to survive. All through a product or service is good, it does not mean it will sell.
4.1.13 Good culture
Good culture is counted as an aspect because it makes the employees more satisfied, which leads to higher effectiveness. The company’s culture is the environment, good colleagues, etc.
4.1.14 Budget
Making a budget for a project and sticking to it is an important aspect in order to have a successful project. The budget, time and planning organizational aspects are strongly linked to each other.
4.2 RQ2
What key factors are important in order to achieve success in an autonomous agile team-based IT project at a small scale?
4.2.1 Customer oriented
One of the success factors that we found was that the customer shall always be in focus. This is also an agile success factor from the literature. The literature describes customer focus as delivering frequent releases and being open to change. It also says that the more involved the customers are, the more satisfied they will be with the results. Figure 8 presents all success factors included in this theme.
According to the qualitative data, finding a way to frequently communicate with the customers and analysing the customer satisfaction is a crucial key-factor in order to achieve success.
As two Tech Manager describes it:
We do a lot of experiments. We deliver small changes iteratively and then measure. Based on this we can see how the customer uses are services and what kind of system that they like. But
at the same time, the vision to achieve success and operate forward is to help as many customers as possible. Conclusion: if the customer likes it then we make profit.
Give value and helping customers is a tremendously important key factor in order to keep the
company going. Customers are and have always been one of the most relevant aspects for a company. Employees stated that not only does it give value to the customers, but it also brings value to the individual and the team working behind the service or product. They also stated that if they can continuously deliver value then they would be perceived well by others and look good in the industry. Starting with this in mind could possibly make something just small turn out big and visible outwards.
Success factors from literature that is relevant to this theme is: Customer Involvement
4.2.2 Architecture
In order to have a successful autonomous agile team it is important to have clear directions on what the teams shall accomplish. The leader sets out the purpose and goal, and the team decides how to get there. To accomplish this, the clarity of both the team and the organisational goals is a crucial success factor. According to the qualitative findings, it is also important that there is trust in the organisation. This means that the organisation trusts the team to achieve the goals so that it generates both technical as well as business value to the organisation. Figure 9 presents all success factors included in this theme.
Figure 9: Architecture - Theme derivation.
As one Tech Manager states it:
You can’t divide the company into different parts and say “Go!”. This will never work, you must have more directive on how everything is managed. The goal has to be clear, you have to define what you
want to achieve. Everyone has to be on the same track. Start from the top of the company and work downwards. Make sure that you follow this procedure until everyone is knowing what is going on.
And as one Developer describes it:
I like the way that we are autonomous and have responsibility over our own decisions. Not just taking command from others but instead they tell us what has to be done and then we figure out how to do it
ourselves. Trust is more important than control.
Firstly the team should Attain the objectives to work with clear and structured goals. Team and
organizational goals have to be well defined from an organizational level down to a team level. Other
employees describe Trust and responsibility as giving the team a big mandate and follow up on the results. They wanted to feel that the company trusted them to make decisions and at the same time reevaluate directions. The goals have to be so clear that the company can with confidence trust that the team does their work. Even though it slightly goes against the principle of autonomy, the team should also focus to work for the company as a whole. One employee stated that by taking advantages from
as a whole. It is not enough to deliver projects to crush the deadlines. The projects have to bring high quality, the solution has to be smart and solid. In the end, it is the product that generates money.
Success factors from literature that is relevant to this theme is: Clear, engaging direction and Team
and organizational goals.
4.2.3 Individual development
Individual development is a crucial key factor in order to have a successful autonomous agile team. The qualitative finding found that own goals and priority as well as engagement and taking responsibility is necessary in order to have a functional autonomous agile team. There shall also be encouraged to self-evaluate own performance to know how to improve the work. In order to develop both individually and as a team, encouragement of taking risks and continuous learning shall also be included. Figure 10 presents all success factors included in this theme.
Figure 10: Individual Development - Theme derivation.
By being Self-transcendence and aiming to find their own goals and new way of working has according to the findings a direct relation to Contribute to development and Motivation and
satisfaction for an individual. Employees stated that by losing the feeling of being monitored has
More room for self-thinking generates more responsibility. The responsibility gives you bigger opportunities to affect what you do. This will lead you getting closer to the product and becoming an expert in the field. It is like a carrot when you feel that you are a part of it all and that is what motivates
me to work harder.
Other informants stated that the organization has to allow people to fail in order for them to grow. Therefore, Corporate culture and policies are crucial to a team's success. Adapting different methods, changing them and suiting them for the team’s advantages is pivotal for a successful autonomous agile team. If it does not work out, do it again and improve. One way of working is not optimal six months later, the industry changes frequently and therefore the way of working has to change continuously.
Success factors from literature that is relevant to this theme is: Self-transcendence and Corporate
culture and policies.
4.2.4 Team setup
When setting up an autonomous agile team, it is important that they are cross-functional, which means that they possess expertise in multiple areas. This is to make sure knowledge is available so that they can help each other out within the team. According to the qualitative findings, education is a very important tool to make sure that the teams can be cross-functional. Additionally, they also said that hiring external people is also valuable for increasing power for the team. Figure 11presents all success factors included in this theme.
Figure 11: Team Setup - Theme derivation.
A good thing to have in mind when setting up an autonomous agile team is to reach out for Outside
help. A Team Leader stated that all managers have to know down to every detail what it means to be autonomous in order to form a team. It is not worth it to just start implementing things in the organization. A tips is to hire an external agile coach and send all managers on education.
Multi-functional means that the team members have to have different skill sets in order to form a
functional autonomous agile team. It also means that knowledge is available which is crucial for a team’s Efficiency and productivity. To make most out of a autonomous agile team, one informant stated:
To increase a team’s efficiency and productivity we coach for developing developers to be more motivated to make things more quickly and constantly get better at quality. Working iteratively and
continuously improving what is needed in order to make small deliveries can be seen as effective.
Success factors from literature that is relevant to this theme is: Cross-functionality and External
Support.
4.2.5 Entirety
One of the agile success factors that was stated in the theoretical background was communication. This success factor says that knowledge should be spread among the team, and have effective communication between project members and customers. But according to the findings, this is not enough. Knowledge should be spread through the whole organisation to get an understanding of both the business side and the technical side of the project. This is to get an overall understanding of what the team and the organisation is walking towards. An important part to make this work, is that the individuals in the teams are motivated and have an emphasis on continuous learning. A rotation of employees among the teams is also a necessary part to effectively spread knowledge. Figure 12 presents all success factors included in this theme.
Figure 12: Entirety - Theme derivation.
To achieve higher results an Overall knowledge of the organization is crucial for a successful project. The more you know about other fields that also are necessary for the project, the better you understand the work that you do. Business side shares information to create comprehension. As one informant described it:
We have one pre-meeting with the business partners every week. This makes us see a root cause of why we work as we do, even if it does not appear outwards. You have to understand the whole business, not just the technical
parts.
Success factors from literature that is relevant to this theme is: Training and learning and
Communication.
4.2.6 Privilege
One major success factor for both a project and for employees satisfaction is privilege. This factor means that the employee should have the privilege to choose techniques and make their own decisions. It also means that the employees should have ownership and control of the product. Figure 13 presents all success factors included in this theme.
Figure 13: Privilege - Theme derivation.
Freedom indicates that the employees have the ability to act or change without limited constraints. But
that does not mean that they can decide over all and everything. Flexibility gives room for trying new things and suits them to the needs and requirements. As one informant describes it:
The room for freedom is one thing that I like with the job that I do. The company makes us feel free to choose relevant and interesting tasks. I do not like to feel mentally stuck, but with the flexibility to adapt and suit both
my and the company's needs makes the everyday work much easier.
4.3 RQ3
What makes an individual team member satisfied in order to work as efficiently as possible in an autonomous agile team?
To show that the answer of RQ3 is based on individuals that are satisfied at work, a Likert scale has been done. The individual score of that Likert scale and the mean, median and standard deviation is shown in Table 7. There were three questions, where the participant could answer with a number between 1 and 7. The answers of each participant were summarized so that the final score of each participant was between 3 - 21. Furthermore, each factor for satisfaction is explained in this chapter.
Table 7: Individual job satisfaction.
4.3.1 Freedom and flexibility
As previously described in 4.2.6, the employees should have the freedom to choose techniques and to make their own decisions. It also includes that the employees should have ownership and control over the product.
4.3.2 Trust and responsibility
An employee's satisfaction is linked to if the company trusts the employee to make their own decisions. This leads to the employees having the responsibility to make a difference in the company.
4.3.3 Clear directions
In order for employees to be satisfied and motivated to a project, there have to be clear directions from the leaders. This factor leads into having effective meetings, with a prepared agenda and goals.
4.3.4 Environment
Good colleagues with good communication and are open for helping each other is a factor for employees satisfaction. The vision for the company and the working on projects that requires continuous learning is also included in this factor.
4.3.5 The work gives value
The employees have to feel that their work gives value and makes a difference in the company. This means both individual value such as continuous learning, as well organisational values such as the solutions gives a revenue for the company.
4.3.6 Shared knowledge
Good communication and shared knowledge leads to happier employees, as well as the development of the employees individual development. Shared knowledge also leads to an overall understanding of the organisation.
5. Discussion and conclusion
The purpose of our research was to construct key success factors for autonomous teams at the small-scale. This was made by answering the three research questions “Is there any difference in organizational aspects prioritization between established and non-established autonomous agile teams in order to achieve a successful project?”, “What key factors are important in order to achieve success in an autonomous agile team-based IT project at a small scale?” and “What makes an individual team member satisfied in order to work as efficiently as possible in an autonomous agile team?”. This paper is grounded on the understanding of Agile teams and the authorization of autonomous teams at small-scale. From the findings of RQ1, we can see that both Culture and Quality is of high
prioritisation in the established autonomous agile team, while these organizational aspects are not even mentioned by the non-established autonomous agile team. The findings allow us to see that there exists a difference between established and non-established autonomous agile teams. We were able to merge existing knowledge with new knowledge to form six different themes (Customer Oriented,
Architecture, Individual Development, Team Setup, Entirety and Privilege) including key success
factors for enabling autonomous agile teams at the small-scale, answering RQ2. The findings from RQ3 resulted in six different elements ( Freedom and Flexibility, Trust and Responsibility, Clear
directions, Environment, The work gives value and Shared knowledge) that makes an individual team member satisfied in an autonomous agile team. From this study we came to a conclusion that the answers to all these research questions are important in order to have a successful autonomous agile team at small-scale. Organizations should utilize the key success factors founded from this investigation in order to form and build a solid team to work autonomously.
5.1 Limitations and future research
A fair limitation of this study is that we gathered too few participants to answer the survey. More participants would have increased the trustworthiness of the results. Additionally more qualitative studies such as surveys answered by other firms would also increase the generalizability of an investigation such as this one.
A future research suggestion would be to take the results of the key success factors in this investigation and analyse how important these key success factors are. The study should be answered by a lot of participants from a lot of different firms, working with autonomous agile teams. Additionally, for future studies about satisfaction, we recommend to use our results as a benchmark to measure how the employees' satisfactions evolve throughout the year.
6. Reference list
[1] "The Need For New Software Technology: Have We Overcome the Software Crisis?," in 2013 20th
Asia-Pacific Software Engineering Conference (APSEC), Seoul, SOUTH KOREA, 1996 pp. 2.
[2] N. Cerpa and J. Verner, “Why did your project fail?,” Communications of the ACM, vol. 52, no.
12, pp. 130–134, Dec. 2009.
[3] N. Munassar and A. Govardhan, “A Comparison Between Five Models Of Software Engineering,”
International Journal of Computer Science Issues (IJCSI), vol. 7, no. 5, pp. 94–101, Sep. 2010.
[4] D. Karlström and P. Runeson, “Integrating agile software development into stage-gate managed product development,” Empirical Software Engineering, vol. 11, no. 2, pp. 203–225, Jun. 2006.
[5] Beck, K.M., Beedle, M., Bennekum, A.V., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R.C., Mellor, S.J., Schwaber, K., Sutherland, J., & Thomas, D. (2001). Manifesto for Agile Software Development.
[6] M. Schur, “THE STATE OF AGILE,” PM Network, vol. 29, no. 9, pp. 16–17, Sep. 2015.
[7] L. Yilmaz and J. Phillips, “The impact of turbulence on the effectiveness and efficiency of software development teams in small organizations,” Software Process: Improvement and Practice, vol. 12, no. 3, pp. 247–265, May 2007.
[8] Xuesong Zhang and B. Dorn, “Agile Practices in a Small-Scale, Time-Intensive Web Development Project,” in 2011 Eighth International Conference on Information Technology: New Generations, 2011, pp. 1060–1061.
[9] Stray, V., Moe, N. B., and Hoda, R., "Autonomous agile teams: Challenges and future directions for research," presented at the Proceedings of XP’18 Companion, Porto, Portugal, 2018.
[10] D. Parker, M. Holesgrove, and R. Pathak, “Improving productivity with self-organised teams and agile leadership,” International Journal of Productivity and Performance Management, vol. 64, no. 1, pp. 112–128, Jan. 2015.
[11] R. Hoda, Agile Processes in Software Engineering and Extreme Programming – Workshops XP 2019 Workshops, Montréal, QC, Canada, May 21–25, 2019, Proceedings , 1st ed. 2019. Cham:
Springer International Publishing, 2019.
[12] R. Wageman, “Critical success factors for creating superb self-managing teams,” Organizational
Dynamics, vol. 26, no. 1, pp. 49–61, 1997.
[13] N. C. Magpili and P. Pazos, “Self-Managing Team Performance: A Systematic Review of Multilevel Input Factors,” Small Group Research, vol. 49, no. 1, pp. 3–33, Feb. 2018.
[14] H. Takeuchi, I. Nonaka, and work groups, “The new new product development game,” Harvard
Business Review, vol. 64, Jan. 1986.
[15] J. Wheeler, “Managing from the boundary: The effective leadership of self-managing work teams,” Academy of Management Journal, vol. 46, no. 4, pp. 435–457, Aug. 2003.
[16] A. Aldahmash, A. M. Gravell, and Y. Howard, “A review on the critical success factors of agile software development,” in Communications in Computer and Information Science, 2017, vol. 748, pp.
504–512.
[17] Chen, J., et al., The relationship between team autonomy and new product development
performance under different levels of technological turbulence. Journal of Operations Management, 2015. 33–34: p. 83-96.
[18] D. Gladstein, “Groups in Context: A Model of Task Group Effectiveness,” Administrative Science
Quarterly, vol. 29, no. 4, pp. 499–517, Dec. 1984.
