agile methodologies and software process improvement

ISBN: 972-8939-00-0 © 2005 IADIS

AGILE METHODOLOGIES AND SOFTWARE PROCESS IMPROVEMENT Kerstin V. Siakas Technological Educational Institution of Thessaloniki, Department of Informatics, P.O. Box 14561 GR-54101 Thessaloniki, Greece

Elli Georgiadou, University of Middlesex, School of Computing Science Software Forensics Centre Trent Park Campus, Bramley Road, London, N14 4YZ, UK

Eleni Berki University of Jyväskylä Information Technology Research Institute (ITRI) Faculty of Information Technology Mattilanniemi Campus, AGORA Building, Jyväskylä, FIN – 40014, Finland

ABSTRACT Many different paradigms and methodologies have been developed aiming to improve software projects, but no “silver bullet” has been found. The most eminent paradigm to make software development more predictable is Software Process Improvement (SPI), which was inspired from other engineering disciplines. SPI is a worldwide movement, which accentuates a disciplined approach embracing repeatable processes and continuous improvements. The conviction in SPI is that a high-quality process will deliver high-quality products. The main critique against SPI is that it creates a lot of bureaucracy and constrains innovation. The fundamental of Agile Methodologies on the contrary, are flexibility and quick response to requirements changes. No detailed plans are made. Instead changing requirements are considered a necessity to sustain and improve customers’ competitive advantage. In this paper we discuss the main Agile principles with particular reference to eXtreme Programming (XP) and the Dynamic Systems Development Method (DSDM). We identify the relationship between older paradigms and models (such as SPI, CMM and TQM) and Agile Methods, and suggest areas requiring further investigation such as the desirability and feasibility of Agile development in different cultures and for different project types. We conclude with suggestions for further investigation. KEYWORDS Agile methodologies, eXtreme Programming, Software Process Improvement

1. INTRODUCTION The ‘software crisis’ was in 1973 characterised as an inability to develop software on time, on budget, and within requirements [Boehm; Marciniak, 1994]. Research carried out by the Standish Group [1998] provides information on the cost of system errors. The evidence suggests that on average software systems over run by 89% on cost and by 122 % on time. The IPSSI Consortium [2000] stated that only 13% of IT projects are successful. In addition software projects are notoriously behind schedule and over budget [Mullet, 1999].

412

IADIS Virtual Multi Conference on Computer Science and Information Systems 2005

These figures are very alarming and show that the software industry is still many years away from becoming a mature engineering discipline.

2. AGILE METHODOLOGIES COMPARED TO SPI Researchers and practitioners have developed a plethora of lifecycle models, methods, techniques, and tools in attempts to minimise the likelihood of software failures. In applying a methodology to the development of software, insights are gained into the problems under consideration and thus, they can be addressed more systematically. Software should comply with the important quality requirements of timeliness, relevance, accuracy, and cost effectiveness. Process Improvement is seen as a preventative approach as opposed to Product Improvement, which is simply corrective. The main critique against SPI is that it creates a lot of bureaucracy and constrains innovation. It has long been recognised that customisation and flexibility in working methods, as well as customer involvement and user participation are desirable. Agile or Lightweight Methods promise to address these issues. Practitioners, method engineers, software and process engineers want to create their own knowledge-oriented methods; document their own tool environment and design their software development processes (Berki, 2004). Agile methods emphasise requirements management and communication more than any other category of methods. Apart from being a problem in requirements gathering, communication is also the key to making everything happen. Functionalities of complex software can be uncovered with comprehensive requirements analysis techniques and with brave and systematic conversations, unfolding the unknown little by little. (Manninen & Berki, 2004). Some of the popular requirements analysis techniques that support communication and collaboration are, for instance, interviewing, brainstorming and storyboarding. The basic features of Agile methodologies are flexibility and quick response to requirements. No detailed plans are made. Instead changing requirements are considered a necessity to sustain and improve customers’ competitive advantage. Agile methodologies promise effective and successful software development without the cost of a heavy quality system, which requires numerous intermediate work products and rigid standard procedures. Although not named as such, Agile techniques have always been used spontaneously by software developers. The software developer used to be a champion working without noteworthy plans, repeatable processes or large amounts of documentation. As systems grew in size and complexity a chaotic situation appeared characterised as ‘ad hoc’. Because software engineering is a knowledge intensive process, organisations wanted to capture the knowledge of the champions by introducing structured methodologies, standard processes and continuous improvements both of processes and products. SPI has become a practical tool for companies where the quality of the software is of high value [Järvinen, 1994]. The evidence for the emphasis on process is that ISO certification does not certify product quality at all but only that a stated and documented process is followed. Similarly, well-known and recognised capability assessment models like CMM, [Paulk et al. 1995] CMMI [2004], BOOTSTRAP [Haase and Messnarz, 1994, Kuvaja et. al., 1994; Kuvaja, 1999] and SPICE (ISO-15504) [2004] have been developed. These models also assess the maturity of an organisation, and propose improvements based on strong and weak points in the organisation. The results of the process assessment normally lead to greater quality awareness and provide the stimulus for improvement [Ross and Staples, 1995]. The focus in these models is on the assessment of the overall technical capability of an organisation.

