1 Introduction

Large projects are difficult to handle and often fail to meet stakeholders’ expectations (Janssen et al. 2015). While agile methods have engendered significant interest in industry, there is little investigative research regarding their architecture and their mode of adoption within a large scale environment involving outsourcing, multiple programs, projects and methodologies - currently seen as a major challenge in the industrial context (Rodríguez et al. 2012; Lee and Young 2013; Asan, and Bilgen 2013). It is widely agreed that there can be no single methodology that can be universally applied to all projects; thus all agile and non-agile methodologies need to be tailored and integrated to support multiple projects (Mahanti 2006). This draws attention to the fact that a software development capability may combine agile and traditional elements to create a hybrid software development method in order to tackle these challenges for using agile approaches within large projects (Boehm and Turner 2003; Gill 2014). Hence, the adoption of agility at a large scale may require the integration of agile and non-agile elements for architecting context-aware hybrid adaptive methodologies (Sommer et al. 2014). We argue here that this can be best undertaken with the assistance of a context-aware hybrid adaptive methodology reference architecture (abbreviated here as ‘HAMRA’) model.

Architecture is defined as the “fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution” (ISO/IEC 42010 2011). Here, we apply systems thinking (Miller 1995) and use an architecture-driven approach to a software or information systems development (ISD) methodology – methodology as a living system. A reference architecture is a blueprint or template for developing a concrete architecture (Harrison 2011). In this context, a methodology reference architecture is a template that describes the methodological system elements (components), concepts or properties (classes) and their relationships to each other and the environment at an abstract or high level, allowing for drilling down for each of these elements as needed for the creation of a context specific project methodology. Thus, the challenge is:

“Which elements or components (agile or non-agile) are relevant for developing a context-aware hybrid adaptive methodology reference architecture?”

This research addresses this important question and identifies the context-aware hybrid adaptive methodology elements for developing the proposed HAMRA by using the qualitative constructive empirical research approach (Jarvinen 2001). The proposed HAMRA is intended to allow project teams to architect the context-specific configurations of hybrid adaptive methodologies by using the well-known situational method engineering (SME) and tailoring techniques (e.g. Kumar and Welke 1992; Brinkkemper et al. 1998; Henderson-Sellers and Ralyté 2010; Henderson-Sellers et al., 2014). Finally, HAMRA can also act as a first step towards the further investigation and development of a standard metamodel for context-aware hybrid adaptive methodologies (a research gap in agile development) – providing an opportunity to extend an ISO standard such as ISO/IEC 24744 (ISO/IEC, 2014) to explicitly support agility for large scale development.

This paper is organized as follows: Section 2 defines the research background and problem. Section 3 presents the research methodology. Section 4 presents the HAMRA based on the literature and on the results from two industry empirical studies. Section 5 describes how the improved and final version of the HAMRA has been applied in architecting the configuration of a context-specific hybrid adaptive methodology in two teaching cases. In Section 6 we discuss the overall research contribution and limitations before concluding in Section 7.

2 Research background and problem

Plan-driven or non-agile software development approaches (Boehm 1988) can be described as predictive, process-focused, document-driven and plan-driven whereas an agile approach (Agile Manifesto 2001; Fowler 2003) is seen as primarily adaptive and people-oriented. It has been suggested (Qumer and Henderson-Sellers 2008a) that traditional plan-driven software development practices (e.g. waterfall, spiral) may be more applicable in large projects, whereas agile practices are (claimed to be) applicable in small to medium size projects. Both agile and traditional plan-driven approaches have their own individual business values and benefits. However, agile methods and their practices offer many potential tangible benefits to an organization over traditional plan-driven approaches, e.g. improved time-to-market, productivity and quality software while reducing development cost and documentation (Reifer 2002). While many organizations are interested in adopting these agile methods or practices suitable to their local circumstances, there are still concerns regarding the adoption of agile in large-scale distributed project development environments (Vijayasarathy and Turk 2008; Laanti 2013).

Agile adoption does not simply depend on available universal agile methods. The core of agility in ISD is focused on the “cognition” or “mindset” of the people (Agile Manifesto 2001; Chance 2011) who are actually involved in the project. The success of agile adoption requires a gradual shift from a traditional to an agile mindset. Indeed, some organizations may find it more beneficial to initially move from a traditional non-agile approach to a hybrid approach and then from a hybrid to a fully agile mindset through the increasing adoption of all the agile principles. The agile mindset emerges through the ongoing tailoring and adoption of a context-specific agile methodology architecture underpinning agile values, principles and practices.

As noted above, the ongoing tailoring and adoption of an agile method may or may not be straightforward (Laanti 2008). However, “a gradual transition from a heavyweight or plan-driven (e.g. waterfall) to an agile process can make the change easier on the development team” (Cohn and Ford 2003). It is also possible to have an agile or hybrid software development method (Maharmeh and Unhelkar 2008) that can be built and/or tailored by mixing agile and traditional (non-agile) elements. It has been suggested (Gains and Hawkins 2007) that “Moving a traditional waterfall organisation into the world of agile methods is one thing, but when that organisation has many customers that operate with plan based on milestones and fixed delivery dates, some hybrid method is called for”. The development of the architecture of an agile or hybrid method is not a one-time up-front activity; rather, it is an ongoing activity that involves actual onshore and offshore (i.e. distributed) project team members. These team members continuously tailor and evolve their hybrid methodology architectures through the gradual adoption of situation-specific agile values, principles, practices and tools suitable to their context. The ongoing tailoring and evolution of context-specific hybrid adaptive method (see Fig. 1) architectures is a key motivation for our research.

Fig. 1
figure 1

Emergence of hybrid approach

Full size image

Here, it may be suggested that agile and non-agile elements are two extremes and have their own individual advantages over each other (Qumer and Henderson-Sellers 2008a). Rather, it may be appropriate to architect a hybrid adaptive methodology (e.g. a combined set of agile and non-agile elements) for a specific situation. The architecture of the hybrid methodology for a large-scale development can be engendered by using the proposed context-aware HAMRA reference architecture and the situational method engineering approach (Henderson-Sellers et al. 2014). The research presented in this paper is aimed at developing and evaluating the context-aware HAMRA reference architecture for architecting hybrid adaptive methodologies.

3 Research method

