Agile software development challenges and solutions: a simple conceptual solution model

Agile software development challenges and solutions: a simple conceptual solution model Peng Chen Master of Science Candidate School of Computer and Information Science, University of South Australia Agile software development methodology has been a new trend and an innovative way to develop software. Many companies want to reap the benefits from the agile approach due to the resultant reduction in development time and cost. However, Waterfall model as a traditional development process has dominated the software industry for a long time. On the other hand, information system users and software users are in favor of lower budgetary products and fast rolled-out deliverables. There are challenges to accommodate agile methods to an organizational inherent development process and infrastructure while scaling the light-weight approach to a large distributed development team. Therefore, this paper aims to find out the challenges and provide solutions for better fitting the agile approach to an organization and satisfying the stakeholders. A generic and simple conceptual model has been created to illustrate the relationships between the main challenge factors, which are agile people, agile documentation and agile scalability. This paper also relates the employability skills to the proposed solutions. A I. INTRODUCTION gile software development approach has been practiced by many practitioners in different paradigms [22], [26]. Each agile development paradigm shares the same agile development principles [22]. These principles encompass close collaboration with customers, informal communication, incremental development, and acceptance to change [21]. Current business environment is dynamically changing and a flexible development process is in high demand to fit the uncertain business changes. Grounded on lack of academic study on agile methods [4], [5], industry experts should concentrate on addressing current issues and challenges of the existing agile methods instead of pursuing new agile methods [4]. As a result, the discussion of this paper is only concerning the general agile methodologies. Agile methods like XP [29], SCRUM [30], Crystal [31], Lean Development [32], originally were adopted by small-sized or middle-sized companies [1]. However, large high-tech global companies adopting agile methods are in increasing [4]. The organization executives have noticed the huge benefits of applying agile model to their organizations while they sill hesitate to use the agile models. The reason is the main characteristics of agile development (such as frequent interaction with users, extensive product release and user feedback, demanding high-level skilled staff, collaborative team work and minimizing documentation) [4], [6], introduce challenges for a large organization to conduct process transformation and change the inherent organizational infrastructure. In the next section a brief comparison between waterfall and agile development methods is introduced. In section 3 a literature review is demonstrated and the challenges to practice agile development are identified on multiple dimensions. Then three significant challenges are chosen for a further discussion in section 4. Based on the discussion, a conceptual solution model is devised in section 5. Section 6 reflects the employability skills on the solutions provided in section 4. The last section is a conclusion of the paper. II. WATERFALL VS. AGILE Traditional waterfall software development life cycle can respond to early problems via detailed planning and adequate system analysis but it is not responsive to customer feedback and requirement change during the whole life cycle [1]. The waterfall life cycle is not iterative and cannot be traced back [2] and it is not cost and time efficient [3]. Establishing extensive planning and clear defined requirements will elongate the development duration and demand more investment. On the contrary, agile methods aim at light-weight, simplicity and speed [4] via rapidly implementing incremental software releases. Agile approach deals with volatile requirements [24]. However, Empirical researches on the comparison of these two methods are minimal regarding measuring cost, duration and quality [23]. A software development methodology or a systems development methodology is not just a development model but also involves documented policy, process, procedure and culture [24]. The deployments of both waterfall and agile development methods therefore have personnel resistance issues [24]. Agile approach requires the acceptance of customers acting as team member besides internal team acceptance, compared with waterfall only requires internal team acceptance [24]. Agile methodology respects people factors, individual activities and short-term change [8], [24]. Agile methodology therefore may be accepted and utilised more easily in an individualism culture [28]. On the contrary, waterfall methodology respects rigid process, detailed

