Many Scrum practitioners get started on the Scrum implementation journey taking a purist's view, and at times they may not evaluate the project for Scrum suitability. If the suitability assessment is done and the project is not found suitable for Agile implementation, then the Waterfall model is typically selected, as it is the most familiar model for executing projects.
It is essential to assess whether the projects are suitable for Agile execution based on the level of benefits that they are likely to experience and on the level of readiness of those involved in the project. Also, there are times when some of the Agile ceremonies can be introduced based on the need of the project regardless of the software development life cycle (SDLC) model chosen, and they are bound to help in delivering value.
Here is a case study of a project that illustrates such an experience.
An IT project for a bank had set out to upgrade a third-party finance product. The scope of the project included building interfaces on a different technology platform to the new product version, as well as using reporting engines to deliver existing reports on a new platform, with minor design changes. The business subject matter expert (SME), along with the business analyst, had documented well-defined and detailed requirements. These were available to the team up front. The project was thus assessed to not incur any significant benefits by following an Agile execution model. Hence, the project was set up to be executed using the standard Waterfall model.
The project plan was accordingly finalized based on the well-defined requirements in consultation with all key people involved -- development lead, test manager, third-party product manager, infrastructure manager, and leads of interfacing teams.
During the course of the project, when the development was more than halfway through with the key interfaces and some key reports were designed and developed, the senior business SME who was closely associated with the project left the organization, as did the business analyst (BA). They were replaced by a new business SME. The new business SME did not approve of the design of the reports that had been provided by the earlier business SME. The requirements that had seemed clear at the beginning started to change, and the team had lots of concerns around the rework and the release timeline.
The developer, along with the new business SME, prioritized the reports based on the impact. The tasks and their efforts were estimated, the reports were reviewed by the business SME as they were developed, and they were approved for the design and details. Some additional report needs were identified and were addressed by the team. The team used a Kanban board to track the activities and hence the requirements to acceptance. The additional requirements were added to the board as they arose. The requirements were prioritized after every approved delivery. Additional requirements were called out and separately evaluated with respect to cost and criticality. The team thus progressed to deliver the reports with business-defined priority. This helped in delivering the outcomes, which were almost signed off. There was a slight change made to the timeline for acceptance testing, which was readily accepted by the business.
At a later stage of the project, during the formal user acceptance testing phase, a critical report did not reconcile. That turned out to be a showstopper, which required the technical architect to recheck the design. The design was revalidated by experts. The issues were turning out to be difficult to analyze. The testing team, development team, and the product vendor team were in a deadlock situation -- a cyclic dependency that subjected the project to a finite risk of being called, which in turn meant heavy losses to the bank and a frustrating experience for all the teams involved.
A sub-team of the members who were working on the issue was formed. The Scrum process depicted in Figure 1 (below) was followed to resolve the issues at hand.
Figure 1: Scrum process
The process helped in leading slowly but in a structured manner toward the desired goal. The outcome came through in time and the report reconciled. This unblocked many of the issues that had stuffed the defects register. The teams that had been at loggerheads were celebrating the outcome -- the final business sign-off.
The deviations experienced in the project were technical issues as well as circumstantial ones. The project implemented two key Agile practices as solutions to handle these deviations, and hence key risks to the project plan, and the teams celebrated the success of the solutions.
This project experience leads to some key conclusions:
Agile practices can deliver their benefits in projects that are planned to work using non-Agile models.
Agile, and particularly Scrum, practices help in leveraging collective wisdom.
Agile and Scrum practices deliver an outcome of the desired quality through collaboration, with a sense of ownership at the individual level.
This experience can lead the process group to rethink the guidelines used for classifying a project as not suitable for Agile implementation.
This experience can help reinforce the benefits that Agile practices can bring to any project.