This research has been conducted by the application of an iterative qualitative constructive empirical research approach (adapted from Kasanen et al. 1993; Jarvinen 200; Hevner et al. 2004; Peffers et al. 2006), which is appropriate to the development and evaluation of the proposed HAMRA. This research approach is a way of linking research and practice (March and Smith 1995; Peffers et al. 2006). It is an iterative constructive research process (Jarvinen 2001; Osterle et al. 2010) that permits the development and evaluation of novel artefacts in short iterations. Here, we describe the six research process steps that have been used in our research spanning well over seven years (2006–2013) for the iterative development and evaluation of the HAMRA.

  • Step 1 (Iteration 0: Initiation) - Firstly, based on the initial literature review, we identified the research problem, objective and motivation for the development of the HAMRA (as discussed in Section 2).

  • Step 2 (Iteration 0: Initiation) - Secondly, we identified the qualitative constructive empirical research approach most appropriate for developing and evaluating the proposed HAMRA (this section).

  • Step 3 (Iteration 1: Development) - Thirdly, based on the review of the literature and related work (see Section 4), the initial elements for the HAMRA have been identified.

  • Step 4 (Iteration 1: Evaluation) - Fourthly, the initial HAMRA elements have been empirically analysed by the means of two empirical case studies (case ‘A’ and case ‘B′) in industry (see Section 4). The initial results of two empirical case studies have been described in (Qumer and Hnderson-Sellers 2008b). These empirical studies are extremely important to get the practical guidance and inputs from the industry to further develop and refine the proposed HAMRA elements. These cases have been very useful to validate the theory and theorize the practice in terms of HAMRA elements.

  • Step 5 (Iteration 2: Development) - These empirical study results have been further analysed in order to identify the hybrid adaptive methodology element classes, relationships and additional element(s), if any, based on the empirical evidence. Based on theory (step 4) and the empirical study analysis (step 4), the HAMRA has been refined, updated and reported in this paper (see Section 4). The proposed HARMA is a unique blend of both theory and practice. It has both academic rigour and practical industry applicability and relevance. It provides concrete elements and underlying detail to support the large-scale hybrid agile development, which is perceived as challenging.

  • Step 6 (Iteration 2: Evaluation) - The application of the refined and final version of the HAMRA is further demonstrated with the help of two teaching case studies (‘C′ and ‘D’) in academic settings (see Section 5). This concludes our research project.

The theory-based initial construct of the HAMRA includes both core and extended hybrid adaptive methodology elements. The empirical study was done by conducting hybrid and agile method tailoring workshops in industry (see Appendices A and B) by using the theory-based HAMRA elements in two different case organizations ‘A’ and ‘B′ (coded names). Empirical study is an inquiry that “investigates a contemporary phenomenon within its real-life context, especially when the boundaries between phenomena and context are not clearly evident” (Yin 2003; Ojala 2003). It can be used to develop, test or describe a theory or phenomenon. The practical applicability of the initial HAMRA elements have been tested by means of two empirical study case studies in industry. The initial results of these two empirical study cases have been published in detail in (Qumer and Hnderson-Sellers 2008b).

This paper builds on these empirical studies, and further analyses the empirical evidence and lessons learned from both industry cases in order to further understand and identify each of the methodology element classes (concepts or properties) and their relationships by using qualitative grounded theory analysis techniques (Glaser 1998), which were found to be very helpful for systematically inspecting the empirical evidence and further identifying the elemental classes and their relationships. The theory-based hybrid methodology elements, empirical study-based relevant element classes and their relationships form the final version of the theory and practice-based HAMRA. The final version of the HAMRA elements, classes and their relationships has been further evaluated by means of two teaching cases (‘C′ and ‘D’) in academic settings at the University of Technology, Sydney (UTS).

In the first empirical industry case study, a hybrid methodology had been designed in a large organization ‘A’ (code name) by using the HAMRA elements (see Appendix A – Hybrid Agile Product Enhancement Process). Organization ‘A’ provides largely object-oriented paradigm-based product development, support and maintenance services to their customers while following a traditional software development approach. They decided that they had to seek a product enhancement process that would enable them to quickly identify and develop new product features to keep them competitive in the market. Their interest was piqued by the attributes of agile methods. However, organization ‘A’ was not ready to commit fully to the use of an agile software development method on a large scale, because they realized that a sudden change in the organizational culture and mind-set might be risky and problematical. Therefore, they decided to tailor and adopt a partially agile approach, only utilizing new features of the agility ‘toolbox’ in the identification process area, together with a partially traditional approach (for the detailed implementation process area) in order to keep things under control whilst retaining flexibility.

In the second industry case study, ‘B′, a full-scale service-oriented agile methodology (different from organization ‘A’) had been designed for a medium-size project-based organization by using selected HAMRA elements (see Appendix B –Agile Service Oriented Process). Their focus was on e-health application development using a service-oriented abstraction paradigm. The description of these case studies was reported in Qumer and Hnderson-Sellers (2008b).

In the third teaching case study ‘C′, undertaken at UTS, a hybrid adaptive business analysis methodology was designed and used for teaching the project-based business requirements modelling (BRM) subject at UTS. UTS offers this project-driven undergraduate (approx. 100+ students in autumn semester, and 250+ students in spring semester) subject over a period of 14 weeks through face-to-face lectures (1 h) and tutorial sessions (2 h). The lectures introduce students to the business analysis methodology. Students play the role of a business analyst and apply the business analysis methodology to a project case study, working in teams of 2–3. A hybrid adaptive business analysis methodology was designed by the first author by using the HAMRA elements. Students applied the hybrid adaptive business analysis methodology to their projects in small teams of 2–3 students during 2013–14 (four semesters). Teaching case study ‘C′ is discussed in Section 5.

In the fourth teaching case study ‘D’, also at UTS, a hybrid adaptive project development methodology was designed by the first author and used for teaching the project-based software engineering practice (SEP) subject at UTS. UTS offers this project-driven undergraduate (approx. 200+ students in spring semester) subject over a period of 14 weeks through face-to-face lectures (1.5 h) and tutorial sessions (1.5 h). The lectures introduce students to agile and non-agile development methodologies. Students play different roles (e.g. business analyst, developer, and tester) and apply the hybrid adaptive project development methodology to projects in a team of 5–7 students. Students applied the hybrid adaptive project development methodology (mixing agile and non-agile elements) to their projects in small teams during 2013–14 (two semesters). Teaching case study ‘D’ is discussed in Section 5.

So far, we have discussed steps 1 and 2 of our research in sections 2 and 3, respectively. The next section discusses step 4 of our research, which describes the proposed “HAMRA” based on theory (literature) and practice (empirical work).

4 The HAMRA

As a result of our theoretical literature analysis and our two industry empirical cases in industry, we developed the final and improved version of the HAMRA (Figs. 2, 3, and 4). The initial elements for the proposed HAMRA were identified based on a review of the traditional ISO/IEC 24744 SEMDM (Software Engineering Metamodel for Development Methodologies) standard metamodel, agility and related concepts (Table 1).

Fig. 2
figure 2

Element viewpoint

Full size image
Fig. 3
figure 3

Classification viewpoint

Full size image
Fig. 4
figure 4

Multidimensional viewpoint

Full size image
Table 1 The HAMRA elements and classes – theoretial and empirical analysis results
Full size table