2 specification and long-term plan [24], [27]. Hence, waterfall methodology may be accepted and utilised more easily in a collectivism culture [28]. However, such assumptions are just elicited here and they need further literature review and research works to be proven. III. LITERATURE REVIEW A. Challenges to avoid project failure key contributors Aken (2008) defined the key contributors to project failure from different aspects of software development. Aken implied the causes of project failure, which include unrealized stakeholders expectations, poor methodology utilization and execution, and cost creep in maintenance [7]. This paper examined the project failure key contributors in the following paragraphs so as to elicite the challenges of agile software development process. 1) Iteration time lag The delay between each software development phase will cause the project team to fail on meeting delivery deadlines [7]. Although the project team can benefit from agile iterative development style and frequent user feedback, each of the iterations still will accumulate time lag because of the unsmooth development process. 2) Overreact on changes Ambiguous, unstable, unrealistic project goals and scopes will lead to feature creep [7] and unsatisfactory systems for users. Changing project goal and scope is common in software development and agile methodology welcomes changes, but without a constant goal as a guide [7], the agile development model tends to overreact on changes and overlook the project goal. 3) Insufficient requirement analysis Early and fast software development output is not always a good sign for the project because it often implies insufficient requirement analysis [7]. However, agile model produces short and intense deliverables with minimal requirement analysis [1]. Hence employing an agile approach somehow hampers project teams to conduct a comprehensive system analysis. 4) Hard to realize distributed development Lack of effective stakeholder involvement is the key deficiency in many failed projects. Agile developers work closely with only a small group of users. As a result, the development team will easily neglect other user inputs. Moreover, due to the nature of close user involvement in agile, it is difficult to realize distributed development [7]. 5) Active response introduces scope creep An agile approach is actively responsive to requirement change. It encourages reworking the code to adjust the changes rather than preventing them [7]. Therefore without an awareness of the consequence agile model can introduce scope creep. 6) Require skilled resources When reflecting on the causes of project failure, many organizations usually omit the fact that crucial experts leaving the project and lack of skilled developers can damage a project. Agile development prefers highly skilled resources [7]. Hence agile will not easily fit in an organization with employees at all skill levels. It is also hard to hire and maintain high-level resources. 7) Hard to fit big project Light system analysis and design destine large projects to failure. Agile is a lightweight approach [1]. It advocates close team collaboration [7]. Teamwork is vital for agile project success. A small team can exaggerate the benefits of agile methods. Grounded on that, it is hard to scale agile process to fit a large project. B. Agile migration challenges Via contrasting agile and traditional software development, Nerur, Mahapatra & Mangalaraj (2005) summarized four major issues for an organization employing an agile approach for software development from organizational and managerial angles. The four major issues relate to organizational management, people, process and technology [8]. Their paper is valuable for an organization who attempts to migrate to agile methodologies. In the following paragraphs this paper verifies the challenges of agile methodology migration through linking to the characteristics of traditional methodology. 1) Agile methodologies change organization fundamental values Many organizations have been applying traditional methodology to develop software for many years. The organization culture, management style and policies have been influenced by the traditional process. The traditional project teams rely on comprehensive documentation for knowledge sharing. It is difficult to change the mindset of the people who have adapted to the traditional process. Conversely, agile methodology advocates a collaborative management style and less documentation compared to a traditional controlling management style with detailed documentation [8]. This is not just simply to substitute one model with another. The challenge of adopting agile approach is to change the whole fundamental values of the organization. 2) High demand on skilled personnel and pluralistic decision-making In traditional software life cycle, analysis, design, development and test phases are implemented separately by different groups. Because of good documentation, traditional approaches allow each group to have staff at different skill levels. Good documentation eliminates decision-making conflict whereas the agile approach introduces pluralistic decision-making [8]. It also requires the staff to possess