3. AGILE METHODOLOGIES COMPARED TO SPI Because of the continuously changing environment, both in technology and customer requirements, the increasing complexity of systems and difficulties in finding solutions to the persisting software crisis there has been a rapidly rising interest in new approaches such as Agile methodologies. Furthermore many companies have adapted, tailored and customised the agile approach to fit their own organisational practices and culture. Below we analyse some of the main features of the Agile Paradigm for systems development.

413

ISBN: 972-8939-00-0 © 2005 IADIS

3.1 Organisational learning – knowledge creation In Agile methodologies the quick response to changing requirements is one of the fundamental features. No detailed plans are made. Instead changing requirements are considered a necessity to sustain and improve customers’ competitive advantage. Because of extensive customer involvement in the development process and the direct interaction between customers and developers there is a more efficient transfer of knowledge. Business people and developers work together daily throughout the project. Communication is achieved through face-to-face conversation. Documentation is kept to a minimum [Agile Manifesto, 2004]. This indicates that knowledge created with Agile methodologies is tacit. Nonaka and Takeuchi [1995] have analysed how organisational knowledge is created. Knowledge is originally produced in the working practice as tacit knowledge. This knowledge is then introduced into organisational use by making it first explicit and then transferred back to the members of organisation. In Agile methodologies this part seems to be missing. Pair-programming, pair-rotation and peer-reviews improve communication; reduce mentoring time and training effort. Thus the learning curve is reduced and knowledge transfer is facilitated [Luong and Chau, 2004]. However, this knowledge seems to remain tacit knowledge.

3.2 Pair-programming The results from a field-study conducted in 15 software companies in Greece using eXtreme Programming (XP) [Sfetsos et. al., 2004] show that one of the success factors was pair-programming. However, difficulties in distribution of programmers and bad relations among staff had a negative effect on pair-programming. Two of the key process areas at level three in CMM address Peer Reviews and intergroup Co-ordination. The similarities between pair-programming and peer-reviews are remarkable. Also Agile methodologies rely on committed and competent software professionals. The commitment required by Agile methodologies also seems to have similarities with the Total Quality Management (TQM), which requires a cultural change by emphasising commitment at all levels in the organisation The successful implementation of TQM methods contributed to Japan’s industrial success especially in quality and reliability. However the emphasis is different between TQM and Agile methodologies. The TQM emphasises process improvements whilst Agile methodologies emphasise flexibility. TQM considers that management commitment and leadership are the driving factors for motivating employees to strive for continuous process improvement [Deming, 1986], whilst the Agile methodologies rely on technically competent software professionals, active involvement of the team and user participation. Empowerment is a common theme in TQM and in Agile Methods. The globalisation of the software market and the increasing use of cross-cultural development teams within multinational companies is likely to create more difficulties with pair-programming.

3.3 Customer involvement The intangible nature of software [Siakas, 2002] and the difficulties of software professionals to capture and understand the business domain and requirements [Rantapuska et. al, 1999] have created the need for cyclic and incremental development with increased user involvement and early versions of software delivery in order to improve software quality. The literature has suggested that higher customer involvement also results in higher quality, especially in terms of meeting requirements. Agile methodologies emphasise user satisfaction through user participation, recognition of and response to continuous changing requirements and frequent delivery of products together with adaptive and iterative software development by self-organising teams that recognise that team-members are competent professionals able to choose and follow an adaptive process. In Agile methodologies continuous access to business expertise is a main feature [Agile Manifesto, 2004]. The field-study carried out by Sfetsos et. al. [2004] also showed that customer involvement increased domain experience. However, customer involvement by on-site customer was difficult in practice and other ways of communication had to be invented. Customer involvement is in general considered a potential regarding customised projects, but in software package-projects the customer is unknown in the stage of software development. In the future this part of the software market is also likely to increase with eBusiness customers who buy off-the-shelf software. The question seems to be if customers are willing to spend the time required by Agile Methodologies in order to train the developers in the business domain or will they in the future request more multi-skilled

414


software developers. In a field-study, where 244 software developers on different levels in four countries, namely Denmark, Finland, Greece and the UK were asked if is it more important to be specialised in a field than to have general knowledge 61.9 % of the respondents considered that it is more important to have general knowledge (to be multi-skilled) [Siakas, 2002]. This may be an indication that our educational curricula in software engineering need to be revised.

