The Accidental Scrum

15 January 2012

Kaushik Kakoty
Infosys

We executed our project in a Scrum manner without even knowing our method was Scrum. What initially looked like an impossible project was delivered in six months, with exceptional customer satisfaction and confidence all around.

Background

As part of a major transformational program, IP/MPLS networks data was being migrated to a strategic logical inventory IT system from a set of networks that had been managed in legacy systems. This led to the business inventory management of these networks, also to be migrated from the legacy to a strategic system. However, the legacy system provided read-only access to close to 350 business users for assisting in their network design and construction process.

The transformation of IP/MPLS required the implementation of a swivel chair (dual data entry) process. This would have the designer "designing" the migrated network device in the new strategic system and then going to the legacy system to update it with relevant data. The swivel chair process was required to ensure that the networks not migrated to the strategic world as part of this release would have sufficient data to continue to complete detail design on the intersecting network components, specifically allowing the designers in the legacy system to know the other end of the network recorded in the new system.

Need

We had an inventory data warehouse and reporting application that had to support the reporting requirements not fulfilled by the new strategic system. This reporting solution was needed so that staff has access to an up-to-date, consolidated view of both the new strategic and old legacy system data, post-data migration.

If this reporting solution were not developed, the designers and business users would have to enter the same data manually into two systems and establish manual processes to keep the data synchronized on an ongoing basis. It would increase the risk of both data bases becoming unsynchronized, resulting in increased effort by front-of-house, field installation, and assurance staff when interrogating this data.

Additional training would need to be provided to current users of the legacy system, who would need to access the strategic system if this information were not transferred to a tactical reporting platform. Additional customer impacts would be felt, with delays in delivering products ordered, as dual entry would increase the complexity and effort in determining availability, designing, and building the products for customers.

Approach

We began this project with a requirement of 86 reports to be developed within a quick timeframe of six months. Some of the reports were complex, due to inconsistent terminology in the legacy system. Each user had his or her own interpretation of the "Status" of a port, for example. This was difficult to make consistent and mappable to the standards in the strategic world.

Instead of going for a traditional big-bang Waterfall approach, we decided to try an iterative approach, delivering in such a way that usable reports would be available at the end of each iteration. Initially, it was extremely difficult to convince the business stakeholders of our approach, because they weren't used to this kind of methodology. We proposed to deliver the most critical reports in the early releases and then, based on feedback from the users, continue to deliver the entire lot in four releases (four sprints, in Scrum terminology). With the hope of getting an early delivery for the most critical reports, the stakeholders finally agreed to this approach.

We began by creating a tracker. It included all the reports, their initial criticality (as felt by the business users), business workshop date, report specification creation/delivery date, report specification issue resolution date, report prototype date, report specification signoff requirement by date, report specification signoff notification, UAT date, UAT approval required date, and the release/delivery date. The business users were busy and required five business days of advance notice and preparation time to attend any workshops. Therefore, maintaining this tracker was critical in helping to plan. Each week we had one workshop in which we covered unresolved items from previous workshops, new reporting requirements for the current workshop, and feedback on report specifications and prototypes.

Results

Once we took the iterative approach, this project was delivered over four releases, each averaging 1.5 months. The longest ones took two months and shortest just three weeks. In addition, by the time we went to the second release, the number of reports required by the business was reduced to merely 25 (from 86).This was because when the detailed business workshops were conducted involving the relevant business users, we could see redundancies and the value of consolidation. When we removed those redundancies and provided the envisioned consolidations, the actual number of reports required dropped drastically.

I must note that the initial release was difficult from both the technical and the perception points of view. The business users didn't have much confidence in our approach. In fact, some of the initial workshops for the first release were unfriendly. However, once that first release was out and users starting reaping its benefits, the atmosphere changed radically. In short, the business users began to believe in our delivery capability. For the last two releases they had full faith and confidence in the IT team, and every aspect of those releases went smoothly.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 0 (0 ratings)

Comments

Be the first to add a comment...


You must Login or Signup to comment.