3 comprehensive skills [8] for pair programming and interaction with different stakeholders. The organization faces the challenges to recruit enough competent agile staff and to consolidate the decisions from different parties. 3) Big investment on process change It is a huge movement for an organization to choose a proper agile method to fit its product and convert its traditional process to agile process. This change movement requires a big monetary investment [8]. Furthermore, management should prepare to tolerate a potential capital lost during the process change [8] because the change will likely reduce the productivity rather than generating additional benefits. The management also should prepare to afford adequate time for the people to learn new tools for engaging the agile development process. 4) Difficulty in disseminating agile tools The designed agile tools do not ensure agile approach dissemination in an organization. The challenge is how to familiarize people with the agile tools and utilize them in order to follow agile development process. C. Architectural challenges Babar (2009) conducted an empirical study on architectural practices and identified architectural challenges in using agile approach. Babar indicated there were concerns on whether agile approach could follow architectural practices and whether the substantial amount of software architectural work was necessary. However, Babar believed it was feasible to integrate the software architectural work into agile development via understanding the architecture-related challenges and strategies [9]. Four architectural challenges are identified by Babar [9]: Agile User Stories are incorrectly prioritized without considering technical design and interdependency between design decisions. Due to limited time and budget, the agile team only focuses on achieving software features but miss out a better proper design. It is hard for an agile team to work with new clients and with unknown domain if there are no proven architectural solutions. Lack of quality attributes consideration on design will result unsatisfactory architectural structure and more cost and time needed in maintenance phase. D. Management challenges In a traditional development organization, managers are facing several barriers in using agile approaches for their management practices. Boehm and Turner (2005) perceptually identified three areas that challenge software managers to manage agile development. The three areas are development process conflicts, business process conflicts and people conflicts [10]. In terms of development process conflicts, these conflicts occur when merging agile process with years defined software engineering process. The development process conflicts include: 1) variability in assumptions, interface definition and team synchronization; 2) different life cycles; 3) maintenance or new development for a legacy system during agile process; 4) function-oriented and informal agile requirement against software engineering verification and validation approach [10]. In terms of business process conflicts, these conflicts exhibit the expectation conflict between near-perfect predictions and short-term results. The business process conflicts include: 1) human resources procurement process change; 2) agile approach has completely different process measurements rather than earn-valued processes; 3) inadequate agile documentation affects process standard ratings and software maturity [10]. In terms of people conflicts, people issues are critical for software engineering management and are the center for agile process. The people conflicts include: 1) managers adjust their management attitudes and styles to applying agile methods; 2) logistical issues on resources location, pairing programming and information sharing; 3) how to handle successful agile project pilots and avoid negative impacts on the pilot team; 4) agile change management requires teamwork and user involvement [10]. E. Governance challenges It has been stated by Lehto and Rautiainen (2009), that backlogs are described as essential components in the agile process. The backlogs can be rolled up to the high-level roadmap and be decomposed to the low-level daily tasks [5]. In their study, agile software development governance is performed through managing backlogs in different organizational levels. They defined different management roles and responsibilities in the top-down agile product planning and development framework [5]. The more responsibilities a manager takes, the higher level backlogs he or she manages. They observed the challenges in communication and the challenges in roles and responsibilities. There are two challenges in communication: 1) lack of communication between product owners and teams will introduce schedule collision and task collision; 2) lack of feedback loops will introduce incorrect estimation and information inconsistency [5]. There are three challenges in roles and responsibilities: 1) structuring teams based on skill set will result coordination overheads and neglect task priority; 2) in a large company, the existing different product owner roles will result in communication and team reporting anarchy; 3) lack of business theme priorities will result in parallel development [5].