3.4 Lack of detailed description of practices One of the principles in Agile methodologies is to document as little as possible. The results from the fieldstudy [Sfetsos et. al., 2004] showed that the lack of detailed description for practices such as simple design, coding standards and metaphor affected negatively the implementation of practices, testing together with communication and synergy starting in the planning game. It seems that the intrinsic motivation is the most dominant reason for the success stories so far. Without systematic working methods the use of Agile methodologies is likely to diminish in the future.

3.5 Software Measurement and Metrics Measurement is inextricably linked with process and product improvement. According to Kitchenham [1996], “Software Metrics can deliver support for process improvement, better project and quality control, and improved software estimation”. Measurement is important for three basic activities, namely to increase understanding of what is happening during software development and maintenance, to control what is happening in projects and to encourage improvement of processes and products [Shepperd, 1995]. Thus metrics are used for processes, products and resources. In order to understand what is happening the current situation has to be assessed, baselines should be established and an understanding of relationship among activities and entities they affect should be communicated. In order to control what is happening in projects the above baseline, goals and understanding of relationships will help to predict what is likely to happen so that changes can be made to processes and products. These changes will help to meet goals and to encourage improvement of processes and products. In Agile methodologies an extensive metrics program is unlikely to be used. In traditional metrics programmes, progress is measured by conformance to plans, which usually are created depending on historical data. Agile methodologies consider that predictability in most cases is impossible and thus we cannot plan in unpredictable situations. The working software itself is considered to be the primary measure of progress, not conformance to plans [Agile manifesto, 2004]. Increased complexity of international organisations and their dependency on people with different underlying norms, values and beliefs, prompt for a softer view including the societal context in IS research and practices in extending the IT/IS boundaries.

3.6 Agile methods, SPI and tools The use of agile tools is not yet supported strongly with agile methods, although changeability and communication of requirements coupled with testing are three fundamental quality properties for requirements management and they need tools to be realised. Furthermore, agile methods should consider the size of the organisation, the project size and its nature, the commercial interests and interaction issues involving end-users and designers. Therefore, Requirements Management (RM) and MetaCASE tools must be utilised in such a way that they capture the organisation’s functions and activities and facilitate the interand intra-organisational communication. Furthermore, adequate requirements elicitation and management requires careful analysis of the work processes and deliverables and their transfer to tool environment. Agile processes and methods and tool support will continue to evolve but new approaches, techniques and tools will also appear. Methodologies like Software Quality Function Deployment (SQFD), XP and other agile methods will be increasingly applied to software projects in the future, not forgetting domain-specific (visual) languages to support domain and product line engineering (Manninen & Berki, 2004). Further research will probably reveal additional factors regarding agile method and tool selection. Distributed and virtual organisations with large multi-site, multi-user projects set a challenge to agile methods.

415

ISBN: 972-8939-00-0 © 2005 IADIS

3.7 Suitability of Agile methodologies in different types of cultures The multidisciplinary character of Information Systems prompts for effective Human Resource Management. However, in Agile methodologies processes imposed by management are by nature resisted. Management and software developers have an equal role in the leadership of projects [Agile manifesto, 2004]. This requires active involvement of all the team and seems to be most suitable in Democratic-type organisations, which have horizontal hierarchy emphasising flexibility and spontaneity. This type of culture generates initiative and responsibility approaches. The leadership style is that of co-ordination and organisation. The organisation has flexible rules and problems are solved by negotiations. Employees are encouraged to make contribution to the decision-making process and to the development of the organisation in general. Democratic organisations can be said to be people-oriented. Examples of countries belonging to the Democratic type are Scandinavia, Anglo-Saxon countries and Jamaica [Siakas, 2002].

4. CONCLUSION Agile Methodologies have evolved from know-how and practice. In essence they are frameworks for systems development. They use mainly Object-Oriented technologies and philosophical and social principles practiced by soft, people-oriented methods and models such as SSM, ETHICS, TQM and SPI. The agility of methods serves as a vehicle for changing the mindset of stakeholders. Consultation, collaborative work, communication and knowledge sharing result in a methodology popular to young competent software professionals, who resist heavy methodologies requiring numerous intermediate work products and rigid standard procedures. The benefits of Agile methodologies for small teams working with rapidly changing requirements is noteworthy. However, the applicability of Agile methods to larger projects is under debate. Investigation, such as the desirability and feasibility of Agile development in different cultures and for different project types, is required. The expansion and use of agile methods and associated technology gave rise to more demanding and changing modelling environments; the computational features of methods; the need for testing, standardisation and integration; abstraction skills to navigate through different modelling levels; realisation of the need for more co-operation and interaction; the need to recognise and cater for diverse cognitive needs of human behaviour and interaction; more expressive modelling through shared work process models and the belief that shared process models must represent agreed views (Berki, 2004). There is a need for a proposal to model processes ‘agilely’ and formally in tool environments. People and methods change; method and knowledge engineers will always need evolutionary, expanding and agile models to capture their thinking patterns and concepts and communicate them to others.

