Agile Governance
How organisations govern their agile software development methods.
By Dino SontropMaster Thesis Information Sciences – Business Information Systems University of Amsterdam
16-12-2016
Abstract. Agile software development methodologies are a popular way to develop software in the software development industry. However, there is little theory on how organisations should arrange their Agile Governance framework; i.e. how to govern these methodologies. This research investigates through an exploratory multiple case study at three large financial institutions how these methodologies
are governed, what kind of problems are experienced, and how these problems can be improved. In this research it is investigated whether the theory of IT Governance can be applied when evaluating an Agile
Governance framework. It was found that their goals are similar but their mechanisms differ. Furthermore, organisations experience problems with the new management style that is needed for
agile development, the level of team autonomy is not sufficient to fully function as intended, and dependencies between agile teams are hard to manage. If organisations spend time and effort on these
areas, improvements will be made. Clear-cut advise on improvements is not possible since there is no right way to arrange an Agile Governance framework.
Keywords: Agile software development methodologies; IT Governance; Agile Governance; Framework;
Supervisor UvA: Arjan Vreeken
2nd Supervisor UvA: Tom van Engers
Internship at Ebicus
1
1. Introduction
In the early days of software development, the only software development method was the code-and-fix method which basically came down to writing some code and fixing the problems that existed in the code afterwards (Boehm, 1988). Systems quickly grew larger and more complex and there was a need for a more structured way to control and maintain their software development. The waterfall method was the first method which imposed a disciplined process upon software development with the aim at increasing the predictability and efficiency of the development process (Fowler, 2001).
The waterfall method received criticism for not having iterations to steer the process based on feedback during the process development process (Cusemano & Smith, 1995). Development processes took long and by the time the product was finished the possibility existed that the system had to be altered because of changed needs in the environment. In the 70s and 80s resistance grew against the waterfall approach and new software development methodologies were introduced with a focus on developing a system through iterative and incremental software development (Larman & Basili, 2003). These methodologies were usually considered bureaucratic with lots of documentation and strict planning to guide the development process (Fowler, 2001; Conboy & Fitzgerald, 2004).
These methods are now considered traditional because in 2001 a new way of software development was introduced. In that year a group of 17 process experts met and discussed the need for simple and lightweight iterative and incremental development methods. In this meeting the Agile Alliance was formed to promote agile software development methods (Larman & Basili, 2003). The adaption of these new methodologies that soon followed, required organisations to adjust their IT Governance frameworks to fit this new situation.
In 2007 the concept of Agile Governance was introduced by Qumer. Agile Governance aims, just like normal IT Governance, to maximize business value by governing IT operations effectively. Research has shown that organisations that put effort in their governance framework yield higher profits than organisations that do not (Weill, 2004). Therefore, the importance of a governance framework supporting large agile projects is well understood in the software development industry (Qumer & Henderson-Sellers, 2008).
Yet little is known about how organisations can effectively govern their agile software development methods (in theory) because research on the subject of Agile Governance is still in its initial phase (Luna, Kruchten, Pedrosa, Neto, & de Moura, 2014). This research contributes to this gap in the literature by investigating how organisations in practice govern their agile software development. The results of this research benefit practitioners that are searching for ways to improve their Agile Governance and it benefits researchers that can use the results for further investigation on the subject.
2. Research Question
2.1 Objective of this researchThe objective of this research is to contribute to the understanding of how organisations can improve the governance of their chosen agile software development method. This is achieved by providing a clear insight in the governance problems organisations face when using agile software development methods and how they deal with these problems.
2.2 Main research question
The interesting notion of governing agile software development methods is that it is needed by organisations to ensure that certain business objectives are met. At the same time governance structures have the potential to undermine the agile process because they are too intrusive. This raises the question of how organisations should organise their governance structures in such a way that agile software development teams can function at their full intended potential. The main research question therefore is:
2 2.3 Sub questions
In order to answer the main research question, a literature study was conducted on concepts that are related to this question. First, the concepts of agile and agile development methods are explained. Then, agile software development is explained and it is show how it differs from the traditional way of software development. When this is clear, the concept of IT Governance is introduced showing how organisations govern their software development. The concept of Agile Governance is introduced, explaining why it is different from IT Governance and how it relates to agile software development methods. As a final step, possible Agile Governance problems are presented that organisations have when governing their agile software development. The first sub questions will be answered after the literature study to create a clear understanding of the used concepts in this study. It is presented as follows:
SUB1: What is the essence of agile, agile development methods, and Agile Governance (problems)? Propositions are then formed from insights acquired from the literature study. These propositions are presented in section 4.7. These propositions helped us structuring the empirical study to answer the second, third, and final sub question. First, an overview must be created of the current situation:
SUB2: How do organisations govern their agile software development methods?
Once an understanding is created on the current practice, this research shifts its focus to the problems that exist in the current situation by answering the second sub question:
SUB3: What kind of governance problems do organisations encounter when using agile software development methods?
Once the problems are identified, the next step can be made by investigating how these organisations deal with these problems:
SUB4: How do organisations deal with these encountered problems?
By answering the last sub question this research presents an overview of how organisations deal with governance issues in agile software development environments. Following this, the main research question is answered. By answering the main research question this research fulfils its objective in creating an understanding on how organisations can improve their governance of their agile software development method.
2.4 Origin of this research
This research originated out of the experience of consultants of Ebicus who are working in agile teams at their clients. Ebicus is a IT consultancy company focusing on customer experience technology located in the Dutch town of Halfweg who initiated this research project. They are specialised in implementing and advising on Siebel and Oracle Customer Experience products. Ebicus has noted that in the recent years many their clients who are working with agile development methods not fully fathom this method of software development and that they have troubles with the governance of these development methods. Because of this experience, the assumption is made that organisations that use agile software development methods have troubles governing these methods. This assumption is used as the starting point of this research.
3. Agile software development methods
3.1 AgileThe concept of agile or agility is widely used throughout the literature in different contexts before it made its way into the world of software development. In 1991 the concept of agile manufacturing was introduced by a group of researchers from the Iaccoca Institute in USA (Nagel & Dove, 1991). The goal of the researchers was to develop a new method of manufacturing that could ensure competitiveness against Japanese manufacturers that were outperforming the USA at the time. In the years after the introduction of the concept there were many contradicting definitions of agile manufacturing and diverse
3 meanings over what agility meant across different markets (Conboy & Fitzgerald, 2004). This is why they conducted a literature review on the concept of agility in a multi-disciplinary nature. They propose the following definition of agility:
‘the continual readiness of an entity to rapidly or inherently, proactively or reactively, embrace change, through high quality, simplistic, economical components and relationships with its environment’ (Conboy & Fitzgerald, 2004, p. 4).
This definition was based upon findings in their literature review that agility was a combination of the concepts of flexibility and leanness. Conboy and Fitzgerald (2004) define flexibility as follows: ‘the ability of an entity to proactively, reactively or inherently embrace change in a timely manner, through its internal components and its relationships with its environment’ (p. 3). The researchers based this definition on the findings that flexibility is mostly described as a proactive or reactive ability to change within a certain time constraint. It is important to point out that the time constraint characteristic that was found in the definitions of flexibility, did not focus on speed as a measurement of success alone. The focus on time within the concept of flexibility is on that there is a constraint, whether this is a slow or fast response does not matter (Conboy & Fitzgerald, 2004). This is an important difference in making a distinction between the definition of flexibility and agility. A large emphasis was found on fast, quick and rapid responses to the environment in the literature review of Conboy and Fitzgerald (2004) when trying to define agility. They also found that that the concept of agility embraces change as an ongoing activity, whereas in the literature describing the concept of flexibility there are no references to continual change (Conboy & Fitzgerald, 2004).
Leanness is mostly defined as the elimination of waste and doing more with less (Aitken, Christopher & Towill, 2002). Conboy and Fitzgerald (2004) define leanness as ‘the maximisation of simplicity, quality and economy’ (p. 3). The concepts leanness and agility have quite a large overlap but should not be confused with each other. As was stated, leanness aims to eliminate all waste. Agility on the other hand also aims to eliminate waste, but not if that undermines the ability to respond to change. (Conboy & Fitzgerald, 2004).
3.2 Agile software development
As was stated in the introduction, the concept of agility was introduced in the software development industry by the Agile Alliance. This group of researchers introduced the manifesto for agile software development with the purpose of uncovering better ways of software development (Fowler & Highsmith, 2001). This manifesto was a start into defining what it meant to be developing software in an agile way. In this agreement four ground rules were given:
Individuals and interactions over process and tools; Working software over comprehensive documentation; Customer collaboration over contract negotiation;
Responding to change over following a plan (Fowler & Highsmith, 2001, p. 2).
According to Fowler and Highsmith (2001), the most important priorities of agile software development were: continuous delivery of software to the client, the ability to react to changing requirements to create competitive advantage, the ability to deliver software in short periods of time and close collaboration between the business side of the organisation and the developers. They did not refute the practices of the traditional methods of software development, such as the waterfall or the rational unified process, but opted for moderation. Cohen, Lindvall and Costa (2004) framed this nicely: ‘Agile methods will probably not ‘win’ over traditional methods but live in symbiosis with them’ (p. 46).
3.3 Why are agile development methods different? Adaptive
Firstly, agile methods are more adaptive than predictive. Fowler (2001) states that traditional methodologies usually separate design from development. When design is separated from development, there is a focus on an extensive and detailed design phase where the whole system is tried to be captured
4 in models, documentation, and requirements. Fowler (2001) mentions that even if all the requirements are captured, there is no guarantee that these requirements will hold up over a longer period of time. The modern market is too unpredictable and volatile to predict its future. Highsmith (2002) states that agile development methods recognise and accept this unpredictability and abandon the idea of following a plan, explaining the fourth rule of the agile manifesto. To cope with this unpredictability, these methods introduce short and fast iterative cycles to incrementally develop software. These cycles function as a feedback mechanism to exactly know where one is in the development process (Fowler, 2001). The aim of iterative software development is to produce a working product that can be tested, effectively explaining the second rule of the agile manifesto. These iterative cycles provide a way to spot design flaws early in the development process so action can be taken accordingly. Another point that is addressed by Fowler (2001) regarding the adaptability of agile methodologies is that because when one refrains from making predictions over the development process, it means that fixed price contracts with customers (traditional approach) are no longer possible since the outcome is unclear. To provide customers with another way to influence the outcome they are involved in the development in which they can monitor the process and steer it accordingly to their wishes. This explains the third rule of the agile manifesto of section 3.2.
People
Secondly, the power in the agile development process lies with the people in the teams and the process around them is there to support them in their creative process (Fowler, 2001). This is the other way around in traditional development where people are standardized to the process and are seen as parts that can be replaced with more ease. In agile software development the focus lies on people that develop individual skills and creating an environment with high levels of collaboration (Highsmith, 2002). Another point introduced by Highsmith (2002) regarding the process is that agile development methodologies have barely sufficient methodology to provide a workable approach to software development. The unpredictable environment requires process flexibility and room for creativity to tackle unforeseen problems. This cannot be achieved when flexibility and creativity are impeded by a more traditional heavy structured methodology. Both Fowler (2001) and Highsmith (2002) arguments explain the first rule of the agile manifesto: putting people over process and tools.
In conclusion Highsmith and Cockburn (2001) state that agile methods are ‘not the practises they use, but their recognition of people as the primary drivers of project success, coupled with an intense focus on effectiveness and maneuverability’ (p. 3). Agile development methods are different from traditional methods in the underlying principles on which the methodologies are built. They provide the capability to create and respond to change, balance flexibility and structure, draw creativity and innovation out of a development team, and provide organisations a method to survive through uncertain market environments (Highsmith, 2002).
3.4 The benefits of agile methods and their adaption in practice
The introduction of the agile manifesto is considered by many to be the starting point of the change from traditional theories to a widespread recognition and adaptation of agile software development methods in practice. At the time of the introduction, scientific proof on the benefits of these agile development methods was low (Abrahamsson, Salo, Ronkainen & Warsta, 2002; Abrahamsson, Warsta, Siponen & Ronkainen, 2003). In 2008 a large literature review was held by Dybå and Dingsøyr finding that agile development can improve job satisfaction, productivity, and increase customer satisfaction. In this research they stated again that more scientific research was needed.
Although empirical evidence was missing, the adaptation of agile development methods grew enormously at small and mid-sized organisations to large global corporations to 84% in 2006 and 95% in 2015. These figures are based on the yearly global surveys of 2006 and 2015 on the adaptation and perceived benefits of agile methods by the company VersionOne. In the survey of 2015 the biggest reported benefits were the ability to manage changing processes, improved project visibility, and increased team productivity. The most popular agile software development method was scrum at 58%.
5 With the rapid implementation of agile methods in the software development industry, the research on agile methods lagged behind (Abrahamsson, Conboy & Wang, 2009). In more recent years two researches focussing on comparing agile software development methods with traditional methods were executed. The research of Matharu, Mishra, Singh and Upadhyay (2015) showed that agile methods are an effective solution to the challenges the software industry faces, including: Increased software complexity, dynamic user requirements, low budgets, and tight schedules. The research of Moniruzzaman and Hossain (2013) found evidence that agile methods are lightweight and can be implemented quickly, are highly adaptable, deliver software more rapidly, require no long term planning, has active communication and feedback with the client, show reductions in cost and time and increases success possibilities of software projects. Overall it can be concluded that agile development methods have proven themselves to be, in most situations, an improvement over traditional methods of software development and that they are here to stay.
While the researches prove the benefits and the survey the popularity of agile methods, organisations implementing and using agile software development methods also face challenges. The VersionOne survey of 2015 reported that the greatest concerns about adopting an agile software development methodology were the loss of management control, the lack of upfront planning, and management that was opposed to change. These concerns mainly focus on how agile software development methodologies are managed. In other words, the software development processes will have to be governed in a different way than they used to be.
4. IT Governance
4.1 IT GovernanceWebb, Pollard and Ridley (2006) introduce IT Governance as a concept that has a close relation to corporate governance. Corporate governance is the responsibility of the board of directors and revolves around the strategic direction, policies and procedures, control and accountability systems, performance management, and risk management of the organisation (Barrett, 2001). Corporate governance is the main governance framework of an organisation and the IT Governance framework will be based on its principles. The IT Governance framework on its part, can provide critical information on strategic goals of the organisation and can therefore influence on how the corporate governance structure is set up (Van Grembergen, 2004). Because of this close connection, it is no surprise that the definition of IT Governance resembles the responsibilities of corporate governance:
‘IT Governance is the strategic alignment of IT with the business such that maximum business value is achieved through the development and maintenance of effective IT control and accountability, performance management and risk management’ (Web et al., 2006, p. 7).
After reviewing multiple definitions of the concept, Webb et al. (2006) derived five key points that covered the broad aspect of IT Governance: Strategic alignment, delivery of business value through IT, performance management, risk management, and control and accountability (p. 7). Because IT Governance is integrated with corporate governance, it falls under the responsibility of the board of directors. IT management on their part are responsible for the correct execution of tasks and procedures that follow out of the framework. They decide which IT services and products best fit the IT Governance strategy and maintains the day by day IT operations (De Haes & Van Grembergen, 2004).
4.2 Elements of IT Governance
As can be concluded out of the previous section, the concept of IT Governance is broad and covers many aspects. An IT Governance framework of an organisation consist of a combination of structures, processes, and relational mechanisms (Webb et al., 2006; De Haes & Van Grembergen, 2004; Weill, 2004). Every organisation has to determine with which combination of structures, processes, and mechanisms they want to define their own IT Governance structure. There is no right way to govern IT, what works for one company might not work for the other (De Haes & Van Grembergen, 2004). This research classifies the structures, processes, and relational mechanisms as elements and classifies the
6 content of the elements as mechanisms. Table 1 illustrates the most common mechanisms for each element of IT Governance. In the coming sections each element and most important mechanisms will be explained.
Table 1 - Elements of IT Governance and their mechanisms.
Element Structures Processes Relational Mechanisms
Tactics IT executives and accounts Committees and councils Strategic IT decision-making Strategic IT monitoring Stakeholder participation Business/IT partnerships Strategic dialog Shared learning Mechanism - Roles and
Responsibilities - CIO on board - IT strategy committee - IT steering committee(s) - IT organisation structure - Strategic information systems planning - Balanced (IT) scorecards - Information economics - Service level agreements - CobiT and ITIL - IT alignment / governance maturity models - Active participation by principal stakeholders - Collaboration between principal stakeholders - Partnership rewards and incentives - Business / IT colocation - Shared understanding of business / IT objectives - Active conflict resolution (nonavoidance) - Cross functional business / IT training - Cross functional business / IT job rotation
Note. Reprinted from De Haes & Van Grembergen (2004, p. 2). Structures
In table 1 De Haes and Van Grembergen (2004) introduce the mechanisms that make up the element structure as part of the IT Governance framework of an organisation. According to the researchers, the roles and responsibilities of the involved parties should be clearly defined and well communicated throughout the organisation by the board and executive management. Also, the CEO is responsible for the overall strategy of the company but on the subject of IT strategy and policies the CIO should be involved in the decision making process. Furthermore, strategy and steering committees may be introduced to support the board of directors or management in IT Governance related matters. These committees may oversee certain projects and make sure IT Governance issues are addressed during board meetings.
The most important feature of the structure of IT Governance is how the IT organisation defines the allocation of decision authority on IT related matters. Weill (2004) introduced six recognisable archetypes that define decision and input rights on IT Governance within organisations: Business monarchy, IT monarchy, federal, duopoly, feudal, or anarchy. An overview of the archetypes and where the decision power resides for that archetype can be found in table 2.
7 Table 2 - Different archetypes identified by Weill.
Decision rights or input rights for a particular IT decision are held by:
Business Monarchy A group of, or individual, CxOs. Includes committees comprised of senior business executives (may include CIO). Exclude IT executives acting independently.
IT Monarchy Individuals or groups of IT executives.
Feudal Business unit leaders, key process owners, or their
delegates.
Federal CxO and at least one other business group (e.g., CxO and
BU leaders). IT executives may be additional participants.
IT Duopoly IT executives and one other group (e.g., CxO or BU
leaders).
Anarchy Each individual user.
Note. Reprinted from Weill (2004, p. 5). Processes
Processes provides the mechanisms that monitor organisational performance and provide the information needed for strategic decision making. According to De Haes and Van Grembergen (2004), maturity models and scorecards are an excellent way to assist organisations in achieving a functioning IT Governance framework and achieve business and IT alignment. Balanced scorecards and Information Economics are methods that rate certain performance indicators to measure the business performance. Maturity models are used to measure business IT alignment and governance maturity (De Haes & Van Grembergen, 2004; Luftman, 2000). They assist organisations in evaluating their current status and help setting priorities for improvement. De Haes and Van Grembergen (2008) found that organisations with higher IT Governance maturity levels were likely to have higher business IT alignment maturity.
Methods such as the balanced scorecard, information economics, and maturity models can be a part of a control framework. While defining the concept of IT Governance, Webb et al. (2006) recognised that control frameworks are a large part of the IT Governance structure. Control frameworks support organisations with the implementation of processes, procedures, and policies that enable them to benchmark their organisation to monitor performance (Web et al., 2006). Organisations implement control frameworks for various reasons: Regulatory or financial control; control of decision-making regarding IT investment; maintaining strategic alignment, and security (Webb et all, 2006, p. 5). Reflecting to the chosen definition of IT Governance and its key points in this research, control frameworks provide the means to cover almost all aspects of IT Governance. Various control frameworks exist and can focus on different aspects of the organisation. These control frameworks provide management the techniques they need for effective involvement on IT related governance decisions (Weill & Ross, 2005). One of the more well-known frameworks that focusses on controlling information systems is the Control Objectives for Information and related Technology (CobiT) framework. It provides management guidelines on 34 IT processes, their corresponding maturity models, and key performance indicators (De Haes & Van Grembergen, 2004). CobiT is usually used simultaneously with other control frameworks. For example, if an organisation is an IT service provider the IT Infrastructure Library (ITIL) is usually used, which provides templates and best practices for core IT operational processes of such an organisation. (Cater-Steel, Tan & Toleman, 2006).
Relational mechanisms
Relational mechanisms focus on the ‘soft’ side of IT Governance by improving communication, shared learning, and strategic dialogue. De Haes and Van Grembergen (2004) state that even though an organisation might have the right IT Governance structures and processes in place it is possible they fail because of misalignment between business and IT people. Listed in table 1, De Haes and Van Grembergen (2004) proposed multiple ways to prevent this from happening. According to Weill and Ross (2005), it is the responsibility of the management to communicate the IT Governance framework to ensure desirable behaviours and accountability by employees. Weil and Ross (2005) state that if an organisation clearly communicates a well-defined and transparent IT Governance framework, this will lead to the desired IT behaviour intended by the framework and creates individual accountability of employees.
8 4.3 Agile Governance
As was stated in section 4.2 under the subsection processes, control frameworks play a large role in an IT Governance framework. Qumer and Henderson-Sellers (2008) analysed seven of these control frameworks, including CobiT and ITIL, and came to the conclusion that these frameworks were too bureaucratic and labour-intensive to be used in agile environments. In accordance Dahlberg and Kivijarvi (2006) stated that the popular frameworks COBIT and ITIL were also judged as labour intensive and as too detailed by some users. This is why the concept Agile Governance was introduced by Qumer in 2007.
The concept of agility and the principles of agile software development methods versus the concept of IT Governance can be viewed as a contradiction (Luna et al., 2014). As explained in section 4.2, the governance of IT within organisations has a various mixture of structures, processes, and relational mechanisms focussed on control, accountability, performance, and risk management in place to maximize business value. However, with the introduction of agile software development within organisations promoting autonomy, flexibility, and creativity in the development one could argue that these concepts conflict with each other.
Agile Governance is an emerging field in IT Governance and aims at identifying both agile and governance capabilities to improve business agility (Luna et al., 2014). It is seen as a way to support agile development methods without large intrusive governance structures that could disrupt the agile process. For the purpose of this research the definition of Qumer (2007) of Agile Governance is chosen. This definition focusses on software development methods alone, while others have broader scopes (Luna et al., 2014). The definition as proposed by Qumer (2007):
‘An integrated Agile Governance involves lightweight, collaborative, communication-oriented, economical and evolving effective accountability framework, controls, processes, structures to maximize agile business value, by the strategic alignment of business-agile goals, performance and risk management’ (p. 159).
When the above definition of Agile Governance is compared with the definition of IT Governance in section 4.1, the following similarities and differences can be found:
Both concepts focus on maximizing business value by achieving strategic alignment of business goals.
Both concepts involve the general focus of governance: Introducing a framework for the accountability, control, processes, structures, performance, and risk management of IT.
The definition of Agile Governance explicitly emphasises on which features it differs from IT Governance: Lightweight, collaborative, communication-oriented, economical, and evolving. The following points are all adopted from Qumer and Henderson-Sellers (2008):
o Lightweight emphasises governance without unnecessary overhead and supporting the agile principles.
o The collaborative and communication-oriented aspect of Agile Governance focusses on the relational mechanisms of De Haes and Van Grembergen (2004) in table 1.
o Economical emphasises the importance of assessment, improvement, self-discipline, and self-accountability within agile software development teams to reduce governance costs.
o Evolving because of the flexible nature of agile development making the governance adaptable to changes in the organisational environment.
It can be concluded that Agile Governance is in essence similar to IT Governance but focusses on supporting agile software development methodologies. Qumer and Henderson-Sellers (2008) came to a similar understanding stating that ‘normal’ IT Governance is aimed at maximizing business value and that Agile Governance, while in the end still aiming at maximizing business value, is more focussed in achieving this by being a lightweight version of IT Governance resulting in the reduction of overhead and bureaucracy.
9 4.4 Research on Agile Governance in practice
It is recognised that if large organisations want to scale up their agile approach, it is important to have a governance framework (Qumer & Henderson-Sellers, 2008). While this importance of Agile Governance is recognised in practice, there is not a great number of researches available on the successful governance on agile development methods (Qumer, 2007; Luna et al., 2014). In 2014, Luna et al. conducted the first and thus far only literature review on combining agile and governance capabilities. Their aim was to create a common ground on the concept of Agile Governance and its challenges for practitioners. After their review, they proposed the following principles of Agile Governance:
Good enough governance: The governance framework of an organisation should be reviewed and adjusted continuously to the environment it serves.
Business-driven: All decisions should be based on pursuing the business strategy.
Human focused: Understanding the importance of using people for creativity in the development process and introducing the right incentives to stimulate communication and collaboration. Based on quick wins: Using the celebration of quick wins to create a positive flow which should
be used to motivate and provide feedback to the team to pursue better results and incrementally develop the governance framework that supports the team.
Systematic and adaptive approach: Teams should focus on adaptability instead of predictability to better adjust to the needs of the environment.
Simple design and continuous refinement: Teams should always choose to develop the solution which has a simple design and can be improved fast and with ease (Luna et al., 2014, p. 135-136). It can be concluded that these principles are abstract and can interpreted in multiple ways. There are no practical solutions available in the theory on how organisations should govern their agile software development teams. As the theory on IT Governance shows, researchers agree that there is no right way to arrange a IT Governance framework. Because of this, this research argues that this also applies to the arrangement of an Agile Governance framework.
Since Agile Governance is quite a new concept, this research inherently calls for the question if the concept of Agile Governance has a legitimate right to exist in the practise or if it is just a minor derivative of the concept IT Governance. Therefore, the interviews will be concluded with testing if the six principles of Agile Governance of Luna et al. (2014) are recognised as important in the practice. Also, the characteristics of Agile Governance will be explained (lightweight, collaborative and communicative, economical, and evolving) and it will be asked if this concept has a right to exist in the current practice according to the interviewees.
4.5 Agile Governance problems
Since Agile Governance has proven to be a relative new research subject, there are no studies available focussing on governance problems in agile software development environments. There are however several researches available about the challenges of the implementation and continued use of agile software development methodologies. Almost all researches speak of challenges in their papers and thus this research investigates existing governance problems. This research argues that challenges are instances in time that when they are not correctly acted upon, they might become problems.
In addition, it is shown in section 4.2 that traditional IT Governance consists of a mixture of mechanisms of the elements structures, processes, and relational mechanisms. Also, it was shown in section 4.3 that Agile Governance has a similar goal as IT Governance but with an emphasis on characteristics better suited for agile software development. Based on the points above this research argues that Agile Governance can be divided in the same elements as IT Governance is in section 4.2. Within each element problems are selected out of five papers that were selected after a literature search on the combination of the following keywords: organisational; management; governance; challenges; problems; issues; implementation; adoption; agile development methods; and agile practices. Two older papers and three recent papers were selected and are presented in table 3
10 Table 3 - Overview of the selected papers.
Title Author and year Reason selected
Management challenges to implementing agile processes in traditional organisations.
Boehm & Turner, 2005. Relevant and proven paper with a decent amount of citations (248). Challenges of migrating to agile
methodologies. Nerur, Mahapatra & Mangalaraj, 2005. Relevant and proven paper with a great number of citations (693). Water-scrum-fall is the reality of agile
for most organisations today.
West, 2011. West has a non-empirical approach using business surveys to describe (among other problems) governance problems. Relevant reflection of the practice.
People over process, Key challenges in agile development
Conboy, Coyle, Wany & Pikkarainen, 2011.
Detailed paper describing the challenges in the relational mechanisms element. Obstacles in moving to agile software
development methods; at a glance. Gandomani, Zulzalil, Ghani, Sultan, 2013. Combining challenges found in a variety of papers and presenting them in categories resembling the elements of De Haes and Van Grembergen (2004).
The problems listed under the elements below only focus on IT Governance problems after the implementation of an agile software development method. To create a chain of evidence throughout this research, the problems are coded. These codes will be used to code the interviews and to refer to particular problems when presenting the results of this research.
Structures
Goal: Provides the organisation with a structure were decision and input rights are allocated to roles and responsibilities in the agile software development process. The following problems can occur when an organisation does not set up this structure properly:
S1. Management style:
S1.1. A shift in management style from command and control to leadership and collaboration is needed (Nerur et al., 2005; Gandomani, Zulzalil, Ghani, Sultan, 2013; Boehm & Turner, 2005).
S1.2. Devolved decision making makes project managers feel like they lose control (Conboy, Coyle, Wang & Pikkarainen, 2011).
S2. Team autonomy:
S2.1. The organisation should provide certain level of autonomy to the development team to support the flexible and responsive nature of agile software development (Nerur et al., 2005).
S3. Product owners’ decision rights:
S3.1. Sometimes business analysts become product owners without having the proper authority in making business and technology decisions which in turn slow down the agile process (West, 2011).
Processes
Goal: Provides the organisation with mechanisms that keep the agile development process running, monitor the performance of this process and provide the information needed for strategic decision making by management. The following problems can occur when an organisation does not manage these processes properly:
P1. Progress measurement:
P1.1. Traditional compliance and measurement approach of software development measurement might be inadequate for agile development. Acceptance of uncertainty
11 because of agility requires different ways of measurement (Nerur et al., 2005; Boehm & Turner, 2005).
P2. Risk management:
P2.1. In traditional approaches risks are mitigated by producing documents on problems and solutions, in agile approaches risks are mitigated by producing and evaluating working software (West, 2011).
P3. Resource management
P3.1. Resource management of people often leads to agile team members working on multiple projects because of project managers wanting to maximizing utilization. This has a negative effect on team collaboration (West, 2011).
P3.2. Agile processes generally have less detailed plans before the project is started therefore there is more uncertainty about costs and timelines which can lead to problems with project funding (West, 2011).
P4. Iterate development:
P4.1. Organisations need to adjust their processes in multiple parts of the organisation to accommodate iterative development (Nerur et al., 2005; Gandomani et al., 2013; Boehm & Turner, 2005).
P4.2. Activities that belong inside the iteration (e.g. requirement analysis, testing) are excluded from it because of constraints, tradition, or other processes (West, 2011). Or they are excluded because of the existence of specialist departments. This is against the agile idea of incorporating all knowledge in the team and only using help for support (West, 2011).
P5. Variability management:
P5.1. There is little theory about the scalability of agile development teams (Nerur et al., 2005).
P5.2. Management has problems managing dependencies between multiple agile development teams (Boehm & Turner, 2005).
P5.3. If the organisation uses agile and traditional development teams, one can expect a different outcome when not managed correctly (Boehm & Turner, 2005).
Relational Mechanisms
Goal: Provide the means to increase business and IT collaboration, strategic dialogue, and pursue optimal communication in the agile development process. The following problems can occur when an organisation does not use the right mixture of relational mechanisms:
RM1. Organisational culture:
RM1.1. The culture of the company needs to adapt to a new way of working. Some may resist to this change or have no motivation for adaption (Nerur et al., 2005; Gandomani et al., 2013; Conboy et al., 2011; Boehm & Turner, 2005).
RM1.2. Organisations with a project culture separate team members after the project is done instead of keeping team together which is advocated in agile methods. This lead to overhead because team members will have to learn working with each other each time a new project starts (West, 2011).
RM2. Business & IT collaboration:
RM2.1. Lack of prioritisation of needs by the business leads to problems with planning and organising software development (Letho & Rautiainen, 2009).
RM3. Team composition:
RM3.1. Selecting people with high specialisations could lead to more overhead and increases necessary coordination (Letho & Rautiainen, 2009).
RM3.2. The ‘master of all trades’ requirement for developers in the agile process can be burdensome for team members (Conboy et al., 2011).
12 RM4.1. Bad communication between the development team and the product owner (Letho &
Rautiainen, 2009).
RM4.2. Value and trust between agile software development team members is needed for optimal communication and collaboration that benefits development process efficiency (Nerur et al., 2005).
RM4.3. With less documentation, knowledge becomes tacit in the minds of people in the development team (Nerur et al., 2005; Gandomani et al., 2013).
RM5. Individual employee:
RM5.1. Lack in (continuous) training of agile principles and practices can undermine the agile process severely (Conboy et al., 2011).
RM5.2. Agile methodologies require high levels of competence of not only technical but also social skills of developers (Nerur et al., 2005).
RM5.3. Members of agile teams can have problems in self-organising and setting priorities (Conboy et al., 2011).
RM6. Stakeholder relationships:
Active involvement in the agile development process by stakeholders is needed for it to work properly (Nerur et al., 2005).
Developers having no business knowledge and involving the stakeholders in the development process can lead to a lack of trust of the stakeholders (Conboy et al., 2011).
RM7. HR infringement:
RM7.1. HR departments and policies can counteract the empowerment of people if they still have policies focussed on traditional software development (Boehm & Turner, 2005). RM7.2. Performance evaluations should not only focus on technical skills but also on the social
and creative skills (Conboy et al., 2011).
RM7.3. Reward systems should be balanced between individual and team performance (Nerur et al., 2005; Boehm & Turner, 2005).
RM7.4. The search for employees that have both high technical and soft skills could lead to problems in recruiting (Conboy et al., 2011).
4.6 Conclusion
The theoretical framework will be concluded by answering the first sub-question:
SUB1: What is the essence of agile, agile development methods, IT Governance, and Agile Governance (problems)?
The essence of agile is that a software development team is in a continual state of readiness to respond to changes in its environment. It does so in a timely manner striving to develop a solution that is simplistic, of high quality, and takes economical components and relationships with its environment in mind.
The essence of agile development methods is to provide a new way of developing software based on principles that are derived from the concept of agile. It emphasises the importance of people and communication with everybody involved in the development process, it focusses on producing working software, makes effort to involve the customer in the development process, and most of all emphasises the importance of being able to respond to changes in the environment.
The essence of IT Governance is that it provides the strategic alignment between IT and the business such that maximum business value is achieved. It is a control framework that consists out of a combination of mechanisms of the elements structures, processes, and relational mechanisms providing means to the organisation for clear role, responsibility and accountability structures, and effective performance and risk management.
The essence of Agile Governance is very similar to IT Governance. It also provides the strategic alignment between IT and the business aiming at maximizing business value through developing a control framework consisting of the same elements providing means for effective performance and risk management. The difference is that it aims to support the way of agile software development. Agile Governance emphasises the importance that the control framework should be avoiding unnecessary
13 overhead, promoting collaboration, communication and self-discipline, and constantly evolve due to changes in the environment.
The essence of Agile Governance problems is, problems that arise when organisations have implemented agile software development methods but do not have a governance control framework in place that consists of the right structures, processes, and relational mechanisms to supports these development methods.
4.7 Propositions
In this section two propositions are presented that were derived out of the theory for sub-questions 2 and 3.
The proposition for SUB2 is based on the following argumentation. This research argues that an Agile Governance framework also consists out of a combination of mechanisms of the elements structures, processes, and relational mechanisms. Also, this research argues that one or more mechanisms listed for each element intable 1 will be present in the framework. Lastly, this research argues that there is no one size fits all solution and thus organisations will have to select their combinations based on their own experience. These arguments lead us to the following proposition for sub question 2:
SUB2: How do organisations govern their agile software development methods?
Proposition 1: Agile software development methods are governed by an Agile Governance framework that consists out of a combination of mechanisms of the elements structures, processes, and relational mechanisms. One or more of the mechanisms present will come out of table 1. This combination of elements is unique for each organisation.
The proposition of SUB3 is based on assumptions, not arguments, as there is little theory to back up these assumptions. This research assumes that organisations have problems governing their agile software development methodologies. Also, this research assumes organisations having one or more problems identified out of the literature and presented in section 4.5. Lastly, this research assumes this list is not exclusive and that other problems exist that are not known in the literature. These assumptions lead to the following proposition for sub question 3:
SUB3: What kind of governance problems do organisations encounter when using agile software development methods?
Proposition 2: Organisations encounter one or more of the problems from each of the elements structures (S1-S3), processes (P1-P5) and relational mechanisms (RM1-RM6) listed in section 4.5. Furthermore, this research proposes that this list is not exclusive as other problems exist.
5. Methodology
This research has a practice-oriented approach conducting multiple case studies making use of the qualitative research method of semi-structured interviewing. In the next sections the chosen approach will be explained.
5.1 Research type
According to Verschuren and Doorewaard (2010), ‘practice-oriented research is meant to provide knowledge and intervention that can contribute to a successful intervention in order to change an existing situation’ (p. 45). The chosen approach suits this research best because its objective is to contribute in solving an existing practical problem. As the chosen field of research is relatively new and little is known on theoretical or practical solutions for governance problems when using agile software development methods, this research will mainly focus on the first step of the intervention cycle of practice-oriented research; the problem analysis phase (Verschuren & Doorewaard, 2010). Because of the lack of standards in the existing theory, this research can be seen as exploratory.
Creswell (2007) states that qualitative research is a suitable research method when there is little or no predetermined information from literature or when one cannot rely on results from other research studies. Qualitative methods are used to explore complex problems and create detailed understandings
14 of those problems and their contexts (Creswell, 2007). This approach falls well in line with the aim of this research to perform a thorough problem analysis in which in-depth knowledge is required to create an understanding of the possible problems that exist and the context in which these problems reside. 5.2 Research setup
In order to perform this problem analysis, multiple case studies are conducted. According to Yin (2002), the case study research method is an excellent pick if one wants to ‘investigate a contemporary phenomenon within its real-life context, especially when the boundaries between phenomenon and context are not clearly evident’ (p. 13). In this study a multiple case study approach is chosen due to the similarity of expected results over different cases.
Verschuren and Doorewaard (2010) state that case studies have two advantages that are beneficial to this type of research. First off, they state that case studies are an excellent way to create a general picture of the research object. When attempting to change a situation, it is imperative to create an understanding of the larger context surrounding that situation. Without this understanding, it is impossible to anticipate the consequences of an intervention (Verschuren & Doorewaard, 2010). Yin (2002) supports this notion by stating that a case study in particular is an excellent way to capture the environment in which the investigated phenomenon resides. This is an important point in practice based research since through conducting a problem analysis the ultimate aim is to propose an intervention to solve this problem. As Verschuren and Doorewaard (2010) state, it is impossible to propose an intervention without knowledge of the environment.
The second advantage is that the case study method has a flexible research setup that does not require much pre-structuring. In research fields that are quite new, such as governance in agile working environments, and where the outcome of the research cannot be easily predicted a flexible research setup is valuable because its course can be adjusted along the way. This is especially true in practice oriented research where situations tend to change quite often (Verschuren & Doorewaard, 2010). 5.3 Quality
Even though it is recognised that the evidence that is created within a multiple case study is considered robust and reliable (Baxter & Jack, 2008), it is a good practice to pay attention to the validity and reliability of this study. Yin (2002) has introduced four tests to assess the validity and reliability of case studies. According to Yin (2002), applying these test throughout the case study will increase the quality of the research remarkably. These tests are:
Construct validity: Establishing correct operational measures for the concepts being studied.
Internal validity: Establishing a causal relationship, whereby certain conditions are shown to lead to other conditions, as distinguished from spurious relationships.
External validity: Establishing the domain to which a study’s findings can be generalized.
Reliability: demonstrating that the operations of a study can be repeated, with the same results (Yin, 2002, p. 37).
The test of internal validity is not applicable to exploratory research and will therefore not be implemented in this research (Yin, 2002). Each test has their own methods in increasing the quality of the research. In the coming sections whenever one of these methods is used, a reference will be made to notify how it contributes to which test.
5.4 Case selection
Since this research is exploratory, Verschuren and Doorewaard (2010) opt for a selection of cases that show similarities since it is difficult to obtain assertions if cases are to different. Yin (2002) calls this literal replication. According to Yin (2002), cases in a multiple case study should not be selected based on a sampling logic but on a replication logic. Each case should be viewed as a standalone experiment. Using replication logic while selecting cases increases the external validity of the research.
The unit of analysis in this research is an agile software development team as a whole. One of the characteristics of agile software development teams is that they have well defined boundaries within the
15 team between members and outside the team between other agile teams or organisational boundaries. This makes them fairly easy to recognise within the investigated organisations. The choice to investigate the unit of analysis as a whole make this research a holistic multiple cases study (Yin 2002). Multiple single cases will be investigated that each have their own context.
To select the right cases a rich theoretical framework needs to be developed that describes the conditions under which the investigated phenomenon is likely to be found (Yin, 2002). By explaining the essence of the important concepts in section 4.6, showing their interrelationships in chapters 3 and 4 and keeping the replication logic of Yin (2002) and the logic of Verschuren and Doorewaard (2010) in mind, three cases have been selected showing similar characteristics.
The cases were selected at departments within these organisations that had already implemented, and therefore had experience with, an agile software development method and had multiple agile software development teams functioning alongside each other. The organisations chosen were large enough to have put considerable thought into setting up a governance framework around their chosen agile software development method. An overview of the organisations can be found in table 4.
Table 4 - Selected cases and their characteristics.
Case A Case B Case C
Industry* Finance Finance Finance
Active* Global Global Global
Department of the case* IT-side IT-side IT-side
ASDM** in use Scrum Scrum Scrum
ASDM** in place < 1 year 5-6 years 3 years
Developing for (customer) Business-side Business-side Business-side
Note. *More details cannot be given due to privacy reasons. **ASDM = Agile Software Development Method. 5.5 Data collection
According to Creswell (2007), high level of detail can only be established by talking directly with people. Therefore, the method of semi-structured interviews is chosen. Semi-structured interviews have the characteristic that they are flexible which is in line with the choice for a practice based research and its exploratory nature. A semi-structured interview also provides the possibility to explore relevant notions that might not be known after completing the theoretical framework but are interesting to pursue. The structure of the interview is based on the two propositions that were presented in section 4.7. The found Agile Governance problems listed in section 4.5 have been divided between the elements that were proposed by De Haes and Van Grembergen (2004). The interview questions can be found in appendix A. In total 7 interviews were conducted at 3 different organisations. The aim was to conduct two interviews at each organisation. One interview with a managing position that had control over one of more agile software development teams and one interview with a team member of an agile team that was controlled by the other interviewee that held the managing position. This was done so different perspectives could be combined to create a full picture of the governance problems within each case. An overview of the interviewees can be found in table 5.
16 Table 5 - Interviewees of the cases.
Case A Case B Case C
Number I1 I2 I3a & b I4 I5 I6
Duration interview 1:09:49 1:14:34 1:20:40 & 35:41 1:10:15 52:41 1:10:29 Position Managing position outside the team Member of
agile team Managing position outside the team Managing position outside the team Managing position inside the team Member of agile team Years experience working with ASDM* 4+ years as SM 6 months as team member 6-7 years as PM 4-5 years as PM 2 years BA, 1 year SM, 1 year PO 2 years as team member
Note. SM = Scrum Master, PM = Project Manager, BA = Business Analyst, PO = Product Owner. 5.6 Data Analysis
The interviews were audio-recorded and after transcription send to the interviewees for feedback and final approval. After the final approval, the interviews were then coded using the codebook that is available in appendix B. The codebook is based on the propositions in section 4.7, the Agile Governance problems from section 4.5 and were supplemented with additional codes through findings while coding the transcriptions.
6. Results
In the coming sections a summary is presented of the three cases that have been studied. The case study database can be found in appendix D. The cases presented in the database provide a more detailed description on the findings in the cases including citations of the interviewees. If no data was collected on a certain problem, it was either not mentioned during the interview or the interviewee had no knowledge on the particular problem.
6.1 Case A
Organisational features
The organisation is a financial institution. Less than one year ago they have implemented the scrum methodology. Knowledge on scrum in leading positions such as team leader, product owner1, and scrum
master2 is estimated to be moderate to high. Knowledge on scrum of team members is estimated to vary
widely, from entry level to high. Both interviewees recognise that the organisation is currently in a transition from waterfall to scrum.
Structures
The decision rights or input rights over IT decisions is perceived as federal (Proposition 1). The IT strategy is determined on CxO level and is known throughout the organisation. There are no known IT-steering or strategy committees (Proposition 1). Clarity on roles and responsibilities regarding IT decisions exist within the scrum teams (Proposition 1). Both I1 and I2 reported problems regarding the management style used to support the scrum methodology (S1.1). I2 states that managers do this because they fear to lose control over a team (S1.2). Projects to which the scrum teams are assigned are funded by the business, therefore the IT department does not decide which projects to develop. The projects are controlled by project managers which are known to influence the product owners. This makes the
1 A product owner is the owner of the product that is being developed by the scrum teams.
17 autonomy of the team limited (S2.1). Evidence is found that business analysts became product owners at the case although this does not happen frequently (S3.1).
Processes
There are no control frameworks known at the case (Proposition 1). Progress, performance, and control is measured by making use of the tools the scrum methodology provides (P1). There is no mention of maturity models, scorecards, KPI’s, SLA’s, or other traditional methods to keep track of performance and progress (Proposition 1). No data was collected on risk management (P2). For resource management, both I1 and I2 acknowledge that members of agile teams work at multiple projects at the same time (P3.1). I2 recognises the uncertainty the business has over agile projects (P3.2) although it was not mentioned that this actually leads to problems with funding. Working in iterations does not lead to any problems and no processes are placed outside that belong inside the iteration (P4.1; P4.2). I1 mentions that dependencies with other teams or departments are possible problems for the agile development process (P5.2). No data was collected on P5.1 and P5.3.
Relational mechanisms
On organisational culture, I1 states that the business is used to a certain way of working and fears change (RM1.1). I1 also mentions that the business does know that agile development is the way of the future. Trainings are given to help with this issue. There is no project culture (RM1.2). To establish alignment between business and IT a project board is formed that has members of the business and the managing position(s) of the scrum teams (Proposition 1). There was no data on RM2.1. At case A, they try to employ team members that are more T-shaped3. I1 recognises that this could lead to increased pressure on
employees although this is not currently a problem (RM3.2). There was no data on RM3.1. I2 states that optimal communication and collaboration is tried to be achieved through using the daily stand-up4 and
the sprint review5 and retrospective6 of the scrum methodology (Proposition 1). According to I2, there is
much value and trust between team members and relates this to good communication and collaboration (RM4.2). There is a lack of documentation although this is not a serious problem (RM4.3). There was no data on RM4.1. There was no data on individuals (RM5). The stakeholders are actively involved in the development process (RM6.1). Developers with little business knowledge causing stakeholders to lose trust in the development process was not recognised by both interviewees (RM6.2). The HR policy of registering hours creates overhead (RM7.1). Team members are evaluated at both hard and soft skills (RM7.2). Team members are individually evaluated or rewarded, not as a team (RM7.3). There was no data on RM7.4.
6.2 Case B
Organisational features
The organisation is a financial institution. Around 5-6 years ago they have implemented the scrum methodology. Knowledge on scrum of team members is estimated to be moderate to high. Knowledge on scrum on leading positions such as team leads and scrum masters is estimated to be moderate to high. product owners are sometimes lacking behind on knowledge. Both interviewees recognise that organisation is still in transition to a purer form of agile development.
Structures
The decision rights or input rights over IT decisions of case B is perceived as federal (Proposition 1). There is no strategy or steering commission (known) in the organisation (Proposition 1). Both interviewees
3 T-shaped means that professionals have deep knowledge on at least one discipline and have an understanding of
other boundary crossing competences.
4 The daily standup is held every morning where team members discuss the challenges of the previous and coming
day.
5 Meeting at the end of an iteration where it is discussed what has been built.
18 describe the clarity on roles and responsibilities regarding IT decisions in the agile process as very clear (Proposition 1).
In case B they have developed a governance structure based on the scrum methodology. They have introduced a program backlog. This is a backlog7 on management level that encompasses all items that
should be developed by the department. The items on the program backlog are dispersed among the team backlogs one level below. The program backlog they introduced receives its items from the business almost at the level of the board of directors, where another backlog exists. Each level down the items on the backlogs are refined and broken down into smaller items. Effort is made to eliminate as much layers of management as possible to make every item on the backlog relatable to the backlog the level above. They have been continuously evolving and adapting this method over the past 5 years (Proposition 1).
Both I3 and I4 recognise problems regarding the management style used at the organisation to support the scrum methodology (S1.1). Both I3 and I4 state that they are currently in the transition to reducing influence of project managers to make scrum teams more autonomously. This changing role leads to managers having problems with losing decision authority which in turn leads to other problems (S1.2). This is perceived as one of the cases biggest problems. The teams are autonomous in how they execute their work. The what is determined by the product backlog that is set by management (S2.1). More team autonomy is the current challenge in the case. Business analysts becoming product owners has happened but never created any real problems (S3.1).
Processes
There a no known control frameworks influencing the teams (Proposition 1). Ways to keep track of progress, performance, and control are all taken from the scrum methodology. There is no mention of maturity models, scorecards, KPI’s, SLA’s, or other traditional methods (Proposition 1; P1.1). Effort is taken by managers to not use this information to steer but to facilitate. Risks are still mitigated by writing (some) documentation due to regulatory requirements (P2.1). People within scrum teams are still sometimes working on different projects although effort is taken to rule this out (P3.1). There are no project budgets but a set budget for a set amount of scrum teams, therefore P3.2 is not reported as a problem. The business is used to iterations (P4.1), this has taken some time in the past. No processes are placed outside the iteration (P4.2). According to I3 and I4, it takes months to get a new scrum team up and running and this is perceived as inconvenient (P5.1). One of the other major perceived problems at the case are dependencies between departments when these departments each have their own working method (P5.2). According to I4, there are still some projects where some teams are delivering through waterfall and some are delivering through scrum. This requires more coordination (P5.3).
Relational Mechanisms
At case B, the culture regarding agile development was introduced bottom-up and evolved over time. Some resistance to the agile mind-set by older employees is reported (RM1.1). Trainings are given on the scrum methodology and there is no project culture (RM1.2). The governance structure introduced in the subsection structures explains the business and IT alignment (Proposition 1). The business is capable to decide on priorities (RM2.1). At the case, they try to select employees that are T-shaped and their aim is to make teams as T-shaped as possible. It depends on the person whether this is experienced as a burden (RM3.2). There were no problems regarding high specialisations of employees that lead to overhead (RM3.1). No poor communication was recognised between the development team and the product owner at the case (RM4.1). Value and trust that led to good communication and collaboration within the teams was recognised (RM4.2). There was no data on RM4.3. There are no problems regarding continuous training (RM5.1). Team members sometimes have problems prioritising work because of their autonomy (RM5.2). Although, this is not a huge problem because the product owner decides on prioritisation. The product owner is the stakeholder manager in the scrum methodology (Proposition 1). There are many incentives to include stakeholders (RM6.1). Developers do not usually come in contact with stakeholders, this is done by the product owner (RM6.2). HR managers can influence the agile process by setting individual goals that could conflict with the interests of the scrum team (RM7.1).