4 F. The three key challenges for Agile Agile software development can help a company lower its product development cost and time. Grounded on the literature above, this paper summarized three key challenges that hurdle organizations to apply agile approach for accelerating the profit-earned cycle. These three key challenges are: How to make good documentation but still be agile? How to make an agile team with personnel at different skill levels? How to scale an agile approach to a big organization? In this paper, agile documentation, agile people and agile scalability are believed as the key challenges of using agile approach. The following discussion will provide solutions to tackle these challenges. The solutions are not specific to a particular agile approach. They can be applied to all the current agile methods. IV. DISCUSSION A. How to make good documentation but still be agile? Documentation is a means for team members to communicate to each other. Good documentation improves team communication during project development. Documentation aims at documenting the system design and knowledge for those who are not familiar with the system. It also helps the senior developers avoid having to repeat the system knowledge to every new developer over and over again [11]. The original staff who designed the system can understand the system very well whereas without proper documentation their successors will encounter difficulties to understand the system [11]. Moreover, it will cost an organization a large amount of money to maintain the system. The fundamentals that have helped software engineering in a long history should not be discarded. Hence, Practitioners should continue to make use of the fundamental principles like documentation while adopting the current agile approaches [11]. Using Unified Modeling Language (UML) tool with limited coding can help less documentation [12]. The graphs and diagrams make system design visible and easy to be understood [13]. This paper suggests agile practitioners use design rationale for assisting agile documentation [11], [14]. Each user story needs lesson learned documentation and several essential reports [10]. Following coding standards [15] and ensuring annotation in code can enhance code readability. Moreover, code review should include reviewing the annotation as well. During daily stand-up meetings [16] project team members share and discuss mistakes while recording a meeting minute. A meeting minute includes current status, risks, lessons learned [12] and an action plan. In a distributed development team environment, effective documentation facilitates communication between distributed teams. People argued code is the true documentation. But in the software industry no one is pleased to revisit the legacy code in an old system [11] without supported documents. The business logic inherent in the code is hard to be understood. B. How to make an agile team with different levels of personnel? To manage collaboration with users, agile developers not only can communicate technology terms but also can communicate business terms to the users [17]. Traditional software developers only focusing on coding are not suitable for agile development method. The waterfall method allows senior and junior developers working in the project, but agile method prefers hiring competent personnel [9], [10]. As to lower agile human resource cost, project managers need to figure out a way to employ different level staff but still perform well in an agile development team. User and executive support [12], [17], [18] play an important role on repairing the inadequacy of competent staff. Creating a collaborative and interactive team environment will encourage knowledge transparency and rapid knowledge sharing [16]. Knowledge management is a way to lower human resource cost. An experienced developer can pair with an inexperienced developer for pair programming while forming a mentorship. Mentorship helps build the competency quickly. So it is a good practice to make sure each member pairs up with a different partner to promote knowledge flow in a circle [19]. Pair programming helps facilitate knowledge transfer [19]. This paper does not agree with the idea that people trump process as mentioned in reference [17] even though agile has an emphasis on self management and organization. The author of this paper believes reasonable process and policies serve as a compass to group and lead people to the same goal. Resource pool is a strategy to reserve talents when a project is closed. It also acts as a supplement when a project is expanding or a new project starts [19]. Moving resources from project to project stably from time to time can accelerate knowledge transfer among projects [19]. This strategy reduces the risks attributed to the absence of key persons or the demand of new resources. C. How to scale an agile approach to a big organization? When an agile approach does not work in certain domains a fundamental change is needed if an organization determines to employ an agile approach [17]. Instead of applying agile methods to all projects in an organization at once, it has been suggested to launch a pilot agile project for a test [10], [12]. Eventually a successful result will prove the feasibility of scaling agile approach to the whole organization. The pilot project must be ambitious, big sized and with enough stakeholder support otherwise a small pilot project success will be unconvinced and unnoticeable [10], [18]. A successful pilot project sets an example in the organization to be followed [10],

