The term Agile Development has been growing in popularity over the past few years, as too has its adoption in the workplace. The principles of agile development were drafted during a gathering of software development practitioners in 2001. Their goal was to attain a common ground amongst their various development methodologies and what emerged was the Agile Manifesto.
The aim of the Manifesto, as stated by Highsmith was to create a methodology that was flexible, made sense and importantly actually delivered to the customer. "We embrace modelling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment" (Highsmith et al 2001)
The participitants at the meeting agreed that in practice agile methodologies are about delivering good products to customers by operating in an environment that focuses on the people in the process, both the provider and the customer of the service, and delivery of the product as promised, in the timeframe as promised. (Highsmith et al 2001)
The Agile Manifesto states four main principles
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Conboy and Fitzgerald describe agile as the ability and willingness to respond to change "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 and Fitzgerald 2004) However, many commentators feel that agile literature has been lacking in empirical evidence of its effects on software development projects within industry. And critics view agile's light approach negatively due to the perceived lack of planning and documentation.
In this paper we will examine two agile software development methods, eXtreme Programming (XP) & Scrum
Extreme Programming
Fowler describes Extreme Programming as championing five key values; Communication, Feedback, Simplicity, Courage, and Respect. These five values are then further developed into fourteen principles and further segmented into twenty-four practices. The idea is that practices are concrete things that a team can do day-to-day, while values are the fundamental knowledge and understanding that underpins the approach. (Fowler 2000)
The objective of any software development methodology is to provide a solution to the customer. Wells states that extreme programming focuses on identifying the elements of a system, prioritising these elements and delivering the key element of the software to the customer when they need it. The process encourages the empowerment of the developers to respond to changing customer requirements at any stage in the lifecycle. Developers receive feedback on their progress directly from the customers. This is feedback is facilitated through regular review sessions and a process which fosters strong communication between programmers and customers. (Wells 2001)
Wells describes the process as below:
User Story
User stories provide the requirements for the design and development stages. User stories should provide only enough detail to make a reasonably low risk estimate of how long the story will take to implement.
Collaborative Design
When the time comes to design and develop, developers will work with the customer face to face to capture detailed requirements. This further encourages the close contact between the customer and development
Release Planning
Release planning specifies which user stories are going to be implemented for each system release and specifies dates for those releases.
Multiple Iterations
An individual project is divided into iterations. Iterative development lends flexibility to the development process.
Small & Often
The development team needs to make frequent releases of the system to the customers. At the end of every iteration the goal is to have tested, working, production ready software to demonstrate to the customer.
Scrum
In Scrum, projects are divided into sprints, which are typically two or three weeks in duration. At the end of each sprint, project stakeholders can assess the progress to date and agree on the next steps. This allows a project's direction and priorities to be modified as required based on external impacts or changing business needs. The key element is that the delivery team and customer have a clear understanding of their progress to date based on tangible working software. This provides a strong foundation when deciding on next steps or when new business requirements are identified.
Scrum Process
Product Backlog
This is the prioritized list of all features and changes that have yet to be made to the system. The Product Owner is responsible for maintaining the Product Backlog.
Sprints
The procedure of adapting to the changing environmental variables (requirements, time, resources, knowledge, technology etc) and must result in a potentially shippable increment of software. The working tools of the team are Sprint Planning Meetings, Sprint Backlog and Daily Scrum meetings.
Sprint Planning meeting
Sprint planning meeting is first attended by the customers, users, management, Product owner and Scrum Team where a set of goals and functionality are decided on. Next the Scrum Master and the Scrum Team focus on how the product is implemented during the Sprint.
Sprint Backlog
It is the list of features that is currently assigned to a particular Sprint. When all the features are completed a new iteration of the system is delivered.
Daily Scrum
It is a daily meeting for approximately 15 minutes, which are organized to keep track of the progress of the Scrum Team and address any obstacles faced by the team.
Agile Methodology Summary
When investigating XP or Scrum, the focus and importance of people is particularly evident. Project member's expertise, skill, and knowledge become the most crucial element of the processes. Agile teams are characterized by their ability to organise themselves as required for each particular deliverable, think on their feet and collaborate, within and across organizational boundaries. Self-organizing teams are not structure less or unfocused; they are teams that can organize themselves as required, to meet challenges as they arise. Agility requires that teams have a common focus, mutual trust, and respect; a collaborative, but speedy, decision-making process; and the ability to deal with ambiguity. (Highsmith & Cockburn ????)
Waterfall Development
Waterfall development is a methodology for software development in which work flows through a series of predefined gates. Each phase of work must be complete before the next phase can begin. The process starts with system requirements analysis, design, development and leads up to product release and maintenance. To accommodate change or errors which can arise during the process, the waterfall model has a series of feedback loops between each phase, providing some flexibility to "go back" a phase and make appropriate modification. The waterfall model is described as having six distinct phases, described below:
Waterfall Process Overview
Requirements analysis
The requirements analysis phase involves understanding and documenting the customer needs. Typically requirements are captured in a structured requirements specification document. Once reviewed and agreed by the customer the requirements document forms the starting point for the next stage.
Design
The design phase involves the identification and definition of the individual elements which will make up the final solution to the customer (hardware, software, specifying performance, designing data storage containers etc), including the user interface design. The output of this phase is a design document which describes just how the customer requirements will be satisified. As in the requirements analysis phase, this design document must be approved by all relevant stakeholders before the project is allowed proceed to the next phase.
Development
The development phase is when the design plan is carried out by the relevant areas. This can include the procurement of hardware or development of the necessary code. In this phase both the design document and the requirements specification are used.
Testing
The testing phase involves verifying that the new development operates as expected, both the individual components and when integrated with legacy systems in the environment. Once again the requirements specification and design documents are used, in this phase it is for the creation of test scripts.
Installation
Following a successful testing phase, the new software is introduced into the live environment.
Maintenance
Once installed, the new development may require modification following identification of bugs while in the live environment. Issues which were not flagged during testing can arise or the development may require rework as the customer is not satisfied with the end product.
Unified Process
All efforts are organized into workflows in the Unified Process and is performed in an iterative and incremental manner. Some of the key features of the UP are as follows [19]
Component Based
It uses a component based architecture which creates a system that is easily extensible, promotes software reuse and intuitively understandable. The component commonly being used to coordinate object oriented programming projects.
Visual Modeling
Uses visually modeling software such as UML which represent its code as a diagrammatic notation to allow less technically competent individuals, who may have a better understanding of the problem, to have a greater input.
Requirments Capture
Manage requirements using use-cases and scenarios have been found to be very effective at both capturing functional requirements and help in keeping sight of the anticipated behaviors of the system.
Iterative and Incremental
Design is iterative and incremental - this helps reduce project risk profile, allows greater customer feedback and help developers stay focused.
Quality control
Verifying software quality is very important in a software project. UP assists in planning quality control and assessment built into the entire process involving all member of the team.
UP is a document heavy process, which combined with a rigid approach adds a lot of complexity. UP, like other Traditional methodologies, defines roles and expectations to the each member of the project team making it less flexible.
Traditional Summary
The heavyweight methodologies have the following characteristics in common
Planning - A key element of these traditional methodologies is the upfront planning involved. Traditional methodologies devote a large amount of time to laying out the individual phases of the project, perhaps months in advance.
Documentation - In traditional methodologies the capture of requirements early in the process is fundamental. The idea is that, at the beginning stages of the process, we should be able to flesh out and capture the customer's requirements. In doing this, future stages can be planned in finer detail. Requirements and other documentation throughout the lifecycle ensure understanding across the phases and attempts to eliminate the potential for misunderstanding. All changes to signed-off documentation usually require change requests, again fully capturing the nature and reason for the change
Process - Fowler believes the goal of traditional methodologies is to "define a process that will work well for whoever happens to be using it". (Fowler 2000). For each stage in the lifecycle there are expectations of the process itself and the individuals involved. The process clearly identifies and documents these expectations
Traditional methodologies enforce a disciplined process, with the aim of making software development more predictable and more efficient. However, as Fowler points out, critics of the methodology see it as bureaucratic, and feel that there is so much involved in following the methodology that the whole pace of development slows down (Fowler 2000). Highsmith & Cockburn also feel that the over reliance on the process to ensure success is dangerous. They feel that there is often confusion between process and competence. "Process can provide a useful framework for groups of individuals to work together, but process per se cannot overcome a lack of competency, while competency can surely overcome the vagaries of a process" (Highsmith & Cockburn 2001)
Rigid v's Flexible
Traditional methodologies are rigid in the steps to be followed and the requirements of each phase. The rigid phased lifecycle ensures that every phase has a defined start and end point, with signed-off documentation from one stage initiating work in the next stage. Agile methods deal with unstable and volatile environments, where priorities and even requirements are changing. By using a number of techniques which focus on collaboration between developers and customers, adaptability and flexibility is built into the process to accommodate this potential volatility
Inclusive V's Generative
Traditional methodologies provide inclusive rules. These rules cover the complete range of options and steps which are available to an adherent of the methodology under any given situation. Agile methods offer generative rules. This contrasting approach provides for a minimum set of rules which an adherent must do under all situations. Highsmith & Cockburn believe that teams which follow inclusive rules will rely on someone else to plan for a given scenario and dictate the actions to be taken, adopting a very passive role in the process. However. They feel that the team that follows generative rules "depends on individuals and their creativity to find ways to solve problems as they arise." (Highsmith & Cockburn 2001)
Once v's Often
In general traditional methodologies design and deliver once in one big chunk based on very detailed requirements, design and development specifications. In contrast, an agile approach espouses iterative design and delivery in smaller chunks.
Up Front v's Gradual
Traditionalists espouse the logical process of ensuring requirements are documented, understood and agreed, before proceeding with design and later development, with the understanding that this approach will reduce the risks associated with scope creep and schedule slippage. Agile methodology sees this as unrealistic. Glass comments customers rarely fully understand what they want at the outset, and true requirements usually emerge following reviews and discussions later in the process. (Glass 2001)
Planning v's Reacting
One of the key elements of the traditional methodologies is detailed planning. The goal of this is to provide management and customers with an easily digestible picture of how the project will run and to aid in determination of effort and cost for delivery of the project before work has commenced. However agile methodology supporters feel that this advance planning is wasted work since changing customer requirements or operational environments mean that estimates are unreliable at best and deceptive at worst.
Estimated v's Actual
Traditional methodologies provide a clear understanding of the progress made and work remaining by using the defined stages of the process, which aids in management of the process and in providing feedback to the customer. (REF ????) Practitioners of agile methodologies receive their feedback and determine their progress based on how the customer reacts to actual completed work, providing a clear indication of the success to date and remaining work. "The working code can be shipped, modified, or scrapped, but it is always real". (Highsmith & Cockburn 2001)
Process v's People
Traditional methodologies reduce the level of interaction between the customer and development or delivery teams. The methodology operates on the understanding that a well specified requirements document can act as the hand over between the business and technology.(REF?????). One of the key principles of agile development is the people and how they are used. Allowing people communicate freely, both within the delivery stream and across the organisational structure as a whole achieves manoeuvrability, speed, and cost savings. Highsmith & Cockburn believe that people can communicate requirements and solutions more accurately through face to face interaction than by writing and reviewing specification documents. Designers working together will produce better designs than any one would produce working alone. Similarly, designers sitting down and discussing requirements in an collaborative manner with the customer will ensure better requirements. (Highsmith & Cockburn 2001)
In Boehm & Turner's [10] vision of the future they predict that in the past there have been many small, noncritical, agile culture, rapidly evolving projects within the agile domain. There have also been many people working on large, critical, stable projects which operate in the structured plan driven arena. However things are changing. Large projects can no longer count on low rates of change, and their "extensive process and product plans will become expensive sources of rework and delay". (Boehm & Turner 2004) As the adoption of agile methods evolves from small stand alone, nocritical projects to the larger cross functional, cross technology, core applications, Boehm & Turner believe the "typical development complexities will be waiting for them, thus there will be a higher premium on having methods available that combine agility and discipline in situation tailorable ways". (Boehm & Turner 2004)
This sentiment is echoed by Glass, when he states that much of the agile developments have been small to medium sized, and there is no reason to believe that they will not grow into larger endeavours. In doing this they could do well to bear in mind the hard learnt lessons and accumulated wisdom of their fellow traditionalist developers who have been working with large projects for quite a lot longer and have experienced all the pitfalls that can be encountered. (Glass 2001)
Gunton suggests that a linear approach is less relevant nowadays and again echoes the fact that systems and development processes must now cope with uncertain organisational requirements, which cannot be specified in specific quantitative terms, and which are subject to constant organisational change. (Gunton 1990) Yoong & Huff describe how agile methodologies can survive and thrive within a changing software development environment which has had to redefine itself in light of the failures and inadequacies of traditional, heavyweight development methodologies (Yoong & Huff 2007)
Another key weakness in the traditional methodology highlighted by Glass is the necessity for the customers' requirements to be agreed at the start of the process. Often customers who may be unfamiliar with the overall methodology and the importance of providing detailed requirements up front do not have the time or experience to specify their requirements accurately at that stage. (Glass 2001) Likewise, the teams responsible for the delivery - the IT personnel, often have limited understanding of the business side of the organisation and their main objective is to remove the operational 'real world' experience into structures and processes. Newman and Rosenberg describe this as 'conflict is structured into the relationship'. (Newman and Rosenberg, 1985)
.
Evaluation versus Traditional
Glass evaluates the principles of agile programming versus the more traditional development methodologies in an attempt to understand why the agile methodologies are not being accepted more widely. Glass uses the four key principles of the Agile Manifesto as a basis for his examination (Glass 2001)
Individuals and interactions over processes and tools.
He agrees with this idea, stating that traditional software engineering has gotten "too caught up in its emphasis on process" (Glass 2001), and states that we have forgotten the lesson exhibited on Barry Boehms book Software Engineering Economics, which shows that the quality of the programmers and the team is by far the most influential factor is successful software construction.
Working software over comprehensive documentation
On the concept of working software over comprehensive documentation, Glass once more agrees, reminding us that the most important element of the process is the end product and offers that over the years traditionalists have made a 'fetish' of documentation. However he does stress the need for documentation in certain areas e.g. manuals and requirement specs and stresses the importance of not just documenting, but updating and revising documentation as required.
Customer collaboration over contract negotiation,
This is an area where Glass feels the 'Agilests' have a question to answer. He agrees that collaboration is vital in a successful end result, but highlights that in the real world no significant piece of work should be started without contacts.
Responding to change over following a plan.
Here Glass highlights what he sees as a simple fact "that customers and users do not always know what they want at the outset of a software project". (Glass 2001) He believes that a software development methodology must encompass an ability to accommodate that change. However, he feels the traditional approach with its detailed planning and scheduling is preferable to the 'lighter' agile approach. He believes that planning is vital and that change should not be allowed ride roughshod over it, instead the planning should incorporate a plan to change. This is in direct contrast with the research of Vijayasarathy & Turk who identified improved predictability of schedule as a benefit of Agile methodologies. (Vijayasarathy & Turk 2008)
Glass is also in conflict with Highsmith & Cockburn, who feel that if identifying requirements at the outset is near impossible, and change is an indisputable part of the modern software development then the dependence on a plan which is effectively out of date once published is a waste of time. (Highsmith & Cockburn 2001)
Difficulties with adoption of agile practices
Highsmith & Cockburn recognise that agile development may not suite every organisation. They reason that the organisation needs to be in a position to be able to adopt agile methods and imposing these practices without due attention to the potential issues can be disasterous
"Imposing agile principles on process-centric, non-collaborative, optimizing organizations is likely to fail. Imposing a change embracing process on sedate project teams may not be reasonable. Attempting to get close user collaboration with organizations that have little time to spend with developers won't work." (Highsmith & Cockburn 2001)
Marks identifies some drawbacks with an agile approach which should be considered before any decision is made on the appropriate methodology for a particular project or organization
Difficulty coordinating larger teams
Can result in a never-ending project if not managed properly
Tendency to not document thoroughly
Predicting the precise features to be accomplished in a fixed time/budget
(Marks 2002)
Marks states that agile methodologies are their most effective when employed with small, highly skilled teams. If the project team are spread over a large geographical area or the team itself is working on cross functional systems, the more difficult it is to coordinate activities with an agile approach. Furthermore he believes that the iterative approach lends itself to scope creep and project over-runs. (Marks 2002)
Bohem & Turner identified three areas of conflicts which can arise when trying to implement agile processes into an organisation
Development process conflicts
When discussing development process conflicts, Bohem & Turner identify a range of issues which organisations will need to contend with when attempting to introduce a more agile development approach into traditional processes. These include variability, different life cycles, addressing legacy systems and requirement gathering.
Business process conflicts
Business process conflicts can include the impact on human resources processes, the need to redesign the methods used to measure individuals progress and conflicts with standards accreditation such as ISO
People conflicts
Bohen & Turner believe that identifying and addressing the people conflicts is by far the most important element when introducing a new way of working, in particular agile practices as they are founded on empowering the individual "People issues are at the heart of the agile movement" (Bohem & Turner 2005).
This is supported by Yoong & Huff who identify how the adoption of agile methodologies and the agile manaifesto principles place increased demands not only on software developers, test managers and customers, but especially on the people managers. They believe that to successfully introduce an agile methodology, organizations will need to manage, harness and direct the skills and talents of their personnel involved. Organisations must focus less on task and more on organisational concerns such as communication, team work, customer focus and quality.
These conflicts are evident in a survey carried out by Vijayasarathy & Turk, where they find that respondents attribute problems with the acceptance of agile development to organizational resistance and managerial disinterest. Lack of training and peer support are also recognized as challenges compounding the view that failing to prepare for the implementation of agile processes within the organisation are probably the biggest roadblocks to the introduction and adoption of agile practices. (Vijayasarathy & Turk 2008)
Defining the theoretical foundation for a study is the first step in conducting research. Before examining the methodology chosen the purpose statement for this research will be defined. We will then investigate the research question and with that established this dissertation will evaluate methodologies to best answer this question.
Purpose statement
The purpose statement outlines the reason behind doing the research, it narrows the focus of the study to a specific question area. (Creswell 2003) The question under investigation here is: Why are companies reluctant to adopt agile software development methodologies?
<<OR WHAT ARE THE ISSUES AFFECTING THE ADOPTION OF AGILE SOFTWARE METHODS>>
The purpose of this research is to confirm identify if there is reluctance amongst organizations to adopting an agile software development methodology and determine if those concerns are genuine. In answering this question, this research will identify the causes of this reluctance and identify measures or controls which can be put in place to reduce the risks identified.
"Research questions define the issues the investigator is seeking to answer". (Creswell 2003) The objective of this research is to identify the issues relating to the adoption of Agile Methodologies and suggest solutions to overcome these issues.
To answer this question this paper breaks the research down into further questions. The questions need to be structured in such a manner as to allow for input from organizations which have adopted agile methodologies and those not yet converted. This will provide a picture of the opinions from both sides of the story.
Breakdown the Question
Do Agile Methodologies deliver benefits in the form of quality, cost and customer satisfaction to the software development lifecycle?
If such benefits exist why are more organizations not using this methodology?
Do these reluctances arise from organizational or delivery issues?
Where an organization has adopted agile methodologies, what issues did they encounter?
How did these organizations who moved from more traditional to agile methodologies overcome these initial integration/adoption issues?
Establish the Benefits
Where organizations are currently using agile methodologies it is important to determine how long they have been using these methodologies and if they have identified any benefits arising for the use of this approach.
Introduction of Agile
Where organizations are currently using agile methodologies, respondents will identify how agile methodologies were introduced into their software development process (phased etc)? These respondents can also provide feedback on their experiences of both Traditional and Agile methodologies
Obstacles/Solutions to Introduction
Where agile methodologies have been adopted and embedded in an organization this research will allow respondents highlight the obstacles encountered with the introduction and the measures taken to overcome these obstacles?
Traditional Methodology Organizations
It is probable that some of our respondents will be operating in organizations which continue to use traditional development methodologies, these respondents will be asked if they are aware of Agile methodologies, and if so are they aware of the benefits attributed to Agile methods?
Adoption of Agile Methodologies
Traditional methodology practitioners will be asked if they can identify the reasons for not adopting Agile methodologies within their organization? These respondents will be able to further identify if these obstacles are of an Organizational (culture reluctance to change etc) or delivery nature (perceived inefficiencies and overhead involved in Agile methodologies)
Methodological framework
Before embarking on any research, this paper must determine the most appropriate research method to answer the key questions. As a methodology, interpretive research does not predefine dependent or independent variables, nor does it set out to test hypotheses, but aims to produce an understanding of the social context of the phenomenon and the process whereby the phenomenon influences and is influenced by the social context (Walsham 1995).
Trauth lists five factors influencing the choice of qualitative methods in IS research.
Nature of the research problem,
The researcher's theoretical lens,
The degree of uncertainty surrounding the phenomenon.
Researcher Skills
Academic Politics
(Trauth 2001)
Nature of the Research Problem
The identification and definition of software development methodologies is very often subjective and requires a deep understanding of the subtleties contained in each to understand if agile or traditional methodologies are actually being applied. Furthermore there are a wide range of potential adoption issues which need to be investigated. This lends itself to a more flexible qualitative approach as the questions which need answered will require clarification and will change from one individual/organization to another. Rowlands builds on Trauths understanding of this by stating that what we want to learn will help shape the research questions posed, and the questions posed will depend on the stage of knowledge accrual about the phenomenon. (Rowlands 2005)
The researchers theoretical lens
Based on the low adoption rate of agile methodologies, as highlighted by Laplante & Neill (2004), it is assumed the adoption of a particular software development methodology is not an objective phenomena with known criteria and measurements. In this case adopting an interpretive approach, is consistent and compatible with the epistemological and ontological assumptions that experience of the world is subjective and best understood in terms of individuals' subjective meanings rather than the researcher's objective definitions. In selecting this method of research the paper understands that the criteria for adoption of software development methodology is too complex to define and measure with standard instruments. In order to gain greater knowledge about the subjects understanding of adoption and success of a particular methodology this paper proposes a flexible method capable of capturing broader subjective feelings and thoughts of its subjects.
Degree of uncertainty
The degree of uncertainty and ambiguity surrounding the topic also confirms the author's qualitative, inductive, interpretive stance. Of the research that had been undertaken, the dominant approach had been positivist with an emphasis on surveys as the main methods of analysis and data collection. A review of published research into agile methodologies was identified as being over-reliant upon mail surveys or exposed to a risk of researched bias (for example Shine Technologies, "Agile Methodologies Survey Results. (Shine 2003)) The existing research could identify what the key benefits were, but it does not tell us why organizations chose as they did, or how they overcame obstacles.
Researcher's Skills
The researcher is an experienced interviewer, capable of conducting a semi structured interview
Academic Politics
This was not an issue as the College expressed no preference towards the choice of positive, interpretive or critical methods.
While a structured interview is limited in the questions which can be posed, a semi-structured interview works on a loose framework of questions which guide the interview while providing the flexibility for the interviewer to raise new questions and avenues for investigation which can be followed as a result of the interviewees responses. This support the interpretative research method selected.
The interviewer in a semi-structured interview generally has a framework of themes to be explored; with specific topics that the interviewer wants to explore during the interview thought about well in advance. The interviewer can let the interviewee speak with more than just their words but with facial and bodily expression too. Also, it allows the interviewee to go into as much depth as they feel they want to, whereas other interview types wouldn't allow this type of freedom. The semi-structure method allows for questioning which hadn't been considered in the initial overview be asked in an evolving or organic nature.
Benefits of Semi Structured Interviews:
Semi-structured interviews are helpful to gain a detailed picture of the respondents' beliefs about, or perceptions or accounts of, a particular topic. The advantages of semi-structured interviews are that they facilitate rapport/empathy, allow greater flexibility of coverage and enable interviewers to enter novel areas, and they tend to produce rich data. (Smith 1995)
Furthermore, semi-structured interviews can include the use of different medium, such as drawings and the presentation of real life examples, all with a view to attaining a better understanding of the issues involved
Implementation
Semi-structured Interview Design
High level areas for questioning will be prepared to ensure the interview remains focused. The interview is flexible within those high level questions, and the interviewee will be asked to describe their experiences in their own words. Probing questions will be used by the interviewer seek further clarification on the interviewees responses to ensure understanding of the issues being discussed.
The guideline questions of the interview will be organized according to topical areas of inquiry that should follow each other in a logical fashion. While the interviewer has to be able to speak the language of the community in the interview is conducted, the language used should be comprehensible and jargon free where possible
An ability to ask short, simple and easy questions, to listen attentively, to steer the interview sensitively in the desired direction and to remember what was said earlier and interpret correctly respondent's statements during the interview are of paramount importance for the interviewer. Closed questions, allowing the interviewee answer 'Yes' or 'No', or guiding questions should be avoided.
Kvale (1996) identifies nine types of questions in qualitative interviewing:
Introducing: "Please tell me about …"
Follow-up: "What do you mean by....?"
Probing: "Could you say more about that?",
Specifying: "What did you do then?"
Direct: Are you happy with…?"
Indirect: What do most people here think about…?"
Structuring: "I would like to move on to a different topic!"
Interpreting: "Do you mean that…?"
Silence: A pause to signal to respondent to reflect or expand on their answer.
These questions suggest that the interviewer(s) should be engaged without being invasive. While the main objective of the interview is to get answers to the guideline questions, the benefit of semi-structured interviews is that they also allow for the interviewer to get an understanding of the values, emotions, stories beliefs, behaviour of the interviewee.
Distribution
Participants will be chosen based on their job roles and their industry experience. Personal in-depth interviews were carried out with the candidates at an agreed time over a three week period.
Interviews will be recorded and transcribed as soon as practicable following the interview to ensure body language nuances can also be included while fresh in memory. The key element is to record the meaning of what is being said rather than the exact words of the respondent. (Perry1998)
Participants
"The participants of the survey must possess the information needed and knowledge of the area under investigation". (Rea 2005) As agile methodologies and their adoption are primarily driven by on senior management and applied by release/delivery management these roles were chosen as the sample population.
Roles
Senior Management
Ultimately Senior Management approves and supports any software development methodology. These business and IT managers must understand and agree to work together within a prescribed framework with the ultimate goal of delivering business needs and a competitive edge. Their input to the questionnaire is required to understand why and how decisions were made on the adoption or otherwise of a methodology within their organizations.
Release/Delivery Management
These are the individuals devoted to implementing the prescribed framework and managing the day to day issues which can arise. They are responsible for ensuring the necessary controls and structures are in place, operating effectively and adhered to in the delivery of software products to the end customer. Release/Delivery management operate within the delivery process and are thoroughly knowledgeable of all the issues which can arise. Their responses to the questionnaire is vital to understand the difficulties and benefits of operating managing a methodology
Organisations
This research focuses two industries, financial services and telecommunications. Both of these industries depend heavily on their software development mechanism to provide services and products to their customers. However software development is not a core financial services activity and these companies do not use their IT capabilities as a differentiator in the marketplace, while for telecommunication companies, innovation in software development and their ability to respond to customers' needs, is directly related to their public offering
The organisations selected will represent companies with internal development functions and, as they represent a significant element of the software market, suppliers of software services to these companies.
Analysis
Since the results of a semi-structured interview are by their very nature often unstructured, analysis is not a straight-forward process. The recorded findings of a semi-structured interview require categorization to provide meaning.
The grounded theory process of coding & categorising interview information according to topical heading, is commonly used to make sense of qualitative research findings. Coding uses this organisation of the interview data into logical components or topics enabling evaluation of data, in turn, this allows for patterns to emerge across all collected material.
