Organizations undertaking software development are often reminded that successful practice depends on a number of non-technical issues that are managerial, cultural and organizational in nature.4,8 These issues cover aspects from appropriate corporate structure, through software process development and standardization to effective collaborative practice. Since the articulation of the 'software crisis' in the late-1960s, significant effort has been put into addressing problems related to the cost, time and quality of software development via the application of systematic processes and management practices for software engineering. Early efforts resulted in prescriptive structured methods, which have evolved and expanded over time to embrace consortia/ company-led initiatives such as the Unified Modeling Language and the Unified Process alongside formal process improvement frameworks such as the International Standards Organization's 9000 series, the Capability Maturity Model and SPICE.
More recently, the philosophy behind traditional plan-based initiatives has been questioned by the agile movement, which seeks to emphasize the human and craft aspects of software development over and above the engineering aspects.1,2 Agile practice is strongly collaborative in its outlook, favoring individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan (see Sidebar 1). Early experience reports on the use of agile practice suggest some success in dealing with the problems of the software crisis,12 and suggest that plan-based and agile practice are not mutually exclusive.10 Indeed, flexibility may arise from this unlikely marriage in an aim to strike a balance between the rigor of traditional plan-based approaches and the need for adaptation of those to suit particular development situations. With this in mind, this article surveys the current practice in software engineering alongside perceptions of senior development managers in relation to agile practice in order to understand the principles of agility that may be practiced implicitly and their effects on plan-based approach.
To elicit an understanding of current practice and perceptions related to agility, an online questionnaire was designed11 with the following objectives in mind:
E-mail was used to contact senior development managers at 970 organizations in the United Kingdom, requesting that they participate in the research. The selection of participants was based on the contact list available and research noting that senior management influence productivity.3 The survey itself comprised of 32 questions that were organized into three sections addressing background/demographics, current software development practice, and perceptions related to agility. Online presentation of the questionnaire ensured that the section on current practice had to be completed before the section on perceptions of agility could be viewed and completed in order to reduce bias.
Table 1 summarizes the demographics of the 62 organizations that responded to the online survey (equating to a response rate of 6%). Overall, the respondents had on average more than 10 years development experience, had variation in their development experience (having worked in more than 4 software development roles), and worked in organizations that had more than 500 employees. The majority of responses received were from IT directors, senior architects and IT managers. In addition, responses from the larger organizations covered inhouse development departments of a variety of sizes from fewer than 10 employees to more than 500 employees. Last, and importantly, only about a quarter of the respondents used an explicitly recognized agile method as detailed below.
The objective of understanding the state-of-practice was to provide a benchmark in order to assess the gap with the concepts of agile practice. The use of software development processes provided the framework for enquiry and a number of questions were asked to provide correlation points for agile practice (discussed later). The major outcomes of interest are that:
In detailed terms, more than half the sample claim to use a formal software development process within their organization, either developed inhouse (56%) or commercially branded (18%). Of the respondents that use formal software development processes (74%), the majority indicated that they based their processes on framework-based approaches which cater for flexibility. These approaches included the Rational Unified Process (RUP) 30%, Dynamic Systems Development Methodology (DSDM) 18% and eXtreme Programming (XP) 8%. Interestingly, organizations using a formal software development process tailor/configure them strongly (82%), lending weight to the adage that 'people don't adopt a methodology, they adapt it' (attributed to Tom DeMarco); and use different processes for different types of project (79%). Tailoring of software development processes, once seen as a negative activity that violates the 'rigor and consistency' of software development processes,6,9 now appears to be seen in a positive light as necessary and is embraced. The following opinion highlights a practitioner's view on flexibility: "Although a method provides a useful framework, it has to be flexible in order to reflect real-world constraints and priorities."
The levels of effort put into tailoring/configuring process varied: 16% stated they spent 1% percent of overall project time on tailoring the software development process; 67% of respondents stated the time to tailor processes ranged from 1% to 5% of overall project time; 19% stated they spent 10% 20% of the project time and 2% stated that they use 40% of the project time. The type of people involved in process tailoring were senior management, project managers, architects and the development team where there appeared to be a decision maker, the development team was always involved in the decision. Lastly, 'project characteristics' were the predominant criteria on which tailoring decisions were made (44%).
Of the respondents that do follow some form of software development process, the majority stated that their processes are based on an iterative and/or incremental software development lifecycle (68%), the remainder being based on the more sequential waterfall model. Nearly all respondents stated that they cater for changing requirements, even late in the project (98%). Of that proportion, only some follow the dynamic prioritization path proposed by iterative/incremental development (39%) - the majority of respondents continue to use traditional change control request (61%).
The objectives of questioning around agile principles were to ascertain perceptions related to the value and importance of agility and to relate that information back to the context of current practice in order to understand the match between principle and practice do organizations practice what they state as important. In summary, respondents were presented with background information related to agile values and principles and asked to rank the principles in terms of importance from an organizational perspective and then rate its importance from a personal perspective. Summary results are shown in Table 2; these findings were then linked back to earlier questions to match perceptions with practice. The major points of interest are that:
In detailed terms, the results showed Principles 1, 5 and 7 (see Table 2) as unequivocal in their perceived importance (60, 84 and 60% respectively). When examining the frequent delivery of working software the results from current practice showed that the majority of respondents delivered on three monthly cycles (31%). Significantly, however, a number of respondents delivered on monthly cycles (24%) and two-week cycles (24%) smaller percentages delivered on weekly cycles (5%) or produced only a final release (17%). In communication terms, the frequency of communication between Business and IT ranged from approximately once a month (13%), through once or twice a week (56%), to communication on a daily basis (29%). The primary means of communication within software development practice is face-to-face within development team (79%) - few respondents use e-mail (17%) or telephone (4%) as a primary communication tool.
While the delivery of working software was seen as important, the results related to software being the primary measure of progress were much more ambiguous. Here, findings from the data collected in practice showed a strong reliance on traditional project metrics. While a number of project respondents do use working software as the primary measure of progress (26%), a significant number use other project milestones and deliverables (54%) or completion of process/lifecycle stages (20%). Similarly, while the majority of respondents state that they cater for change late in the development cycle, change does not appear to be a particularly welcome factor. Interestingly, however, there is a strong correlation between the respondents who embrace change (40%) and their use of dynamic change control techniques (38%).
Low areas of organizational importance indicate that a significant number of respondents (47%) value human facets of development over and above typical facets of cost, quality and time. This view is borne out to a given degree when the data is correlated with the view that projects should be built around motivated individuals (53%) and practice indicating that (a) the development team is involved with decision making (64% on average) and (b) individuals are empowered to make decisions on work directly related to them (89%). In contrast, however, the results note that, while the development team is involved in tailoring the software development process (64%), team skills are the least used tailoring criteria (22%).
The results also indicate that architecture and design were viewed from a top-down perspective and not as artifacts that should emerge from practice and dialogue. While this is interesting, the respondents' comments indicate a poor understanding of the question and we have thus discounted data in this regard. Lastly, other interesting but less obvious results are:
All surveys carry health warnings and this example is not immune. Overall, the sample size of the data can be considered limited in that it addresses a UK audience and the response rate is small at 6%. With such limitations in mind we have sought to present the results without bias in order to allow the reader to draw their own inferences. Overall, however, a number of interesting conclusions may be drawn in relation to the state of practice and the implicit use of agile principles:
Table 3 provides a summary of agile themes that are relevant in terms of their adoption in practice. The findings suggest that there is an uptake of the principles of agile development, though in larger organisations this uptake is countered by the perceived need to maintain rigor and control of the process. In practice, the adoption of agile principles is implicitly tied up with process tailoring, configuration and iterative lifecycles - the correlation between these factors and the agile principles noted as important is strong. Process flexibility therefore emerges as the 'marriage' between agility and plan-based approaches, increasingly supported by framework-based process approaches such as RUP.
9. Hardy, C.J., Thompson, J.B., and Edwards, H.M. The use, limitations and customization of structured systems developement methods in the United Kingdom. Information and Software Technology 37, 3, (1995), 467477.
11. Patel, C., Lycett, M., Macredie, R.D., and de Cesare, S. Perceptions of agility and collaboration in software development practice. In Proceedings of the 39th Annual Hawaii International Conference on System Sciences (Kauai, Hawaii, January 47). IEEE Computer Society Press, Los Alamitos, CA, 2006.
©2010 ACM 0001-0782/10/0600 $10.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2010 ACM, Inc.
No entries found