5 [12]. Cutting down the heaviness in software development is one welcomed benefit from agile methodologies. However, it requires the organization to invest money on testing, building and deploying automation. Automation tools reduce massive manual tasks and show productivity [18]. Therefore, agile automation will attract developers who propone rigid traditional development methods to start using agile methods. Development and test teams can work parallel for each user story [18]. Early test preparation or even early code testing can eliminate risks, enhance code quality and reduce maintenance cost. Additionally, one code branch enforces communications between developers for their current changes on the same code. It also keeps code consistency because only one version of the code should be allowed [12], [18]. Version control tools like Concurrent Versions System (CVS) are recommended to support the idea of one code branch management [12]. There is no fast-forward to promote agile development process to an organization. This paper suggests the organization to employ agile approach project by project, building the automation tools one by one, evolving a development infrastructure one component at a time. With each successful change people s traditional development mindset will be gradually overcome by the agile method. Many big organizations have setup their affiliates in different countries and sometimes their clients are also international companies. When applying an agile development model across a multinational organization, global development introduces challenges to realize responsive communication, less requirement documentation and extensive teamwork [6]. Global software development (GSD) has been an irreversible trend for a company to expand its business globally and to seek lower-cost resources. However, GSD is facing multiple issues. They include strategic issues, cultural issues, inadequate communication, knowledge management issues, project and process management issues and technical issues [20]. The GSD issues can be addressed via controlling process, knowledge sharing, communication and building trust between distributed teams [10]. There are seven solutions organizations can apply to manage the GSD issues. Firstly, regarding process control, minimal documentation facilitates requirement distribution and the first two or three iterations quality is vital to meet user requirement and to build a solid foundation [12]. Secondly, a bug tracking system is used to report development issues and all global teams should use the same system to share information. Thirdly, the distributed teams are encouraged to work on well documented functionalities rather than critical new functionalities [6]. Fourthly, early morning meetings with the onshore team and late shifts for offshore team can synchronize the working hours [6]. Fifthly, using video conference call and instant message tools can overcome distant communication barriers and build trust between distributed teams. Sixthly, in terms of building trust between teams, it is encouraged to arrange short term visits between teams located in different regions and forge opportunity for them sitting together [6]. Finally, although reference [6] does not favor the 24x7 development model, the author of this paper believes the 24x7 development model can make use of the time difference and reduce the opportunity that developers work in odd hours. In addition, these solutions can promote morale in teams. V. A CONCEPTUAL SOLUTION MODEL As the discussion above all the proposed solutions have been surrounding people, documentation and scalability these elements. These are the three main challenges which have been identified while they can also be considered as the key factors for the solutions of agile development problems. This paper aims at simplifying the way to overcome the challenges via focusing on the most influential elements in agile software development. Through the literature review and discussion a conceptual model is devised as Figure 1, which illustrates the relationships between each factor. Agile People Employability Skills Agile Documentation Agile Scalability Figure 1: Agile conceptual solution model This agile conceptual solution model comprises the three basic factors. They are agile people, agile documentation and agile scalability. As shown with double arrows, agile people and agile documentation interacts with each other. Good documentation with essential information and in minimal time facilitates the communications between engineers, knowledge sharing and knowledge preservation [11], [33], [36]. As a result, their employability skills [36] are improved and they can be easily deployed to different agile projects as well. On the other hand, agile people with adequate employability skills can accept documentation easily and compose succinct but informative documentation [35]. Meanwhile, agile people and agile documentation both contribute to the scalability of agile development approach to a large organization. People and documentation both are the intellectual assets [34] for a company. If an executive intends to scale a new agile approach to all projects and to a whole organization, skillful personnel are

6 the first thing to look for. Secondly, the executive will consider whether the company has enough knowledge base to educate the personnel for adopting the agile approach and enough documentation to revisit the systems and previous errors [33]. Agile people, agile documentation and agile scalability are believed as the main factors to be examined while an agile development challenge occurs. It will be difficult to identify all the challenges in adopting agile development process within a volatile business environment. This model is considered as a generic solution which can be applied to all kinds of challenges via focusing on the core factors. Simplicity is emphasized in the agile development methodology [25] thus the solution of its challenges is expected to be simple. VI. EMPLOYABILITY SKILLS Agile development methodology represents all aspects of the employability skills [36] including communication, team work, problem solving, initiative and enterprise, self management, learning and technology. Based on the discussion of how to solve the agile challenges, agile staff are required to improve all the employability skills to make agile project a success. 1) Communication During agile development, developers are asked not only to perform pair programming but also to work with users and respond to their feedbacks. In the context, good communication skills are a must for developers to express business and technical information correctly. It could be an advantage for someone who can speak at least one foreign language while working in a global distributed development team. 2) Team work Team work and collaboration is a key factor for agile project success. Mentorship in pair programming, decision-making, using the same bug-tracking system, knowledge transfer, and 24x7 development model all require effective team work. 3) Problem solving In terms of problem solving, this paper is a good example to demonstrate this skill. This paper identified the challenges of using agile approach, analyzed the causes and provided the solutions. With respect to agile development itself, high problem solving skill determines a quick response to user s change requirements. because agile process is a people-centric process. Each agile team member should be able to manage themselves and acquire the business knowledge from users while change requirements occur, and maintain a minimal documentation. 6) Learning and technology Concerning learning and technology employability skills, using automation tools can eliminate repetitive manual tasks and improve efficiency. Rotating personnel among projects from time to time will facilitate knowledge sharing and individual learning. VII. CONCLUSION There is no robotic mechanism on how to exercise agile approaches in an organization. However, this paper can help the IT industry recognize the current challenges in adopting agile development process within the context of global economic environment. This paper also gives possible solutions for the defined key challenges, including agile documentation, agile people and agile scalability. It is recommended to use the suggested solutions as hints and tailor the existing agile methods to fit individual organization based on different situations. In this paper, documentation, people and scalability are considered as three significant challenges to promote agile model across the software industry. Documentation is inevitable during software development life cycle. This paper suggests effective documentation with proper tools and mechanism is essential for the agile model to succeed. People are the key to produce working system and to make the agile process work. Instead of investing money and time on searching experts for agile development projects, this paper advocates resources reservation plan, knowledge transfer and mentorship. In comparison with the traditional software development model, this paper predicts the agile model will eventually excel other models via enhancing its scalability. An agile conceptual solution model is created to link people, documentation and scalability together so as to provide a generic model for agile development challenges. The limitation of this paper is that the application of the model is not provided in this paper. Further research needs to be conducted in regards to the application of the model by practitioners. However, the author of this paper believes that the managers or practitioner will embrace this model due to its simplicity. It is hoped that this conceptual model can attract academic attention and stimulate scholarly debate. 4) Initiative and enterprise Regarding initiative and enterprise, the executive of an organization need to have a long term strategy of agile process migration and to tolerate a temporary capital lost when building the process infrastructure. The development team should be able to adapt themselves to the new process change via learning new skills with strong motivation. 5) Self management Self management is one attribute of agile development

