June 24, 2015

Insider’s view on adopting Agile Methodology by Shalu Tyagi, Scrum Alliance

Since January 2012, we at InterGlobe Technologies (IGT) have come a long way since embarking on our journey of Agile implementation. With limited exposure to Agile/Scrum and a new customer under our belt, we encountered several challenges at different stages of the development process.

We learned the following critical lessons during our transition to Agile development.

Getting the right people on board
With a growing number of projects, we needed Agile-ready people in a short span of time. We addressed this problem in the following two ways:
By promoting Certified ScrumMaster® (CSM®) training to internal resources. CSM certification was added to the company’s Professional Certification Policy. Employees who undergo this training are reimbursed by the company for course fees. CSMs can impart what they’ve learned to the rest of the organization.
By helping our recruitment team bring the right people on board to satisfy the requirement of Agile implementation in the organization.

Inducting the Scrum teams
With 15 new Scrum teams, we faced the challenge of training all of them for Agile/Scrum implementation.

We designed a fast-track induction plan. Each Scrum team member underwent a two-week induction comprising the fundamentals of Scrum, led by an expert. Study materials were available to the members as references on the intranet, which helped them scale up to the desired level. We also included the induction training through workshop-based videos delivered by Agile experts.

Managing sprint delivery hiccups
According to Agile philosophy, Scrum teams self-claim the work to be delivered in a sprint. However, in our model, a team is committed to delivering 45 Function Points (FPs) per sprint, as indicated in the Service Level Agreement (SLA). The induction helped minimize the learning curve for the team, and the members were productive from the first day of the sprint. We excluded the initial couple of sprints from the productivity calculation because the teams took some time to scale up to producing 45 FPs for the customer.

Initially, even after working for two weeks, some teams were unable to deliver. In other cases, the sprints were merged to ensure delivery. As a result, sprint-spillover delivery management was another challenge we faced. We overcame these challenges through one of the vital principles of Agile: transparency. Despite these delivery management issues, we continued to involve the customer, discussing the roadblocks and their root causes with them. The customer was considerate throughout these challenges.

For one of the projects, the customer wanted the team to make delivery in the middle of the sprint due to their own constraints and market demands. The business excellence (Quality Assurance) team, who are custodians of the processes, helped convince the client that Agile/Scrum has to principally follow the fixed schedule and cost while the features continue to change.

Adopting a standardized and scientific estimation technique
The customer was dealing with multiple IGT teams at various locations and across geographies, and also with other companies. The recommended story point method of estimation was ruled out, as it was complexity-based and the results varied from team to team. The situation demanded a standardized and scientific method of estimation. Therefore, we used the International Function Point Users (IFPUG) FP estimation technique for product- and sprint-level estimations.

Switching the estimation technique to adjust to the increasing scope
With the client constantly increasing the scope of work, we needed a faster and more accurate method of estimation at the sprint and product levels. We switched to the MK II estimation method, for which internal resources received external training. The Scrum group then formed the estimation board, which was responsible for training people who perform size and review the estimates.

Managing sizing for nonfunctional requirements, legacy code, and rework
In all the cases, IGT was given legacy code as the base code for further enhancements. Enhancements included lots of refactoring of the code. Additionally, some stories did not include any functionality and were technical in nature, such as moving the code from branch to trunk. Because these technical stories were also an integral part of the product backlog, we needed to size them. We learned how to accurately size these stories from the customer’s own estimation expert.

The scope of work included reworking the functionalities that had already been developed. The reworking of functionalities was also an integral part of the product backlog, and we needed to size them as well.

We learned how to size the rework in Agile projects, an activity that is not typically calculated in the Waterfall model.

Managing conflict between Waterfall and Agile cultures
The teams considered stand-up meetings to be a sheer waste of time that could instead be spent on developing and testing the application. They felt that they would have to prepare the meeting minutes, send calendar invitations, and maintain these artifacts for audit purposes.

We convinced the teams to attend the stand-up meetings by letting them know that no artifacts were required for the audits. We also ensured the real-time implementation of the process by randomly attending their meetings.

Initially, the meetings lasted beyond the scheduled time, with no valuable input emerging from them. However, as time passed, the teams began to provide good input during the meetings and also adhered to the timeline.

Project managers were worried about not having a productive role in Agile, because the teams were self-managed and, as ScrumMasters, they would have little to do. We debunked this misconception by providing awareness sessions in which ScrumMasters were briefed about their roles in Agile/Scrum.

Reaping CMMI benefits
Being a Capability Maturity Model Integration (CMMI) Level 5 certified organization, we have a dedicated team to perform project audits. The same team conducts monthly audits to verify the implementation of the Agile/Scrum process. They perform regular audits and conduct process assurance activities through regular process compliance checks. The results of the audits, along with the metrics performance, are then reported to senior management for updates and feedback.

Agile governance through numbers
With the accelerated growth of the team, a new dedicated team was formed to manage the metrics dashboard, which displays all the raw data and metrics at the portfolio level. The dashboard helped us manage data and focus on improvements based on our current performance. The Metrics Baseline Report released at the organizational level helped us gauge the performance of our Agile framework across all teams. This has also helped with measuring our productivity at many levels, such as at the project level, portfolio level, and organizational level.