The literature review helped us to identify a set of 11 hybrid adaptive methodology elements. The 12th element methodology “Facility” was identified during the analysis of our two industry empirical cases. All 12 elements form the final version of the HAMRA. The HAMRA construct can be viewed from three viewpoints: an element viewpoint (Fig. 2), a classification viewpoint (Fig. 3) and a multidimensional viewpoint (Fig. 4). A viewpoint is a template that can be used to create context-specific views (Harrison 2011). The HAMRA element viewpoint (Fig. 2) is a template that provides the building blocks or elements of a hybrid adaptive methodology, which is a common practice in representing reference architectures (Harrison 2011). The HAMRA elements are classified into core and extended elements. The classification of the HAMRA elements is shown in the HAMRA classification viewpoint (Fig. 3). A hybrid adaptive methodology can be configured thorough the integration of HAMRA elements for a specific context. Thus, the relationships between the HAMRA elements are shown using the HAMRA multidimensional viewpoint (Fig. 4). Each element is represented as a dimension in the multidimensional viewpoint, which can be used to configure a hybrid adaptive methodology (fact).

Agility is about making complex things simple or, at least, simpler. Unlike a traditional complex relational metamodelling approach, here we used a simple and adaptable multidimensional modelling approach from the data warehousing literature (Kimball and Ross 2002) to show the relationships between different dimensions for a hybrid methodology (fact). This allowed the adaptability or flexibility to delete, modify or add new classes in each element dimension of a methodology as required and capture links between all dimensions in the hybrid adaptive methodology, which is called here a fact element. We can create many facts or hybrid methodologies through the integration of different methodology dimensions. The multidimensional view harnesses the autonomy of individual elements or components allowing for drilling down for each of these element classes (e.g. classes and hierarchies) as needed for a specific project or context. The multidimensional approach can be further used to develop a repository or warehouse of hybrid adaptive methodologies, which can be further used to support methodology-related analytics.

Here, we described the final updated version of the HAMRA in terms of these three viewpoints. Organizations may create additional viewpoints suitable to their local context. The key sources and empirical analysis of the HAMRA elements are summarized in Table 1.The last column of Table 1 presents the consolidated and final version of the HAMRA elements.

4.1 The HAMRA - Core

The tailoring of hybrid methods for a specific context can be assisted by using a situational method engineering approach and a standard metamodel. For example, the Software Engineering - Metamodel for Development Methodologies (SEMDM) metamodel (ISO/IEC 2007) can be used to describe and specify methodology elements and their relationships (Ralyté 1999; Henderson-Sellers 2003). The SEMDM (ISO/IEC 2007) is a comprehensive and established standard that combines different traditional non-agile metamodels and software development methodologies. The review of ISO/IEC 24744 SEMDM resulted in the identification of four core well-established methodology elements: people, process, work product and tool (see Table 1). People use tools and perform processes to produce work products (Fig. 3). These elements are classified as core well-known elements. We discuss these four elements in detail based in both the literature and empirical study analyses in this section.

4.1.1 People

The adaptive hybrid methodology (Fig. 4) includes the people element (ISO/IEC 2007), which is one of the important constituents of people-focused (Agile Manifesto 2001) agile software development methodologies and approaches. People use agile or non-agile processes and tools for producing agile or non-agile work products. They may also have an agile competency (e.G. agile skills, education and experience) and capacity (e.g. availability and workload bandwidth). Conboy and Fitzgerald (2010) discuss the people or developers’ characteristics such as “familiarity with a range of methods and methods” in the context of disciplined, purposeful and context-specific agile method tailoring and adoption.

The people element was used in defining the hybrid and agile methodologies for empirical case study organizations ‘A’ (see Appendix A) and ‘B′ (see Appendix B). For case study ‘A’, in the context of the people element, the agile team choreography model (describing a self-organizing, empowered and co-located team) had also been outlined in order to direct the behaviour of the agile team. The empirical study analysis highlighted that the case study organizations have different teams containing individuals who, regarding them as actors (e.g. producer, consumer), can be said to have competency and capacity to perform different roles (e.g. senior developer, product manager). Hence, the empirical study analysis helped us to identify seven sub-elements or classes and their relationships within the people element: individual, team, organization, actor, role, competency, capacity. These people element classes have been included in the updated final version of the HAMRA (Table 1).

4.1.2 Process

The adaptive hybrid methodology (Fig. 4) has a process element (as represented in the metamodel of ISO/IEC 2007) – indeed, any methodology has one or many integrated processes. The empirical study analysis of the tailored processes for the case study organizations helped us to elicit six process element classes and their relationships: event, stage (or phase), activity, task, gateway (decision point) and technique (agile and non-agile practices). Therefore, these six classes have been included in the updated HAMRA under the process element (Table 1). For instance, in case ‘A’, the phases (e.g. post-mortem) and events (e.g. end of iteration) are mentioned such as “the post-mortem phase is executed after the end of each iteration, phase and process for the purpose of future learning and decision making”. Similarly, both cases highlighted activities, tasks, decision points or gateways and techniques within the overall context of the process element. It has been found that the technique concept can cover concepts in both agile and non-agile practices. The analysis of the empirical study indicates that a process can be triggered by an event (e.g. request for new feature or service requirement) and may have one or many gateways (key process activity flow control and decision points), activities, tasks and techniques (practices), which can be organized into different stages (phases). Organizations may include additional process element classes, if required.

Process elements can be associated to other HAMRA elements; for example, process and agility elements together can describe an agile process. A process may be required in order for it to be compliant with rules, policy, legal and more abstract elements such as object-oriented or service-oriented processes. Similarly, other context-specific relationship types and relationships can be derived from the process element perspective.

4.1.3 Work product

The adaptive hybrid methodology (Fig. 4) produces work products (ISO/IEC 2007). The case study ‘A’ highlighted the backlog (e.g. feature backlog), document (e.g. requirements specification document), model (e.g. architecture), component (e.g. product component) and software application (e.g. software product) classes of the work product element. In addition to these five classes, case study ‘B′ also highlighted the matrix (e.g. business and service mapping matrix), service (e.g. e-health consultancy services), function (e.g. business operation of a service) and interface (e.g. service interface) classes of the work product element. These nine classes have all been included in the final version of the HAMRA under the work product element (Table 1).

The work product element can be associated to other HAMRA elements such as work product and agility elements that can describe the agile work product. The work product could be executable or non-executable (e.g. test cases, product backlog, iteration and executable artifacts) that can be used or produced to add business value to a project or a product development environment. Work products may be based on various abstraction mechanisms (e.g. object-oriented and service-oriented) and are compliant to rules, policy and legal requirements. Similarly, other context-specific relationship types and relationships can be derived from the work product element perspective.

4.1.4 Technology

The original tool element given in ISO/IEC (2007) has been renamed to technology element in HAMRA subsequent to the empirical analysis. This is because it is more than a tool or set of tools. It is about complex technology platforms and infrastructure that may be required to support real world, large-scale software development work. The empirical analysis highlighted the platform (e.g. J2EE development platform) and infrastructure (e.g. Web logic application server) classes of the technology element. These two classes have been included in the final version of HAMRA under the technology element (Table 1). The technology element can describe agile and non-agile technology (e.g. automated testing, continuous integration, deployment, communication) that can be used to add value by supporting agile and non-agile project development environments. Technology may be based on various abstraction mechanisms and is compliant to rules, policy and legal requirements. Similarly, other context-specific relationship types and relationships can be derived from technology element perspective. Organization may include additional technology element classes, if required.

4.1.5 Summary