7 REFERENCES [1] V. Guntamukkala, H. J. Wen, and J. M. Tarn, An empirical study of selecting software development life cycle models, Human Systems Management., vol. 25, pp. 265 278, 2006. [2] O. Benediktsson, D. Dalcher, and H. Thorbergsson, Comparison of software development life cycles: a multiproject experiment, IEE Proceedings Software, vol. 153, no. 3, pp. 87 101, Jun. 2006. [3] M. F. F. A. Nasution and H. R. Weistroffer, Documentation in systems development: a significant criterion for project success, in Proceedings of the 42 nd Hawaii International Conference on System Science 2009, Big Island, pp. 1 9. [4] P. Abrahamsson, J. Warsta, M. T. Siponen, and J. Ronkainen, New directions on agile methods: a comparative analysis, in Proceedings of the 25 th International Conference on software Engineering, May. 2003. [5] I. Lehto and K. Rautiainen Software development governance challenges of a middle-sized company in agile transition, in Software Development Governance 2009, Vancouver, pp. 36 39. [6] B. Ramesh, L. Cao, K. Mohan, and P. Xu, Can distributed software development be agile? Communications of the ACM, vol. 49, no. 10, pp. 41 46, Oct. 2006. [7] A. Aken, CHUNK: An agile approach to the software development life cycle, Journal of Internet Commerce, vol. 7, no. 3, pp. 313 338, 2008. [8] S. Nerur, R. Mahapatra, and G. Mangalaraj, Challenges of migrating to agile methodologies, Communications of the ACM, vol. 48, no. 5, pp. 73 78, May. 2005. [9] M. A. Babar, An exploratory study of architectural practices and challenges in using agile software development approaches, in Software Architecture, 2009 & European Conference on Software Architecture, pp. 81 90. [10] B. Boehm and R. Turner, Management challenges to implementing agile processes in traditional development organizations, IEEE Software, vol. 22, no. 5, pp. 30 39, 2005. [11] B. Selic, Agile documentation, anyone? IEEE Software, vol. 26, no. 6, pp. 11 12, 2009. [12] H. Lei, M. Claus, R. Rammage, C.D. Baer, R. Decool, J.M. Kniss, S. Clyde, D. Cooley & D. Liu, Software s Eight Essentials, in Proceedings of the 2009 International Conference on New Trends in Information and Service Science, Beijing, 2009, pp. 1203 8. [13] S. Gillard, Managing IT projects: communication pitfalls and bridges, Journal of Information Science, vol. 31, no. 1, pp. 37 43, 2005. [14] T. Sauer, Using design rationales for agile documentation, in Proceedings of the Twelfth IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, 2003, pp. 326 331. [15] B. Fitzgerald, G. Hartnett & K. Conboy, Customising agile methods to software practices at Intel Shannon, European Journal of Information Systems, vol. 15, no. 2, pp. 200 213, 2006. [16] M. Levy & O. Hazzan, Knowledge management in practice: The case of agile software development, in Cooperative and Human Aspect on Software Engineering 2009, Vancouver, 2009, pp. 60 65. [17] A. Cockburn and J Highsmith, Agile software development: the people factor, Computer, vol. 34, no. 11 pp. 131 133, Nov. 2001. [18] D. Goodman and Michael Elbaz, `It s not the pants, it s the people in the pants` learning from the gap agile transformation what worked, how we did it, and what still puzzles us, in Agile 2008 Conference, Toronto, pp. 112 115. [19] C. J. Goebel, How being agile changed our human resources policies, in Agile Conference, 2009, Chicago, pp. 101 106. [20] J. D. Herbsleb and D. Moitra, Global Software Development, IEEE Software, vol. 18, no. 2, pp. 16 20, 2001. [21] M. Fowler and J. Highsmith, The agile manifesto, Software Development, vol. 9, no. 8, pp. 28 35, 2001. [22] S. C. Misra, V. Kumar and Uma Kumar, Identifying some important success factors in adopting agile software development practices, The journal of Systems and Software, vol. 8, no. 2, pp. 1869 1890, 2009. [23] S. M. Mitchell and C. B. Seaman, A Comparison of Software Cost, Duration, and Quality for Waterfall vs. Iterative and Incremental Development: A Systematic Review, 2009 3rd International Symposium on Empirical Software Engineering and Measurement (ESEM), pp.511-515, 15-16 Oct. 2009. [24] F. K. Y Chan and J. Y. L. Thong, Acceptance of agile methodologies: A critical review and conceptual framework, Decision Support Systems, vol. 46, no. 4, pp. 803 814, 2009. [25] L. Lindstrom and R. Jeffries, Extreme programming and agile software development methodologies, Information Systems Management, vol. 21 no. 3, pp. 41 60, 2004. [26] T. Dyba and T Dingsoyr, Empirical studies of agile software development: A systematic review, Information and Software Technology, vol. 50, no. 9-10, pp. 833-859, August 2008. [27] B. Boehm, Get ready for agile methods, with care, IEEE Computer, vol. 35, no. 1, pp. 64 69, 2002. [28] S. P. Robbins, Organisational behaviour, 5th ed. Pearson Education Australia, Frenchs Forest, N.S.W., 2008. [29] K. Beck, Extreme Programming Explained: Embrace Change, Addi-son-Wesley, 2000. [30] K. Schwaber, M. Beedle, Agile Software Development with Scrum, Prentice Hall, Upper Saddle River, 2001. [31] A. Cockburn, Crystal Clear: A Human-Powered Methodology for Small Teams, Addison-Wesley, 2004. [32] M. Poppendieck, T. Poppendieck, Lean Software Development An Agile Toolkit for Software Development Managers, Addison-Wesley, Boston, 2003. [33] M. F. F. Nasution and H. R. Weistroffer, Documentation in Systems Development: A Significant Criterion for Project Success, 2009 42nd Hawaii International Conference on System Sciences, pp.1-9, 5-8 Jan. 2009. [34] A. Chandani, B. Neeraja, and Sreedevi, Knowledge Management: An overview & its impact on software industry, 2007. ICTES. IET-UK International Conference on Information and Communication Technology in Electrical Sciences, pp.1063-1068, 20-22 Dec. 2007. [35] K. Kitagawa, The Employability Skills Profile, seven years on, Orbit, vol. 31, no. 2, pp. 12-15, 2000. [36] R. Mcquaid and C. Lindsay, The Concept of Employability, Urban Studies, vol. 42, no. 2, pp. 197-219, 2005.