EMC PERSPECTIVE Adopting an Agile Approach to OSS/BSS Development
Reader ROI The agile software methodology is different from the traditional approach in that requirements gathering and analysis, design, and construction have overlaps and developers are willing to accommodate requirements and, hence, designs that keep evolving. The agile way of development recommends writing test cases soon after the requirements are written. Coding is done to meet the requirements and the objective of the coding is to pass the written tests. Code may be frequently reorganized and tests re-executed to meet evolving requirements. The agile approach recommends working closely with business users and delivering incremental solutions to them every four to six weeks. An IT organization can adopt the following agile best practices: use-case-based requirements specification, emphasis on meeting business needs, making periodic software releases, focus on a working solution rather than formalities. Adopting an Agile Approach to OSS/BSS Development The biggest challenge that communication service provider 1 IT shops face today is to deliver more functionality in the operations or business support systems (OSS/BSS) with a reduced time to market. How can the IT organization be more responsive to business? Should the IT organizations retool their shops with a different process? What are the best practices an IT organization can adopt in order to be agile? Agility is the ability to be responsive. A software development process would be considered agile if it: Helps realize business value from development efforts quickly with a shorter delivery cycle Minimizes bottlenecks and dependencies across development tasks Works with changing requirements and allows the adaptation of the solution to respond to changed requirements Increases user involvement in the development process Promotes effective communication across development team members Forrester s 2003 North American benchmark study included interviews with 704 North American IT decision makers and found that 57 percent of projects failed because of poorly scoped requirements, 35 percent because of buggy software, and 30 percent because of unattainable business requirements. Agile processes address many of the problems that are at the root of such failures. Perhaps that explains the growth in acceptance of agile processes in corporate IT shops in the last few years. A few years ago, founders of agile processes including Scrum, extreme Programming (XP), Dynamic Systems Development Methodology (DSDM), Adaptive Software Development, and Feature Driven Development (FDD) and Crystal, united under the umbrella of the Agile Alliance. The agile movement is now gaining momentum. Traditional vs. agile software development processes A traditional software development process follows a sequential, waterfall approach in which the requirements gathering and analysis, architecture and design, code construction, system testing, user acceptance testing, and installation are done sequentially. There is very little concurrency and there is very little interaction between users and developers. The three most widely used agile processes are: XP, DSDM, and Rational Unified Process (RUP). Agile processes differ from traditional SDLC processes in many ways and are described below. 1. Working in small increments: The traditional approach requires a longer delivery cycle before a working solution is delivered to users, compared to the agile approach. The agile approach consists of building and delivering a working solution in several iterations. The iteration does not represent the final product, but it is an incremental step towards the final product. It gives users a chance to see, touch, and feel the solution much earlier. After seeing the solution, the users may make requirement changes and they get worked on in a subsequent iteration. 2. Philosophy: The philosophy behind the traditional software methodology is to follow a process that includes entrance and exit criteria for each phase. At the time of exiting a phase, the reviewers review the work done in that phase. Change control is enforced aggressively, in the sense that after a phase is complete, the deliverable produced in that phase is considered frozen. Agile is a different philosophy in which requirements gathering and analysis, design, and construction have overlaps and developers are willing to accommodate requirements and, hence, designs keep evolving. The agile way of development recommends writing test cases soon after the requirements are written. Coding is done to meet the requirements and the objective of the coding is to pass the written tests. Code may be frequently reorganized and tests re-executed to meet evolving requirements. 1 Wireless, wire-line, cable, and Internet service providers 2
3. Emphasis on Documentation: The traditional methodologies emphasize creating detailed documents. Documents are used as a means of knowledge transfer and as a risk-avoidance mechanism in case the person with the knowledge leaves the project. Agile takes the approach that a working solution is more important than documentation. That does not mean that Agile does not produce documentation. On the other hand, Agile values self-documented code, design documents that graphically show how the solution is constructed. Agile also places a lot of importance on people actively discussing and brainstorming to reach a common understanding. 4. IT and Business Separation: The traditional approach includes the business stakeholders in the requirements-gathering phase. After the requirements are analyzed and reviewed, business users really don t get involved. On the contrary, Agile recommends working closely with Business users and delivering incremental solutions to them every four to six weeks. 5. Change Management: The traditional methodology aims to keep change under very tight control. Changes to scope and functionality are formally documented and have to be approved by management. Agile, on the other hand, accepts that changes are bound to happen and although changes need to be documented, there is not much resistance to change. Refactoring the code is a legitimate phase in the agile development process. 6. Team culture: A team practicing a traditional methodology sees team members as a group of specialists. Each individual owns a part of the solution under development. If there is a question or a problem in that part, every one knows who to go to. On the other hand, if the specialist is away and a part needs to be changed, the team waits for the specialist to return. Agile takes a different approach here. Individuals are responsible, but the entire team owns the solution. Each team member works on different parts of the solution, however, if another team member modifies a part of the solution, the owner is not offended. 7. Success Factors: A project manager practicing the traditional methodology considers a project successful when the project is completed on time and within budget. Most often, the project manager makes the project plan after the project sponsors approve the charter. The chances of the on-time and in-budget completion are greater depending upon how stable the requirements are, how experienced the project team is, etc. The project manager who has adopted the agile process is fully aware that plans will change. On-time completion is important, but what is more important is that the solution is user driven and meets the needs of the users. 8. Effort Distribution: Typically, project managers practicing a traditional software development process estimate the development effort with a 60/40 rule. Sixty percent of the total effort is spent on gathering requirements, architecture, and design. Forty percent of the total effort is spent on coding, unit testing, and system testing. On the other hand, a project manager using an agile process for development spends almost equal amounts of time in requirements gathering and analysis, design, coding, and testing. 9. Flexibility: The traditional methodology of software development is modeled on the basis of implementing a predictable process. This works well if requirements are stable and do not change. The Agile process addresses stable as well as evolving requirements. In that sense, the agile process is more flexible and accommodates changes. 3
Agile best practices Even though an IT organization has not embraced an agile process as its core software development process, the following best practices can be adopted easily. Requirements Definition 1. Use-case-driven requirement gathering is a very effective technique for capturing requirements. Write use cases followed by detailed functional requirements with the participation of business users. 2. Prepare test cases when requirements are defined. 3. Understand that requirements will evolve over time as business users start using the solution. Analysis and Design 1. When considering competing design choices, the simplest choice is the best choice. 2. Focus on people and not technology. Make sure that the developers understand the design by providing key artifacts such as sequence diagrams, entity relationship diagrams, class responsibility collaboration (CRC) diagrams, class hierarchy diagrams, etc. 3. Look at the big picture and not just the most commonly used use cases. Development 1. Time-box each iteration to a period of four to six weeks. Time-boxing will help bring unpredictable requirements under control. 2. Make the development process requirements and intention driven. The intention should be to pass the written test to test the requirement against which the code is written. 3. Get it working first, optimize and re-factor later. The goal of every developer should be to meet the requirement and pass the test case. After the code works, it can be optimized and performance improved. 4. Be prepared to change the code if the requirements change. 5. Follow coding and documentation guidelines so that other developers in the team will be able to follow and modify the code as required. Testing 1. Get business users and developers involved in reviewing the test cases. 2. Be prepared to run multiple rounds of testing. 3. Provide feedback rapidly to the developers regarding problems encountered during testing. Project Management 1. Remember that the schedule you make at the beginning of the project will have to be changed as the requirements evolve. 2. Keep the developers motivated, as they might have to make several passes through the solution in response to changing requirements. 3. Keep the project sponsor abreast of the impact of the changing scope and requirements. 4. Facilitate good communications. Set up a war room. Organize daily team meetings to discuss progress and issues. 5. Make sure that the design is not sacrificed to meet the planned date. 4
Suitability of agile methodology An agile development process is not suitable for all types of software development projects. Project managers often have a choice of choosing a development process. Many project failures can be attributed to the wrong development process. There are no hard and fast rules as to whether an agile process is better suitable for certain types of projects over others. Based on project constraints, the team composition, and other factors such as stability of requirements, the project manager should make a decision about which process to use. Needless to say that some of the agile best practices can be used, as appropriate. Let us review the pros and cons of using an agile process for different classes of projects: 1. Projects with stable requirements: The traditional software development process works well when requirements are predictable, stable, well-defined, and understood. Architects and designers provide a design based on the requirements and the developers implement the solution based on the design. Agile best practices can still be used in such projects, which will undoubtedly add value. If multiple iterations are developed instead of a single release at the end of the project, such iterations can certainly help the confidence of the project sponsors. 2. Projects with unstable and evolving requirements: The agile software process is well suited for such type of projects. However, the project manager has to make a judicious decision about when to start the coding phase. If coding and testing begin before the design is well understood, undoubtedly there will be multiple passes needed before the code works right. In such cases, the agile approach may end up taking more time than the traditional approach. So the decision of when to start coding is a key decision that will influence the fate of the project. 3. Small versus big projects: Historically, agile methodologies such as extreme programming have been used successfully in small projects, with teams of 12 people or less. Big projects obviously have big risks and the project manager can decide whether to use the agile process or not, depending upon several criteria such as whether the team members are experienced in agile processes or not. 4. Onsite versus offshore projects: Agile processes typically work well when team members are co-located. An IT organization that has never developed with an agile process before and wants to use an agile process with an offshore development team will face significant challenges. Frequent face-to-face meetings and good communications will help mitigate risks in such situations. 5. Fixed price versus time and material with an upper limit: In general, it is not a good idea to commit to a fixed-price project if the requirements are unstable. Estimating the overall project effort is hard no matter which development process is used. Having said that, an agile process with time-boxed iterations can be an effective way to deliver a fixed-price project with a definite end date. Adopting the agile way While it is easier for small IT shops to adopt new software processes, bigger, more mature software organizations with hundreds or thousands of software professionals cannot adopt a new process overnight. Here are some steps to introduce an agile development process in a relatively mature IT organization that already follows an established process: Establish an Agile software center of excellence (CoE), staffed by consultants experienced in applying agile processes. The CoE should clearly define the agile process that will be followed for developing software solutions. The CoE should also publish a set of standards, guidelines, and best practices to be followed. The CoE will train and mentor members of the IT organization in using the agile process. The CoE shall also acquire tools to promote agile development. The CoE should also define a metrics framework that will help measure the gains due to changes in the agile process. The CoE should identify a set of early adopter projects. The early adopter projects should use the agile process from requirements gathering to installation and deployment. After carefully analyzing the experience gained in early adopter projects, the CoE should take the agile approach to the mainstream. 5
About BusinessEdge Solutions BusinessEdge Solutions, an EMC Consulting Practice, offers strategy, process optimization, and information management services to clients in the telecommunications, media, and entertainment (TME); financial services; and life sciences industries. Leveraging our vertical industry thought leadership and asset-leveraged consulting, supported by pre-engineered business and information management frameworks, BusinessEdge drives competitive advantage for clients and reduces the time, cost, and risk of delivering breakthrough results. Industry and technology expertise and experience are at the core of our commitment to create vision for our clients and are the drivers behind the delivery of high-impact business solutions. Our consultants average 15 years of industry-specific experience and apply their deep knowledge of the industry, technology, business architecture, and business best practices to develop information management strategies that improve process effectiveness and productivity, reduce business risk, improve decision making, enable collaboration and knowledge sharing, and enable the optimization of IT spend. EMC Corporation Hopkinton Massachusetts 01748-9103 1-508-435-1000 In North America 1-866-464-7381 www.emc.com Take the next step For more information, contact BusinessEdge Solutions, an EMC Consulting Practice, at info@businessedge.com, call 1-800-655-EDGE extension 3040, or visit our website at www.businessedge.com. EMC 2, EMC, and where information lives are registered trademarks of EMC Corporation. All other trademarks used herein are the property of their respective owners. Copyright 2008 EMC Corporation. All rights reserved. Published in the USA. 04/08 EMC Perspective H4339