In summary, four ISO/IEC 24744 (2007) SEMDM elements have been identified, empirically analysed and then included in the HAMRA. However, the ISO/IEC 24744 (2007) SEMDM does not explicitly specify the other related elements that were uncovered during this research for developing the HAMRA (as discussed in the following section) - called here ‘extended’ methodology elements: agility, abstraction, business value, business policy, rules, legal, context and facility. These extended elements extend ISO/IEC 24744 SEMDM and cover contemporary thinking and recent developments in software and ISD methodologies. Of course, care has been taken in identifying new candidate elements and classes (extending the ISO/IEC 24744 SEMDM) with regard to whether these new elements or classes under scrutiny are worthy of representation as a new concept (i.e. an element or class in the reference architecture) or whether it is the slot value of an attribute (possibly needing to be added) of an existing element in the ISO/IEC 24744 SEMDM. However, these emerging methodology elements and classes seem to bring interesting insights and further research oppurtunites for the possible extension of ISO/IEC 24744 SEMDM.

4.2 The HAMRA - agile (extended)

4.2.1 Agility

The adaptive hybrid methodology (Fig. 4) incorporates an agility element. The concept of agility is not new, although its quantitative scientific definition is less well determined. It has been found that existing software development methodology standards (e.g. ISO/IEC 2007, 2014) do not explicitly discuss the element of agility. The need for an agility element has been identified based on the review of basic agility attributes (e.g. Randell and Zurcher 1968; Wong and Whitman 1999; Boehm and Turner 2004; Conboy and Fitzgerald 2004; Henderson-Sellers and Serour 2005; Conboy 2009), agile values and principles (Agile Manifesto 2001), and agile practices of six well-known agile method practices such Extreme Programming (Beck and Andres 2004), Feature Driven Development (Palmer and Felsing 2002), Adaptive Software Development (Highsmith 2000), Dynamic Software Development Method (Stapleton 1997), Scrum (Schwaber 2007) and Crystal (Cockburn 2006). The Agile Manifesto (2001) specifies the concepts of agility in terms of abstract agile values and principles that are concretized in the agile practices and techniques of these agile methods.

Our empirical analysis has highlighted agile value, agile principle and agile level of the agility element (Table 1). These classes collectively define our agile adoption and improvement model (AAIM) (Qumer 2010). For instance, in case ‘A’, the communication-cooperation protocol had been developed to specify and enable an effective face-to-face communication among the empowered, self-organizing and cross-functional agile team (senior developers of the company) and their clients. The purpose of this protocol was to reduce the documentation and waste while focusing on the development of the new features, rather than the documentation. This practice clearly highlighted the value of the empirical evidence regarding the usability of the three agile values of “reduced documentation”, “individuals and interactions” and “keeping the process cost effective.

Agile values and principles can be organised into six agile levels (see Appendix C). The degree of agility of an adaptive methodology ranges from basic level 0 to advanced level 6. An experimental environment or scenario can be initiated at agile level 0 in which a team may try out some of the individual agile practices and tools prior to beginning with the systematic adoption of specific agile levels and relevant practices (from 1 to 6). For instance, in case ‘B′, “instead of a full scale agile process, we envisaged an experimental scenario and constructed only three agile process fragments: enhanced pair programming (EPP), pair review (PR) and on-site developer (OSD) for a service-oriented e-health project to familiarise the case study organization with an agile approach” (Qumer and Henderson-Sellers 2008b). Each agile level (from 1 to 6) specifies the agile values and principles to be followed in order to achieve the particular level: infancy, initial, realization value, smart and progress. An organization may assess their current agile level and architect a hybrid adaptive methodology for a desired transition(s) and final target agile level (some sort of an agile adoption and improvement roadmap). For instance, in case ‘B′, an agile service oriented process (ASOP) was engineered (by focusing on AAIM level 1 agile practices) to iteratively carry out a systematic test-driven development of the e-health software applications. The concept of an agile practice can be covered by the process element and its technique class; hence, there is no need to define the agile practice as a separate concept or class since these are already included in the HAMRA. [Please see Appendix C and Appendix D for the detailed analysis and mapping of agile values, principles, levels and practices.]

