Get certified - Transform your world of work today


The Cheetah Wave: Agility Trumps Speed

A success story at InterGlobe Technologies

4 June 2015

Shalu Tyagi
Information Technology

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:
  1. 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.
  2. 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.

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: 4.4 (28 ratings)


Gaurav Gupta, CSM, 6/9/2015 6:34:21 AM
Very nicely explained the implementation of Agile in IGT.
Karen Fernandez, CSM, 6/9/2015 2:44:42 PM
The article is very informative. Some of the basics (4 values and 12 principles) appears to have been compromised do you think?

Forcing all teams to deliver 45 points? Does that mean all 15 teams estmate all the stories together? How else would you standardize the points?

It is unfortunate that so many companies are wanting Agile but notcwilling to let the teams do the work of making their own decisions.
Kapil Goel, CSP,CSM, 6/10/2015 9:44:05 AM
Good summary of the Organization transformation to Agile mindset and its implementation.
Tushar Jain, CSM,CSPO, 6/10/2015 11:15:26 AM
Congratulation Shalu to bring IGT in Agile fold.

Though, purist may object on various counts (e.g. usage of FP, fixed number of FP, etc.) but I should say that it is starting and may be appropriate given nature of business (multiple clients at various level of maturity, distributed teams, etc.).
Atulya Mishra, CSP,CSD,CSM, 10/6/2015 6:45:02 PM
Again, you splendidly did it.

In my experience Big-Bang approach to agile transformation leads to an environment where it became nightmare to the team, so again my point is; mapping organizational culture to fit in with your agile transformation is essential, crucial and then gradually inspect and adapt on it.

It'e really challenging to map CMMI flow (which demand heavy documentation for audits etc. ) with agile (less documentation)

Hope sometimes we can discuss about your experince on this point and learn from your experience.

Great work !
Ashutosh Singh, CSM, 3/31/2016 2:06:02 PM
This is the best Explanation how we archived full implementation of Agile in IGT .
Shalu Tyagi, CSP,CSM,CSPO, 9/25/2016 8:57:33 AM
Thank You All !
Anonymous, 12/15/2017 9:42:10 AM
Key points discussed in a very systematic and logical manner, the take away from this article is how I can utilize the already proven things at my workplace inspite of reinventing the wheel again. Thanks so much for sharing such a nice article and keep sharing the knowledge.
Shalu Tyagi, CSP,CSM,CSPO, 12/15/2017 11:21:54 AM
Thanks for the feedback

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up