With rapid advances in communication and information technology, global development teams have become the norm, allowing organizations to deliver high-quality software and solutions at low cost. Leading software services companies have increasingly used a global software delivery model to provide custom information technology, consulting and business process outsourcing services to their various customers. For most software services companies, not having a global delivery strategy would put them at a serious competitive disadvantage.
Framework Heights incorporate is the Waterfall and Scrum models for different software modules. This allowed us to harness the benefits of both models while mitigating the risks associated with either of them.
Waterfall Model Overview
The Waterfall model is a highly structured, sequential software development process that progresses through various software designs and development phases in linear order. An ordered list of the phases in the Waterfall process includes the following:
- Requirements specification
- Design
- Construction (implementation or coding)
- Integration
- Testing and debugging (validation)
- Installation
- Maintenance
The model recommends total and correct completion and documentation of each phase before moving on to the next. As such, it emphasizes that requirements are frozen and the design phase is complete before proceeding to the coding phase. This saves time and effort in the construction, integration and testing phases of the software development process and reduces the risk of schedule slippage and cost overruns.
Interested stakeholders can easily monitor progress on the project because each phase has a defined start and end point. Significant customer involvement is required during the requirements specification, design and testing phases, while remaining phases do not require significant input from the customer. One major drawback associated with the Waterfall model is that it can be too late in the development cycle to discover business critical defects, as business testing only begins after the development phase.
Scrum Development Process Overview
Scrum has proved to be a highly successful framework for project management that takes an adaptive, iterative and incremental approach toward software and product development. Scrum is ideally suited for projects with changing requirements. In order to operate in such an environment, Scrum relies on a self-organizing, self-managing, cross-functional Scrum team that is supported by a Scrum Master and a product owner. The product owner represents the voice of the users and customers and is responsible for creating a prioritized wish list of product features, called a product backlog.
Scrum projects advance via a series of sprints, which are typically two to four weeks long. At the start of the sprint, team members commit to completing a portion of the product backlog.
This set of requirements in the backlog is frozen for the duration of the sprint. During each sprint, the Scrum team works on creating a potentially deliverable product increment. At the end of the sprint,the product owner and the customers review the deliverable and provide feedback on the build. This feedback could take the form of bugs, changes in functionality, etc., which could significantly alter the product backlog and the work done in the next sprint.
Although the Scrum methodology often requires significant customer involvement throughout the software development process, it can significantly increase productivity and reduce the time required to release quality software to the customer when it is used to solve the right problems, by capable teams and with supportive management.
Project Implementation
IAs project requirements and use cases were analyzed, we decided that software develop-ment of the business functionality would be best executed under a traditional waterfall model, while using the Scrum model for the presentation layer would allow us to rapidly develop against emerging user interface requirements. A hybrid waterfall and Scrum approach seemed to be a feasible and sensible option for a number of reasons:
- Requirements of the business and data functionality were stable and clearly defined.
- Clients saw greater business benefits in validating and testing the algorithm in its entirety, as opposed to validating incremental iterations of business functionality.
- Software design and development of the algorithm needed to be precisely documented and delivered to the client.
- It was possible to deliver the business functionality to the client independent of a production-level user interface, thus allowing error detection and bug fixing before completing the development of the presentation layer. This flexibility somewhat mitigated the risk of delivering incomplete software at the end of development.
- Requirements pertaining to the presentation layer were going to be developed as the project progressed.
- Clients aimed to lessen the burden of data collection on workers and needed to see working prototypes of several user interface options before deciding on the most user-friendly and least time-consuming option.
Implementation of the Business and Data Layers
Besides the stability of client requirements, the success of a project or module executed by a global team using the Waterfall model depends on the offshore development teams understanding of the requirements. To ensure all stakeholders were on the same page, a Heights associate was assigned to work on-site at the client location as a business and IT analyst.
The primary responsibility of the analyst was to work closely with client business users to develop and refine use cases for the business module. This activity was scheduled to be completed in three weeks. The use cases were loaded into Rational Requisite Pro to ease management and versioning. The relation-ships between the use cases and the high-level requirements were maintained through a requirements traceability matrix (RTM).
Once the high-level requirements were framed and the use cases were written, the use cases were sent to the development team for analysis, clarification and validation. Although it was estimated to be a week long activity, clarifications were sought until design and estimates were complete.
As a next step, the effort to develop the core business functionality was analyzed and the estimates were created using the Use Case Point Estimation methodology. Both the development team and the IT analyst were involved at this for a Scrum project to succeed, it is crucial to foster a collaborative, self-organizing and self-managing environment within the team. The estimation formulation and review were completed in two weeks. The estimates were reviewed with clients, and client approval was obtained. Once the estimates were approved, the requirements were frozen.
Following approvals, the analyst then worked with the offshore team lead and senior developers to develop the software design. The design phase included both the database design, as well as the architecture design. The design specifications and design diagrams were documented in a Software Architecture Document (SAD) template and were reviewed by the IT analyst. A client architect then reviewed it, and the design was approved. The design process was completed in three weeks.Based on the final approved design, the development team started to develop the business module. The application development was completed in 2.5 months, including unit testing of different pieces of the functionality and peer testing within the team.
The business module was then delivered for quality assurance to the testing team. Testing, including bug fixing, was completed in two weeks, and the final build was delivered to the client for user acceptance testing and business scenario testing. Any changes to the functionality or requirements were logged and implemented, using the complete Waterfall model template in a new, smaller iteration.
Implementation of Scrum
For a Scrum project to succeed, it is crucial to foster a collaborative, self-organizing and self-managing environment within the team. Development of trust between team members is a primary ingredient for the creation of such an environment. It is, therefore, essential for teammates to communicate as openly and regularly as required.
In a geographically distributed team, it is often necessary to spend time collaborating with team members outside of core work hours in order to bridge the time difference between onsite and offshore locations. We, therefore, set team member expectations accordingly before the start of the project and were fortunate to have a highly skilled and enthusiastic team willing to dedicate a portion of its non-work hours to brainstorming and consulting with each other as needed. We also provided team members with virtual private network (VPN) and remote desktop access so they could connect to their work machines without needing to be in the office. Phone and video conferencing facilities were provided to enable inter-active dialogue and the perception of nonverbal communication signals.
For the purposes of UI development, the onsite analyst assumed the role of product owner. Given his proximity to client management and his involvement in use case and requirements development, this was a logical choice. The offshore team was made up of the Scrum Master and the actual development team.
The requirements that were generated in the backlog were developed across different sprints. Each sprint had a timeline of one month, with two sprints executed by two different Scrum teams in parallel. The sprints executed in parallel consisted of requirements that were independent modules and hence did not require integration at the end of the month. The UI module was completed in a two-month timeframe, utilizing four different sprints.
Each sprint was executed in the following manner:
- To ensure that project business requirements were clearly communicated and understood by the offshore team, the product owner and the offshore team worked together on converting the business requirements of the prioritized product backlog into IT requirements.
- The first four days after the sprint-planning meeting within every month-long sprint was devoted to this process, enabling the offshore team and the onsite analyst to be on the same page.
- In addition to brainstorming sessions, daily 20-minute standup video/teleconference calls were scheduled to discuss what work was completed, what remained and to discuss any potential problems, as well as provide clarifications on requirements and requested features. An important tool was the creation of meeting minutes.
- A shared Excel spreadsheet was used to exchange queries and clarifications on requirements in the backlog between the Scrum team and Scrum product owner. While it can be argued that agile development is less about creating documentation and more about development of working software, it is important in a global context to document and validate the understanding of the entire team. During development, pair programming was used to effectively share responsibilities in the project. Instead of assigning delivery and unit testing of an entire requirement to one team member, the responsibility is shared by two team members, with development and unit testing occurring in tandem.
- The last week of each sprint was devoted to peer testing and bug fixing.
- A sprint review meeting was held after each sprint to gather feedback from the product owner and the clients. Any changes suggested during this meeting were added to the product backlog and prioritized by the product owner for the next sprint.
Conclusion
WWe successfully developed and tested the presentation and business modules within six months, as per client requirements, and delivered an integrated application for user acceptance testing. Deployment was scheduled after completion of UAT and a few final bug fixes. The client considered the deployment a great success, and we heard a lot of positive feedback from the RMAS user base and the client project manager. Thus, the hybridized software development approach was a novel and highly effective solution, used to guide a challenging project to an extremely favorable outcome.
Having a focused and expert IT team that was comfortable with different software development models as well as taking an open and flexible approach toward the software development process were the key ingredients to speeding up development time and minimizing risks. At the same time, the global software development team allowed us to keep costs low and helped our client meet budget targets.
While a hybrid software development process may not be a silver bullet for all software development problems, it could be detrimental for large organizations to be biased toward a single software development methodology to execute all projects. The choice between Agile, Waterfall or any other software development methodology should be based on which model best reduces risk, increases productivity and improves quality while achieving the goals of the project.
We believe that the freedom afforded to software architects, analysts or developers to tailor the software development process according to business needs and project characteristics is a crucial factor in successful project completion.