It has been noted in our two industry empirical study cases that agility can be associated with people (agile people: agile actor, role, team, competency), process (e.g. case ‘A’: hybrid agile product enhancement process), work product (e.G. agile work product: user story backlog, agile executable models) and technology elements (e.G. agile technology: agile development platform and infrastructure. Similarly, other context-specific relationship types and relationships can be derived from the agility element perspective. Organizations may also include additional agility element classes, if required, by virtue of method tailoring, as practised in Situational Method Engineering (Henderson-Sellers et al., 2014) – as noted earlier.

4.3 The HAMRA - related concepts (extended)

4.3.1 Abstraction

The adaptive hybrid methodology (Fig. 4) supports abstraction. Abstraction element has been identified based on the underlying paradigmatic mindsetFootnote 1 (object-oriented and service-oriented) embedded in software and ISD methodologies (e.g. Berzins et al.1986; Theodorakis et al. 1999; Odell 2002; Feuerlicht 2006). Abstraction, whilst the keystone of a modelling paradigm or mindset, is an important element of a software or ISD methodology (e.g. Berzins et al. 1986) and can be associated with other elements such as people, process, work product (e.g. object-oriented classes, services) and technology (e.g. object-oriented tools to develop classes).

Case study ‘A’ was mainly “focused” on an object-oriented hybrid agile approach whereas case study ‘B′ was focused on a service-oriented agile approach. Based on our analysis of the literature and our empirical evidence, the abstraction element and its two classes have been included in the final version of the HAMRA (Table 1). Organization may include additional abstraction classes, if required.

Furthermore, a software development project may in fact combine more than one abstraction mechanism for a specific situation; for example, one project may involve the use of object-oriented and service-oriented abstractions together. In order to develop such a project, we may need to have a tailored methodology to support both abstractions at the same time. Most of the agile software development methods are not uniquely tied to any specific abstraction mechanism (e.g. object-oriented and service-oriented) or, perhaps more accurately, agile methods are abstraction neutral. However, it is possible that agile and abstraction-based practices can be integrated in order to tailor a situationally-specific multi-abstraction agile or hybrid method (e.g. such as agile object-oriented, and agile service-oriented) for a multi-abstraction project development. Hence, it may be suggested that abstraction is an important element of the proposed reference architecture.

4.3.2 Business value

The business value element describes the financial and non-financial value that may influence method tailoring and adoption. Traditionally, business value is more concerned with the actual project business value. However, it is important to understand the business value of a methodology, which will be tailored and applied to deliver the project and associated business value. The business value element has been identified as relevant, based on the concepts of business benefits or business values that may be linked to both agile and non-agile or plan-driven methods such as rapid time to market, improved handling of large scale projects, reduced documentation, reduced defect density and improved quality (Royce 1970; Boehm and Turner 2003; Fitzgerald et al. 2006; Elssamadisy 2007; Smith and Sidky 2009). Racheva et al. (2009) suggested that “business value is a key concept in agile software development approaches” and “essentially, in agile software projects, the development process is a value creation process”. Business value can be associated with people (e.g. contribution relevant to people), process (e.g. business value contribution of process or practices), work product (e.g. business value contribution of a work product) and technology (e.g. business value contribution of a development platform) elements. The expected business value can be useful, for example, when architecting a methodology with a view to achieving specific business objectives and when comparing different agile and non-agile methodologies and their contributions to the overall business value. Indeed, the notion of business value is a way to link a methodology to an overarching business strategy. The integration of a business value element to other agile and non-agile elements is one way of mapping the business decisions to major software product and project milestones. It is important to understand the link between business and software development for software business-intensive organizations.

The business value and agile method adoption alignment is an issue that has not been investigated to any great extent by the agile community. Here, based on the analysis of data from our empirical study, we propose that it should be, because it has an impact on both the tailoring and adoption of agile methods in practice (such as the alignment of business and agile software development goals). Case study ‘A’ highlighted the time (e.g. product time to market) and scope (e.g. product features) classes of the business value element. In addition to these two classes, case study ‘B′ also highlighted the cost (e.g. decrease the development cost by about 20 % in comparison with the existing traditional approach), quality (e.g. improve the quality of the services) and training (e.g. train team member) classes of the work product element. These five business value classes have been included in the final version of the HAMRA under the business value element (Table 1).

4.3.3 Policy

The adaptive hybrid methodology (Fig. 4) needs to be compliant to relevant policy. Policy guides the specific behaviour of an organization, which may be expressed in terms of processes to achieve business values (Chapman 1997) or goals (Tyndale et al. 2002). In the context of an agile methodology, Cockburn (2003) suggests that “people construct rules and policies for their upcoming interactions, deciding on work habits, communication standards, project policies and conventions”. The policies are developed and adopted at a high level by top management in order to drive the business of software development or acquisition. Although top management is responsible for the overall success of the business in the market, agile or non-agile or hybrid practices or processes should be owned by the team actually doing the software development work. Nevertheless, it is often their organization’s policies that may have the largest impact on their choices of adoption of agile or non-agile practices.

Senior management and business policies may be one of the influencing elements of software process improvement in terms of agile process adoption and improvement. Policies may guide the organizationally-specific strategic goals and objectives related to software process improvement; the lack of business policy and software process alignment may be one of the resistance factors to the agile process adoption and improvement efforts (Nasir et al. 2008). Reis et al. (2002) suggested an approach to model software development-related policies that may support the reuse of policy instances across different software processes in a software organization. Software development-related policies constitute “the guiding principles for process development and/or enactment” (Feiler and Humphrey 1993). The changes in policy may also impact other associated elements of a methodology. It has been suggested (Vahaniitty and Rautiainen 2008) that “for a software company, it is essential to understand how to link business management and software development and employ a solid, business-oriented approach in its development decision-making”. Hence, it may be suggested that the policy element, together with the other software development elements, is an important element of a software methodology (Kenens et al. 1998) and, therefore, it has been included in the proposed reference architecture. The case study ‘A’ highlighted the product development policy and case study ‘B′ highlighted the project development policy classes of the policy element. These two classes have been included in the final version of the HAMRA under the policy element (Table 1).

4.3.4 Rule

The adaptive hybrid methodology (Fig. 4) needs to be compliant to relevant business rules. ‘Business rule’ is an important element and can be seen as generic statements about the organization’s way of doing business (Leite 1998). Knolmayer et al. (2000) suggested that “business rules are defined as statements about guidelines and restrictions with respect to states and processes in an organisation”. The rule element may influence method tailoring and adoption. It has been suggested that business rules often drive and govern the software development process in an adaptive and collaborative environment (Orriens et al. 2006). Cockburn (2005) suggested that “projects for systems that can cause more damage need added hardness in the methodology, more validation and verification rules”. Furthermore, Cockburn (2002) discussed the characteristic of “rule” in the context of agile methods as being elaborated into “rules of project behaviour and human-and communication-oriented rules”. Hence, it may be suggested that the rules may be the means to enforce policy and regulatory requirements in order to provide important checkpoints in the processes and practices of an organization. Here, it is included in the proposed reference architecture.

Brinkkemper (1996) describes a software development method as a systematic approach that encompasses directions, rules and a specific way of thinking in order to perform development activities, with the corresponding development of products. It has been suggested (Cockburn 2003) that “treating people’s individual personalities as significant input to the methodology produces the consequences that possible different team members should use different rules within certain bounded work area” and also “every one to three months, they meet for a few hours to a day to discuss the conventions and rules that are operating by and adjust them to better fit their needs”. Both case studies ‘A’ and ‘B′ highlighted the communication, cooperation and decision rule classes of the main rule element. For instance, in case study ‘A’, a communication-cooperation protocol was developed. These three rule classes have been included in the final version of the HAMRA under the rule element (Table 1).

4.3.5 Legal

The adaptive hybrid methodology (Fig. 4) also needs to comply with relevant legal requirements. The legal requirements (compliance and regulatory) may impact the software processes and practices of software business intensive organizations. Although top management is responsible for the business policy, strategy and legal compliance needs, it has been suggested that “organisations have policies in order to: satisfy the business objectives, satisfy customers, make good use of resources, and conform to laws or general business conventions” (Leonardi and Leite 2002). Beznosov and Kruchten (2004) highlighted the legal aspect of the software development process in the context of security-critical requirements. Here, we may argue that top management may be interested in verifying whether the adopted or to-be-adopted agile practices are in alignment with their business policy, legal and statutory requirements (e.g. especially agility adoption and improvement in the context of large government and military organizations, state departments, ministries). For instance, one of the agile values suggests having an open contract (e.g. “Customer collaboration over contract negotiation”) as opposed to having a fixed contract (e.g. plan-driven). This situation may restrict an organization to adopt this particular agile practice due to their legal compliance requirements of mandatorily having a fixed contract. In another example, the agile practices of “sit together” and “pair programming” may raise legal issues related to personal safety, performance and privacy (e.g. legal and regulatory compliance - industrial award or certified agreements). Also, on another note of agile practices, an “on-site customer” may be exposed to the information (e.g. personal, project, contract) of other customers, which may not be desirable from the perspective of local Freedom of Information (FOI) Acts (e.g. Commonwealth FOI ACT 1982) or commercial in confidence. In other words, it may be suggested that the business policy, rule and legal elements are tied to the adoption and tailoring of agile and non-agile methodology. Here, the legal element is included in the proposed reference architecture and empirically analysed. Both studied organizations need to be compliant to legal requirements for a mutually agreed contract for a specific product and service. Hence, the contract class has been identified and included in the HAMRA under the legal element. Organizations may also include additional legal element classes according to their context using method tailoring.

4.3.6 Context

The eleventh element of the HAMRA construct is an overarching context element that describes the overall environmental context, which is associated with all other methodology elements. It describes a context or environment in which a methodology is developed and applied. Context is a project environment or situation that can be characterized by the subject area or problem domain in a particular organization (Rolland and Prakash 1996). A project context can be described by using a set of factors called contingencies or situational factors (Harmsen et al. 1995). An organization or an extended organization includes both its internal and external environment, which incorporates not only its internal business units but also its partners, suppliers and customers (Harmsen 1997; Kornyshova et al. 2011; Qumer and Hnderson-Sellers 2009). It is important to identify and understand the contextual information of a given situation or project environment when tailoring a method (Bucher 2006). Tolfo and Wazlawick (2008) pointed out that “it is necessary to choose a software development method that suits the organizational culture”. The empirical study highlighted that “a step-by-step approach may be considered reasonable for a gradual, successful transition or adoption of agile ideas, rather than all at once, which may pose several risks and problems”. Our empirical study has suggested the inclusion of classes to represent nature (e.g. size, complexity, and process change risk aspects of the large and complex environment of case ‘A’ organization), industry (e.g. case ‘B′ consulting organization), domain (e.g. case ‘B′ e-Health), structure (e.g. formal organizational structure) and culture (formal process-driven exiting culture of case ‘A’ organization) within the context element; hence these have been included in the final version of the HAMRA (Table 1). Organizations may include additional context classes appropriate to their context.

4.3.7 Facility

The adaptive hybrid methodology (Fig. 4) has an associated facility element, which was identified during the empirical analysis. The initial construct of the HAMRA containing eleven elements provided sufficient methodology coverage. However, the empirical study analysis uncovered a new methodology “facility” element, which was not present in the initial HAMRA construct. Facility provides the physical or virtual and co-located or distributed spatial workspace to support other methodology elements. For instance, case study ‘A’ highlighted the need for co-located workspace for developers. Facility is an important element, because some of the agile practices such as face-to-face communication or daily stand up meetings may not be feasible if the team members are not co-located or in the same facility. Hence, the facility element and spatial class have been included in the final version of the HAMRA (Table 1).

Here, we learned thorough the theoretical and practical empirical study analysis that a hybrid adaptive methodology can be configured using the HAMRA elements. This highlights the theoretical and practical relevance of the HAMRA elements. Furthermore, it can be observed from case study ‘A’ that it is possible to have a hybrid adaptive methodology (see Appendix A) for a large organization instead of a full scale agile method such as is the case for case study ‘B′, which can be built or tailored by mixing agile and existing traditional (non-agile) elements. Based on the theoretical and practical empirical analysis, a set of twelve integrated hybrid adaptive methodology elements and their relevant classes have been identified, which then forms the proposed revised HAMRA. The HAMRA incorporates already well-established four core elements (process, people, work product, technology) and newly identified eight extended elements (agility, abstraction, business value, policy, rules, legal, context and facility). The HAMRA is a blueprint that describes the methodological elements and their relationships at an abstract or high level, allowing for drilling down for each of these identified element’s classes as needed for a specific context.

5 Application

This section demonstrates how the final version of the HAMRA multidimensional viewpoint (Table 1, Fig. 4) has been applied in configuring two hybrid adaptive methodologies for teaching and developing software projects in two teaching cases (cases ‘C′ and ‘D’) at UTS. In teaching case ‘C′ at UTS, a hybrid adaptive business analysis (BA) methodology was designed by using the HAMRA multidimensional viewpoint or template for teaching the large-scale project-based undergraduate business requirements modelling (BRM) subject and delivering associated project requirements (see Table 2). In teaching case ‘D’ at UTS, a hybrid adaptive project development (PD) methodology was designed by using the HAMRA multidimensional viewpoint for teaching project-based software engineering practice (SEP) subject (see Table 2). This was done to further evaluate the applicability of the final version of the HAMRA elements. This is also a way to link theory and industry based empirical research to teaching. This completes a full cycle of theory-empirical research-teaching. These methodologies are incorporated into the delivery of both subjects. [Please see Table 2, which shows the application of HAMRA elements and created methodologies in the academic project context.]

Table 2 The HAMRA teaching cases – multidimensional viewpoint
Full size table

5.1 Adaptive requirements methodology

The project-based BRM subject introduces students to agile and non-agile BA elements. The goal is to architect a hybrid adaptive BA methodology for the Job Advertisement and Application Submission (JASS) system analysis team project. In order to do so, we used the HAMRA multidimensional viewpoint (Fig. 4) to architect a hybrid adaptive BA methodology (see Table 2 – BRM Teaching Case) through the integration of traditional BA elements from Business Analysis Body Of Knowledge (BABOK) (IIBA 2009) and agile BA elements from the Scrum (Schwaber 2007) (published in the public domain). The project brief and the created hybrid adaptive BA methodology were explained to the students by the lecturer at the beginning of the semester. Students applied the adaptive BA methodology to their projects in small teams (2–3 students in a team) during the semester of 14 weeks. The adaptive BA methodology is organized into two stages and four activities (Fig. 5). The details of the adaptive BA methodology are mapped in Table 2.

Fig. 5
figure 5

Hybrid adaptive BA methodology architecture – stage and activity view

Full size image

5.2 Adaptive PD methodology

The project-based SEP subject introduces students to agile and non-agile PD elements. The goal is to architect a hybrid adaptive PD methodology for the Travel Funding Approval (TFA) system team project. In order to do so, we used the HAMRA multidimensional viewpoint (Fig. 4) to architect a hybrid adaptive PD methodology (see Table 2 – SEP Teaching Case) through the integration of traditional waterfall (Royce 1970) together with agile elements from Scrum (Schwaber 2007) and Extreme Programming (Beck and Andres 2004) methodologies (published in the public domain). The project brief and the created adaptive PD methodology were explained to the students (different from the first teaching case) by the lecturer at the beginning of the semester. Students applied the adaptive PD methodology to their projects in small teams (5–7 students in a team) during the semester of 14 weeks. The adaptive PD methodology is organized into three stages and six activities (Table 2, Fig. 6 with marked circle). The details of the adaptive PD methodology elements are mapped in Table 2.

Fig. 6
figure 6

Hybrid adaptive PD methodology architecture – stage and activity view

Full size image

The people element classes were used to describe the people dimension of both the hybrid adaptive BA and PD methodologies (Table 2). For instance, students played the role of business analyst (traditional role), whereas the teaching staff played the role of a product owner (agile role) in case ‘C′. Similarly, students played different agile and traditional roles in case ‘D’.

The process element classes describe the adaptive BA and PD methodologies (Table 2). For instance, the activity class of the process element describes two BA and six PD activities. It can be observed from Table 2 (see case ‘D’ Task) that, instead of traditional detailed up-front planning and analysis, the planning and analysis activity tasks are done iteratively at different levels – from the high-level project to just-in-time iteration-level planning and analysis (pre-iteration). Furthermore, it is important to note that the technique class describes both agile and non-agile techniques to support the tasks of hybrid adaptive BA and PD methodologies.

The work product element classes describe the traditional non-agile (e.g. requirements specifications document, uses cases) and agile work products (e.g. user story backlog). Furthermore, it also highlights the abstraction-specific object (cases ‘C′ and ‘D’) and service (case ‘D’) work products. Students as business analysts, in the adaptive BA methodology (case ‘C′), mainly focus on capturing requirements using high level user-story work products and clarifying those user stories during face-to-face conversations with the product owner (tutor or lecturer) during the tutorial sessions. It is important to note that in the hybrid work product context, students only detail complex user stories in terms of system use case model and narratives.

The technology element classes describe the platform and infrastructure that are required to support the adaptive BA and PD methodologies. For instance, in the adaptive BA methodology, agile (e.g. IBM Jazz Hub) and traditional non-agile (e.g. MS Office MS Visio) platforms and infrastructure have been included in order to support the production of agile (e.g. product backlog) and traditional non-agile (e.g. requirements specifications document) work products. It is important to note here that students were allowed to use any additional or different technology, other than that specified in the adaptive methodologies and provided by UTS labs.

The agility element classes refer to the agile values, principles and levels supported by the adaptive BA and PD methodologies. The adaptive BA methodology incorporates the agile levels 1–2 values, principles and relevant agile practices as techniques (see Appendix C). The adaptive BA methodology includes the basic levels of agility since it is a first year undergraduate subject. The adaptive PD methodology incorporates agile levels 1–3 values, principles and relevant practices. The adaptive PD methodology includes the mid-levels of agile (better than BA) since it is a second year undergraduate subject. The adaptive methodologies incorporating advanced agile levels, values, principles and relevant practices can be architected for advanced adaptive BA and PD subjects.

The abstraction element classes describe the abstraction dimension of the adaptive BA (object oriented) and PD (e.g. object and service oriented) methodologies. It is important to note here that although agile practices originated in the context of object-oriented development, agile is not in fact tied to any specific abstraction mechanisms (e.g. object or service). It seems to be abstraction neutral. However, it is important to understand the abstraction dimension from the abstraction-specific work product, technology and technique perspective.

The business value element classes are mapped to both adaptive BA and PD methodologies. Since it is an academic project, only the training business value is relevant and mapped in this context. Other business value element classes can be mapped to commercial project methodologies.

The adaptive BA and PD methodologies were tailored for the academic projects; therefore, only the project development policy class of the policy element was relevant. The project development policy states the UTS student workload policy for the subjects in the context, which is 9–12 h per student per week (including 3 h face-to-face teaching time per week). The tasks in the adaptive methodologies should be compliant to this policy. Similarly, rule class elements such as communication, cooperation and decision rules (e.g. UTS assessment rules) guide the BA and PD methodologies. For instance, in the hybrid adaptive BA, agile rules (e.g. rules of face-to-face human communication) and non-agile rules (e.g. requirements document driven communication) have been integrated. The legal contract element class refers to the subject outlines, which is a legal contract between students and UTS. This contract guides the assessment tasks in the adaptive BA and PD methodologies. Similarly, the context element classes describe the academic context for the adaptive BA and PD methodologies. Finally, the facility element class ‘spatial’ refers to the UTS lab, student home and internet facilities supporting the execution of adaptive BA and PD methodologies.

This section has presented the application of the final version of HAMRA. It is clear from the analysis of HAMRA that the HAMRA is not another agile or non-agile methodology. HAMRA is a reference architecture or guide; a hybrid adaptive methodology can then be established or represented by using the HAMRA elements and classes for a particular situation. The HAMRA construct (e.g. a vocabulary and conceptualization of agile and non-agile environment) has laid down a foundation for possible future investigation (and future research) of a standard metamodel for hybrid adaptive methodologies.

6 Discusion

HAMRA should perhaps be considered as a living organism (living systems theory of Miller 1995), which is continually evolving and adapting. Living systems are created, used, maintained, transformed and retired or expired. Living system organisms are composed of nested parts or cells. According to the living systems metaphor, each living system at the higher level is made of other low-level parts or cells. In the HAMRA, an adaptive methodology is a living system, where each element is thus perceived as a “Cell”. These cells can be combined to architect an agile or hybrid adaptive methodology. The advantage of using the “Cell” metaphor of the living system theory is that it presents the holistic and dynamic nature of the HAMRA and the subsequently created methodologies. It indicates that these should both be architected and managed as a whole of interdependent and connected elements or cells instead of a collection of separately architected and managed elements (see multidimensional viewpoint – Fig. 4). It thus takes into consideration the inter-dependency and interactions of methodology cells because changes in one part or cell of a methodology can impact other parts or cells of that methodology. This is critical because changes made in one part while ignoring the whole may channel the methodology energy in the wrong direction and could be a recipe for future methodology malfunction or failure. The HAMRA is flexible and can be extended, localized and modified by the development team(s), using situational method engineering. The elements or dimensions or cells embedded in the HAMRA can be integrated to generate various situationally-specific configurations of hybrid adaptive methodologies for project development. The concreteness and contribution of the proposed HAMRA are discussed from both practice and research perspectives within the overall context of its scope and limitations.

6.1 Practice

The HAMRA construct has been incrementally developed over a period of time (see Section 3). Firstly, the initial version of the HAMRA was developed based on the literature review (as discussed earlier). This initial HAMRA construct was applied to two industrial empirical cases: A and B (see Table 1) to get early feedback and directions for further development. We conducted process workshops in industry and created hybrid agile product-enhancement process (APEP) and agile service oriented process (ASOP) by using the initial HAMRA construct for industrial cases A and B for two different organisations (see Appendix A and B for workshop photos). It was done to determine the industrial applicability and soundness of the HAMRA elements to ensure that the construct in hand represents the domain of interest and is fit for the purpose of software process or method creation. The results of these cases highlighted that a step-by-step method tailoring approach along with a structured framework, such as HAMRA, is appropriate for a gradual and successful adoption of hybrid and agile practices for large and complex projects. The results of these empirical cases were described in (Qumer and Hnderson-Sellers 2008b), which laid a foundation for further development of the HAMRA in its current form. Secondly, these empirical study results were analysed and integrated with the detailed theoretical analysis work (see Table 1) to further identify the hybrid methodology element classes, relationships and also additional elements (see Figs. 3 and 4) for the final and refined version of the HAMRA construct. Finally, the practical applicability and concreteness of the refined version of the HAMRA was further tested by successfully using it in creating two hybrid adaptive methodologies for practice-oriented undergraduate software projects (cases C and D) in academic settings (see Section 5). This rigorous three-fold evaluation of the practice and theory based HAMRA construct clearly indicates its practical applicability and relevance.

6.2 Research

The final version of the HAMRA was compared with three related frameworks such as ISO/IEC 24744 SEMDM International Standard (2007), Agile Scrum Framework (Schwaber 2007) and the Four-Tiered Framework of Iivari et al. (2000). This was done to ensure that the important elements are not overlooked in the proposed HAMRA construct. The comparative analysis clearly highlighted the concreteness and research contribution of the HAMRA (see Table 3).

Table 3 Comparison and contribution
Full size table

Firstly, HAMRA was compared with the ISO/IEC 24744 SEMDM. It is clear from the comparative analysis (Table 3) that the HAMRA construct incorporates both agile and traditional methodology elements (e.g. light grey coloured column) in addition to the already well-established ISO/IEC 24744 SEMDM traditional methodology elements. As noted earlier, ISO/IEC 24744 SEMDM seem to support only non-agile traditional methodology elements. Secondly, HAMRA was compared with the well-known and widely used agile industry framework of Scrum (Schwaber 2007). It has been found (see Table 3) that the contemporary Scrum framework discusses most of the elements of the HAMRA except methodology abstraction, legal, context and facility elements. Scrum seems to be an abstraction-neutral framework and claims to be used with a range of abstraction mechanisms. It also does not explicitly discuss the policy element. However, it seems that the policy element is embedded in its agile principles. Finally, HAMRA was compared with the generic Four-Tiered Framework (Iivari et al. 2000). This framework provides a four-layered architecture approach to classifying the ISD: ISD Paradigms (ISDP), ISD Approaches (ISDA), ISD Methodologies (ISDM) and ISD Techniques (ISDT). The scope of the HAMRA is limited to software and ISD Methodologies; therefore, we compared it to the ISDM layer of the Four-Tiered Framework with the HAMRA. The Four-Tiered Framework ISDM layer discusses the process element (e.g. relationship between techniques) and, surprisingly, it does not discuss the most important people element in the ISDM layer. The ISDM layer also inherits attributes from the ISDA layer (e.g. abstraction, goal, principles). Based on our detailed analysis, we found that ‘goal’ element seems to refer to business value element of the HAMRA, whereas ‘principles’ maps to the policy element of the HAMRA. The Four-Tiered Framework ISDT layer, below the ISDM layer, seems to discuss the technology and work product elements under the category of techniques. Overall, the Four-Tiered Framework seems to incorporate most of the elements of the HAMRA except the methodological people, agility, rule, legal, context and facility elements. This comparative analysis clearly indicates the concreteness and comprehensiveness of the HAMRA. It provides the elements, as a research contribution, which have not been discussed earlier (see Table 3).

The final version of the HAMRA was compared with three related frameworks such as ISO/IEC. The measureable benefits of agile approaches such as improved time-to-market, productivity and quality of software have already been demonstrated, studied and reported in the literature (Reifer 2002). The challenge for organisations is how to adopt agile at the large scale rather why do we need to adopt agile? This paper addresses this important concern of “how” and proposed the HAMRA construct. The analysis of the HAMRA, both from practice and research perspective, clearly highlights that it provides a comprehensive and concrete set of the agile and non-agile methodology reference elements and associated classes that can be used as a lens to create an architecture of a situation-specific hybrid adaptive methodology for adopting agile at the large scale (as demonstrated earlier). The HAMRA is intended to be used by agile and non-agile teams as a blueprint for understanding the overall picture of the agile and non-agile methodology elements.

6.3 Scope and limitations

The HAMRA should not be viewed as providing fine-grained details and exhaustive index of methodology elements and classes. It is an evolving construct and should be viewed with its scope and limitations. It is also not another agile, non-agile or hybrid methodology either. There are a number of agile [e.g. XP (Beck and Andres 2004), Scrum (Schwaber 2007)] and non-agile methodologies [e.g. Waterfall (Royce 1970), Spiral (Boehm 1988)]. These well-known agile methodologies, together with the Agile Manifesto (2001), originated in the context of small to medium project development environments, offering a collection of agile values, principles and industry best practices. However, they lack empirical evidence and theoretical underpinning. Traditional methodologies offer practices for large project development environments that lack agility whereas an agile response is preferable for tackling unclear or changing project requirements. Agile and non-agile traditional methodologies have their own individual advantages over each other (Qumer and Hnderson-Sellers 2008a). Therefore, it seems appropriate to have a hybrid methodology (e.g. a combined set of agile and non-agile practices) tailored for a specific situation by mixing both agile and plan-driven approaches to support the large-scale environment. However, a hybrid adaptive methodology reference architecture is required to represent and tailor a hybrid adaptive methodology. The proposed HAMRA construct developed here attempts to fill a small part of this gap. It builds on the empirical studies and also has theoretical underpinning and rigor, and integrates both agile and non-agile elements, which have not been previously analysed as we discussed in this paper.

HAMRA is a theoretical and practical construct, it is intended to capture and convey the high level view of the hybrid methodology elements and their relationships that can be detailed as needed for architecting a situationally-specific hybrid adaptive methodology. The HAMRA construct that we have developed and extended here needs to be considered with a view of its limitations since the body of literature and practice are both dynamic in nature. It should be considered as an ongoing work to be revised and extended by future studies. Given the project scope and time constraints, this study is limited to the number of case studies, qualitative analysis and finite number of theoretical concepts. However, based on the initial results, we are fully confident that the proposed HAMRA construct elements provide sufficient coverage and guidance for developing hybrid methodologies. It is important to mention that there was no relationship bias between the researchers and empirical study organisations. The analysis, coding and labelling of HAMRA elements are subject to human error and mistakes, which may lead to inconsistencies. The elements and their interconnections were identified by the first author independently, and the second and third were continuously involved in critically reviewing each element. This review was performed iteratively to get feedback and minimize any possible omissions, errors or analysis bias. The review feedback, and disagreements were discussed and resolved during review meetings involving the second and third authors, who have more experience in IS modelling and methodologies.

7 Conclusion and future work

Agile approaches are based on industry best principles and practices; and have been criticized for lacking empirical evidence and theoretical underpinning. The research reported here attempts to fill a small part of this gap (between theory and practice). Here, the HAMRA conceptual construct has been presented based on an analysis of both literature and qualitative empirical studies. A number of existing well-established (people, process, product and technology) and new (agility, abstraction, business value, rules, policy, legal, context and facility) elements have been discussed. These new elements and HAMRA as a whole construct initiate research into possible extensions to the ISO/IEC 24744 SEMDM International Standard that will both support agility concerns and also modify the standard in a seamless way – by using the extension procedure detailed in Henderson-Sellers and Gonzalez-Perez (2006).

The HAMRA construct is thus a first step towards the possible future investigation of a standard metamodel for hybrid adaptive development methodologies. Based on analysis presented in this paper, the HAMRA elements can be used as a checklist or vision-guiding reference architecture when constructing various situation-specific agile and hybrid methodologies. Further research may investigate whether there are other elements that can be included in HAMRA. An empirical study can be conducted to understand the impact of identified HAMRA elements on the project success factors such as quality, time, scope, budget, and customer satisfaction. Similarly, a design-oriented and action-oriented study can be conducted for building, intervening and evaluating (BIE) the details of different types of HAMRA artefacts for different industrial contexts (e.g. health, financial services, manufacturing). This research is further implementing the proposed HAMRA and developing a full scale context-aware hybrid adaptive methodology information system. The initial prototype has been developed and deployed as an agile e-toolkit in the public cloud environment to support the teams to self-tailor agile and hybrid methodologies for their local context (see Qumer and Hnderson-Sellers 2010). The discussion of the agile e-toolkit is beyond the scope of this paper due to space limitations. This paper concluded with the development of a theoretical and practical HAMRA construct as a prelude to likely further research directions in this important area.