AGILE PROJECT MANAGEMENT – OFFSHORE AGILE 1. ABSTRACT Agile is an iterative and evolutionary approach to software development implemented through a set of practices and principles. It focuses primarily on developing software with high collaboration between various individuals and with customer, “just enough” documentation and frequently delivering working software in order to make the process more responsive to changes. Off-shoring software development enables organizations to leverage wealth of skill and talent available at a much lower rate thereby making them more cost effective. In an attempt to leverage the benefits of off-shoring as well as Agile, we have practiced the hybrid “Offshore Agile” model yielding good results. This paper describes the challenges faced and best practices established during software development using offshore Agile. 2. CHALLENGES IN IMPLEMENTING OFFSHORE AGILE Implementing Agile in offshore-onshore development model throws up many challenges. This section describes significant challenges experienced while implementing offshore Agile. 2.1 Cultural Incompatibility Cultural incompatibility is one of the biggest stumbling blocks one could face while implementing offshore Agile. 2.1.1 Inertia from traditional software development methodologies Traditionally most of the Indian software companies are extremely process oriented and every single work item is planned well in advance. Development team, Project Managers and Senior Management track progress vis-à-vis the plan. Deviations are closely monitored and corrective actions are taken to bring the project back on track as per the plan. Change Control is also an integral process. Changing requirements are tracked using baselined requirements as reference. Agile does not advocate use of such traditional procedures. Project planning far in advance is not advisable. Changing requirements are always welcome and do not need to go through an elaborate change control process. Making the development team adapt to a complete shift in processes is a big challenge. 2.1.2 Cross Cultural Issues Most of the Indian software companies operate at a junior programmer level. In such a model, most of the architectural/design decisions are taken at a senior level. Developers are mainly responsible for developing code based on the design/architecture laid out. Issues and questions are generally addressed in a hierarchical fashion. Agile advocates active participation from the entire development team irrespective of their seniority. Queries and issues are raised and discussed in an open forum. It is a challenge to break the command-control mindset of the team and have them actively participate in all discussions without any hesitation. 2.2 Communication Communication is one of the most fundamental principles of Agile development. Any practice that distracts from effective communication must be removed from the process. On the contrary, any practice that enhances the process must be embraced. AGILE PROJECT MANAGEMENT – OFFSHORE AGILE 2.2.1 Absence of enough face-to-face communication Agile advocates high collaboration between all members of the development team and customer. This includes face-to-face communication for effective resolution of issues/queries. In an offshore development model, such high collaboration may not be feasible because the team is spread across various geographies and time zones. One of the key offshore Agile challenges is to identify alternatives to achieve the same level of effectiveness. 2.2.2 Incorporating Dynamic Requirements In conventional development methodologies, baselined requirement is the most important artifact to start development. Its importance is even more pronounced in an offshore development model due to the associated communication overheads. Agile methodology embraces changing requirements as it makes the product more acceptable in the market. Incorporating dynamic requirements in an Offshore Agile model is a challenge. 2.2.3 Always maintain “working software” Generally, conventional delivery is based on milestones. Working software is delivered at the end of each milestone. One of the Agile principles is to have working software available at any point of time. Development is iterative. Typically, iteration is 2-3 weeks long. Synchronizing the team to maintain working software is challenging in an environment where requirements are dynamic, project size is large and iterations are short. 2.2.4 Managing continuous review, feedback and acceptance process Iteration covers all phases of software development – Analysis, design, coding and testing. In addition to these, acceptance/review process of previous iteration is also carried out in parallel. Incorporating review/acceptance comments along with the tasks identified for the current iteration is a challenge. 2.3 Project Management Irrespective of the methodology being used (Conventional or Agile); effective project management is the key to success. Managing Agile projects has its own challenges. Some key Agile project management challenges, which we experienced, are mentioned below. 2.3.1 Project Visibility and Tracking In conventional methodology, detailed project plan is the most commonly used tool to track project status. Detailed tasks are outlined and resource allocations are done in the initial phase of the project. In Agile, project status is tracked by working software rather than tasks accomplished during a specific time period using a comprehensive project plan. The major challenge is that there is not much visibility on the low level tasks to be accomplished in the future. Tracking becomes difficult because different phases are carried out in parallel. 2.3.2 Planning and estimation In conventional methodology, estimations are done using well-established techniques like Function Point Analysis, Use Case Points etc. in the beginning of the project. In Agile, estimates are built by rolling up the aggregate estimates on a set of features. Rough magnitude of estimation is done in the beginning of each iteration and refined as the iteration progresses. Since estimates evolve as the work progresses, project planning is a challenge. AGILE PROJECT MANAGEMENT – OFFSHORE AGILE 2.3.3 Need of highly self motivated technical people Typically a project team has a mix of people with varying skill sets and competencies. Project Manager appropriately utilizes all resources based on their competencies. Agile advocates on executing projects only with highly self-motivated and technically strong people. It is a challenge to identify and also retain such highly self-motivated and technically strong people. 2.3.4 Aligning with conventional Quality Assurance processes Most of the Indian software companies are highly process oriented and follow conventional quality assurance processes and practices. Agile philosophy is people oriented and gives less emphasis to well defined processes. It believes in “just enough” documentation and supports only those processes, which helps in doing the tasks faster and more efficiently. The challenge is to align the Agile practices with organization’s well-established quality processes and strike a fine balance between these two to optimize benefits. AGILE PROJECT MANAGEMENT – OFFSHORE AGILE 3. BEST PRACTICES Agile methodology is based on the following key 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 It advocates continuously applying and evolving best practices around these principles. This section describes best practices being followed at CSC India for implementing Offshore Agile. These practices have been evolved based on the challenges posed by Offshore Agile. 3.1 Communication 3.1.1 Knowledge sharing in offshore-onshore work model Most of the development work is being done from offshore. Only around 15% of resources at onsite ensure that all the Business/Technical queries are resolved and are turned around quickly to the offshore team. Onshore Team is involved in resolving high critical issues. Also, they are involved in deployment, representing team in any meetings with other onshore teams. They basically act as interface with the BA’s and other customers. Onshore team coordinates with offshore team by having daily knowledge sharing meetings during night times with some time overlap. Onshore team is homogeneously rotated every three months for effective knowledge sharing and onshore exposure to all team members. This also provides an equal opportunity for the development team to personally interact with the customers. People returning from onshore actively share their experiences and knowledge gained with the offshore team. This also helps in eliminating cross-cultural divides. 3.1.2 Multiple Communication Channels Seamless communication is critical for the success of Offshore Agile. Personalized communication might not be possible at all times. Hence it is important to have alternate communication channels including asynchronous communication. Following communication channels have proved effective: Conference Calls, Instant Messengers, Web Meetings, Video Conference, White boarding and asynchronous communication – WIKI. WIKI is an Intranet based central repository to store artifacts, share common information and host forums for asynchronous discussions. It is cost effective, works well because they are simple to use, can be worked with any browser, and are simple to set up. AGILE PROJECT MANAGEMENT – OFFSHORE AGILE Fig 1: Asynchronous Communication using WIKI 3.2 Planning & Review 3.2.1 Roadmap As a starting point, feature analysis of the desired system is carried out. All required features are listed, prioritized and grouped into high-level “User Stories”. User Stories are high level system needs. Based on their priority, user stories are grouped into iterations and project roadmap is created. Project roadmap acts as a high level plan to execute the project. In the road map, complex user stories are planned in the initial iterations and simpler ones later, to minimize risk and maximize reusability. Fig 2: Product User Story Roadmap AGILE PROJECT MANAGEMENT – OFFSHORE AGILE 3.2.2 Iterative development model – Two-week iterations Iterative development attempts to minimize risk by developing software in short iterations. Fig 3: Agile Methodology Schema Iteration is like a miniature software project of its own, and includes all of the tasks necessary to release the mini- increment of new functionality: planning, requirements analysis, design, coding and testing. At the beginning of each iteration, its functional requirements in the form of user stories are elaborated using simulation tools like iRise. While iteration may not add enough functionality to warrant releasing the product, an Agile software project intends to be capable of releasing new software after every iteration. At the end of iteration, the team reevaluates project priorities. Optimum results were obtained with short iteration spanning for two weeks. The basic idea behind iterative development is to develop a software system incrementally, allowing the developer to take advantage of what was being learned during the development of earlier, incremental, deliverable versions of the system. Learning comes from both the development and use of the system, wherever possible. At each iteration, design modifications maybe made and new functional capabilities are added. 3.2.3 Iteration Planning Meetings At the beginning of each Iteration, delivery team meets to identify and plan delivery and support tasks in order to successfully deliver the planned user stories. Typically, planning meetings are structured to cover the following: • Review goals accomplished from the previous Iteration. • Review goals planned for the current Iteration and slate goals that the delivery team will address. • Identify new delivery tasks that must be accomplished in order to successfully deliver the current Iteration. • Identify new support tasks that should be accomplished to successfully deliver future Iterations. • Review practices being used and modify based on the lessons learnt during the iteration. • Query resolution (Business/Technical) AGILE PROJECT MANAGEMENT – OFFSHORE AGILE 3.2.4 Regular Meetings Regular synch up meetings are held for the entire team where all queries, issues, status of tasks and plans are discussed. These meetings help in synchronizing various activity groups. Weekly status review meetings are held between the development team and customer to review task progress, query resolution and identify/mitigate risks. 3.2.5 Workload Management Workload Management is carried out by the team and enabled by the project manager. Self-organizing, self- disciplined teams need to manage their own workload in order to maintain their accountability. Project manager monitors their effectiveness and assists them by providing resources required to meet the team's assumptions made while planning iterations. One task owner and support team member(s) is identified to accomplish each task planned in the iteration. As the task progresses, owner provides updates on the respective task. Everyone in the delivery team must either own or support a task. 3.3 Automated Development Process 3.3.1 Test Driven Development Test-driven development encourages developers to write unit test cases before writing the code. In conventional software development, people write code and test the application to validate developed code. In test driven development, test case acts as a specification to write code. The test case is considered to be the acceptance criteria. This also helps developers understand the specifications or requirements. 3.3.2 Continuous Integration, Test and Build Delivery team continuously delivers code into the code repository, integrates code and builds the entire system as and when a logical end is reached. The value of continuous integration is that it brings up integration issues immediately, instead of deferring them till the end of the project. Every time a significant code is delivered into repository, build verification tests (unit tests) as well as functional tests are executed. When a test fails, the build fails. Responsibility of fixing it lies with the developer who broke it. In this way configuration management of offshore development becomes almost a non-issue and we always have a “Working Software”. AGILE PROJECT MANAGEMENT – OFFSHORE AGILE Fig 4: Iterative Agile Development Model 3.3.3 Automation – Code Generation, Code Quality Review, Build, Deployment & Testing Code generation scripts are used to generate code skeletons automatically. This helps in adherence to architectural standards, minimizing the efforts required in coding and allows time to incorporate changing requirements. To automate the code quality review process, tools like Metrics for code complexity, CheckStyle for style checks and coding standards, PMD for coding practices, Profiler for code profiling, JDepend for code inter- dependency analysis, Clover to measure test coverage, are integrated with development and build environment. These tools generate code quality reports so that code quality can be monitored and achieved. Fig 5: Code Quality Report using Metrics AGILE PROJECT MANAGEMENT – OFFSHORE AGILE Open source tools like Maven, Continuum, and Cruise control are used to facilitate automatic build, deployment and test cases execution on regular intervals. These tools are integrated with configuration management tool i.e. Subversion. These tools provide web interface to report latest build status, build history, reasons for failure and code changes etc. Fig 6: Build Report using Continuum Integrating test cases with build scripts ensures automated regression testing after each build. 3.4 Continuous Improvement 3.4.1 Regular Practice Review At the end of each iteration, delivery team reviews the practices identified for that cycle and evaluates whether or not the practice was applied effectively/efficiently. All practices are listed and assigned a practice owner. If the practice is a hindrance or the practice has no positive impact, delivery team should contact the practice owner to have it removed from the list of practices. If the delivery team identifies improvements to the practice, the practices list is to be updated accordingly. 3.4.2 Opportunistic Refactoring Refactoring is the process of changing code for increasing flexibility, understandability and reducing maintenance costs without affecting external behavior. In scenarios where adding new behavior to a program might be difficult with the program's given structure, developer refactors code to make it flexible and then adds new behavior. 3.4.3 Knowledge Management using Tools Knowledge management refers to ways organizations gather, manage, and use the knowledge that they acquire. Knowledge management plays a key role in information sharing, planning & continuous improvement in Offshore Agile implementation. AGILE PROJECT MANAGEMENT – OFFSHORE AGILE A central repository is maintained to keep all the documents or artifacts related to the project. All the stakeholders can refer the repository for any document. Fig 7: Knowledge Management using Protégé 3.5 Project Management Project Management artifacts (Status report, task list, task assignment etc.) are generated automatically using project & knowledge management tool – Protégé. Fig 8: Project Management using Protégé 3.5.1 Quality Metrics Agile methodology suggests keeping Time (duration of iteration) and Resources (team size) fixed as far as possible. If required, Scope (tasks to be accomplished) can be adjusted based on team’s ability to deliver working AGILE PROJECT MANAGEMENT – OFFSHORE AGILE software. In such a situation, metrics like Schedule Compliance and Schedule Slippage are insignificant. Metrics based on Scope and Defects (to monitor product quality) provide better visibility. Based on past iteration data, Agile Process Capability Baseline & Metrics have been developed, to track and predict scope/defects for future iterations. Control charts using defects and scope as parameters, have been developed. 5 0 .0 0 4 0 .0 0 D e fe c ts C L + 2 s ig m a 3 0 .0 0 C L + 1 s ig m a 2 0 .0 0 C L - 2 s ig m a 1 0 .0 0 C L - 1 s ig m a CL 0 .0 0 UCL -1 0 .0 0 1 2 3 4 5 6 7 Ite r a tio n s Fig 9: Defect Control Chart – Reducing Defects per Iteration 250.00 200.00 Work units 150.00 CL+1sigma 100.00 CL-1sigma CL 50.00 0.00 1 2 3 4 5 6 7 Iterations Fig 10: Scope Control Chart – Scope Management within Control Limits AGILE PROJECT MANAGEMENT – OFFSHORE AGILE 4. OFFSHORE AGILE – IS IT WORTH! Our experience on Offshore Agile has been rewarding so far. The key has been to continuously evaluate the practices being followed, and be open to customize the process, based on the need. We suggest that following points be evaluated before making a decision on implementing Offshore Agile: • Is the team mature enough to follow the practices of Agile world? “People” are a key asset of Agile software development process. All members of the team should be professionally matured to understand the underlying philosophy of Agile. Ownership is the key. People should be capable of proactively suggesting and embracing changes for improvements. Building & retaining a team around such motivated and technically able individuals would have a cost associated with it. • Is the budget enough to absorb cost of rotating resources between onshore and offshore? Smaller projects might not be able to recover the expenses associated with rotating resources through cost savings on offshore development and might have to figure out different ways of collaborating and communicating. • Is the budget enough to absorb cost of infrastructure? The cost of infrastructure to support onsite-offshore communication should also be factored in the project cost. In situations where high reliability and speed of communication infrastructure is a priority the cost of such infrastructure would be significant. • Is the environment prone to continuous change? Offshore Agile development requires significant shift from conventional methodologies. There may be scenarios where the requirements are well known in advance and any deviation from these requirements is not required or desired. In such scenarios, established conventional methodologies may prove to be a better fit rather than going for a relatively newer Offshore Agile development. • Is it desired to define and maintain the software documentation in fine details? In case of projects, which are intended to have long maintenance phase, customers may insist on having detailed documentation. Often in conventional projects documents are updated for every little change in software. It may appear counterintuitive but on a number of occasions discarding old documents and producing fresh ones may prove more efficient. Devoting a lot of time in producing very detailed documentation, which is anyways prone to change and getting attached to the documentation may offset the advantages provided by Agile development. 4.1 Customer Feedback “I had the opportunity to review some new user acceptance tests for AR this week. I was absolutely thrilled with what I saw. The graphical user interface on AR is one of the best I have ever seen. The application looked first class!!” - Product Brand Manager “It would appear as though we have a shining example of Offshore Agile.” - Communications Director “One of the Agile principles has been "Become good at delivery by doing it over and over again” The AR team has taken that to heart. The team has successfully delivered another Iteration on time!!!” - Senior Business Analyst AGILE PROJECT MANAGEMENT – OFFSHORE AGILE 5. REFERENCE MATERIAL • www.agilemanifesto.org • www.martinfowler.com • www.extremeprogramming.org • AOSD: Agile Offshore by Vincent Massol • Internationally Agile By Matt Simons • Agile Software Development By Robert C. Martin • Refactoring By Martin Fowler • Agile Project Management By Jim Hingsmith 6. AUTHOR’S BIOGRAPHY Somesh Chandra has 8 years of work experience in conventional and Agile project management methodologies. He is a part of the Financial Services Group primarily with Banking and Healthcare. He has an experience of implementing end-to-end projects using both conventional and Agile project management techniques. He is currently working as a Project Manager with CSC India Pvt. Ltd., Offshore Agile Practice and is a PMI certified Project Management Professional. Before this, he was working with Tata Consultancy Services (TCS) as a Project Lead. His interest is in finding new ways and applying innovative techniques at offshore using Agile methodology. Devesh Gupta is a M. Tech. in Computer Science and has over 13 years of work experience in the Financial Services domain. He is currently working as General Manager with CSC India Pvt. Ltd. He is responsible for overall delivery and management of all healthcare projects based out of CSC India. Devesh is also actively involved in business development and in managing CSC’s financial services clients across the globe. He is a certified CSQA and Project Management Professional. Before this, he was working with Tata Consultancy Services (TCS) as Senior Consultant and Group Head for a custody banking product.
Pages to are hidden for
"Agile Project Management - Offshore Agile"Please download to view full document