REFERENCES Agile Manifesto, 2004: http://www.agilemanifesto.org/ Berki Eleni, Georgiadou Elli, Sadler Chris, Siakas Kerstin, 1997: A Methodology is as Strong as the User Participation, International Symposium on Software Engineering in Universities - ISSEU 97, Rovaniemi, 7-9 March, pp.36-51 Berki E., 2004: Formal Metamodelling and Agile Method Engineering in MetaCASE and CAME Tool Environments. In the Proceedings of Tigka, K. & Kefalas, P. (Eds), The 1st South-East European Workshop on Formal Methods, SEERC, Thessaloniki Boehm Barry W., 1973: Software and Its Impact: A Quantitative Assessment, Datamation, May 1973 Deming W. Edwards 1986: Out of the Crisis: quality, productivity and competitive position, Massachusetts, USA Georgiadou, 2003: Software Process and Product Improvement: A Historical Perspective, Cybernetics and Systems Analysis, Volume 11, Issue 4, 125-142 Georgiadou Elli, Siakas Kerstin V., Berki Eleni, 2003: Quality Improvement through the Identification of Controllable and Uncontrollable Factors in Software Development, EuroSPI 2003 (European Software Process Improvement Conference), Graz, Austria, 10-12.12.2003, pp. IX 31-45 Haase Volkmar, Messnarz Richard, 1994: Bootstrap: Fine-Tuning Process Assessment, IEEE Software, pp. 25-35, 1994 CMMI 2004: http://www.sei.cmu.edu/cmmi/

416


IPSSI Consortium 2000, PIPSI For Managers - Personal Quality Management Defects, EuroSPI 2000, http:// www.compapp.dcu.ie/ipssi/managers4.pdf Järvinen J., 1994: On comparing process assessment results: BOOTSTRAP and CMM, Software Quality Managemen Conferenc, SQM94, Edinburgh, pp. 247-261 Kitchenham B., 1996: Software Metrics, - Measurement for Software Process Improvement, NCC, Blackwell Kuvaja P., Similä J., Kranik L., Bicego A., Saukkonen S., Koch G., 1994: Software Process Assessment and Improvement – The BOOTSTRAP Approach, Blackwell Publishers, Cambridge, MA Kuvaja Pasi 1999: New Developments in Software Process Improvement Keynote Speech in Software Quality Management Conference (SQM 99): Southampton March 1999 Luong Frank and Chau Thomas, 2004: Knowledge Management in Agile methods sern.ucalgary.ca/courses/SENG/ 609.24/F2002/slides/KM.ppt Manninen, A. & Berki, E., 2004: Coordinating the Quality of Requirements Change and Organisational Communication – An Evaluation Framework for Requirements Management Tools. In the Proceedings of: Edgar-Neville, D. Ross, M. & Staples, G. (Eds) New Approaches to Software Quality. Software Quality Management XII, University of KENT at Canterbury, British Computer Society, Apr. 2004 Marciniak John J. (ed.), 1994: Encyclopaedia of Software Engineering, Software 2000: A view of the future: Eds: Brian Randell, Gill Ringland and Bill Wulf. ICL and the Commission of European Communities, 1994, John Wiley & Sons Mullet Diana, 1999: www.unt.edu/benchmarks/archives/1999/july99/crisis.htm Nonaka I. and Takeuchi H., 1995: The Knowledge-Creating Company – how Japanese Companies Create the Dynamics of Innovation, Oxford Univ. Press, Paulk Mark C., 1995: The Evolution of the SEI’s Capability Maturity Model for Software in Software ProcessImprovement and Practice, Pilot Issue, pp. 3 - 15 Ross M., Staples G., 1995: Maintaining Quality Awareness, 3rd International Conference on Software Quality Management, SQM95, April 1995, Seville, pp. 369 - 375 Shepperd Martin, 1995: Foundation of Software Measurement, Prentice Hall International (UK): Limited 1995 Siakas Kerstin V., 2002: SQM-CODE: Software Quality Management – Cultural and Organisational Diversity Evaluation, PhD Thesis, London Metropolitan University (former University of North London), November 2002 SPICE, 2004: http://www.netcomuk.co.uk/~ksouthwe/RothSouthwell/ISO_15504.htm Standish Group, 1998: http://www.standishgroup.com/visitor/chaos.htm Sfetsos, P., Angelis, L., Stamelos, I., Bleris, 2004: G. Evaluating the Extreme Programming System - An Empirical Study, Fifth International Conference on Extreme Programming and Agile Processes in Software Engineering, Garmisch-Partenkirchen, Germany, June, 2004 Software Crisis, 2004: http://cispom.boisestate.edu/cis310emaxson/softcris.htm

417