Get certified - Transform your world of work today


Value-Based Agile Adoption

1 August 2013

Sumant Raja
Denarit Consulting Ltd

Adapting based on learning is key to the Agile evolution. Do, Learn, Adapt should be like a spiral ladder that helps you, your team, and your organization innovate and improve with every step you take.
The paper illustrates how Agile principles helped overcome issues in an application maintenance environment.

1. Background

After completion of a major transformation project, a new integration system was handed over to the application support team along with six months of storm support. Though there was significant support during the storm period, the offshore team was new to the system, as 100 percent of the development was done onsite. Another decision was to take a significant number of low-priority defects as known issues, either to be dealt with by the storm support team as production defects or resolved as part of a change release in the future. This was identified as a risk to the knowledge transfer plan, since both the support and storm teams would be busy resolving the defects.

The support model proposed for the application maintenance phase is shown below:
The support team was spread in India and the U.K. This provided a three-hour overlap window when all the team was on the ground. The India team operated in two shifts (A and B) for a period of nine hours each. The U.K. work hour was the standard 7.5 hours between 9 a.m. and 6 p.m. An on-call support structure was established for out-of-hours critical support.

Both onshore and offshore delivery teams were burned out due to regular system outages and the cleanup exercises that followed.

Further, the client was in discussion to sell a part of the business, a move that was realized a few months after the go-live. The systems were expected to provide support during the transition. The stakeholders of this new business were key stakeholders with high influence.

Though there was scope to use the test-driven development, this capability was not exploited to benefit the development and minimize the defects in the production environment.

The section below shows the key stakeholders, the key challenges, and the drivers for Agile adoption.

1.1. Stakeholders

A range of stakeholders are involved in the success of the application ,management engagement.
Stakeholder Responsibility
Offshore delivery team Support and deliver from offshore.
Onshore delivery team Support and deliver from onshore.
Storm support team Provide post go-live support for 6 months.
Functional business analyst Responsible for driving key functional decisions.
Legacy stakeholders The new integration solution delivers to the requirement of legacy systems as well. This included the stakeholders from the part of business that was sold, but the client was committed and contracted to support the new business through the existing IT solution until formal IT separation.
Third-party vendor Commercial off-the-shelf broker is used as part of the system development. Vendor supports the core product.
Release project and other teams Parallel development is done by the release team and as part of other projects. Early involvement is critical to release and project rollout.
Operation stakeholders Owner(s) of the system from operations point of view. Also responsible for business liaising and escalation.
Offshore and onsite leadership team Responsible to support delivery and escalation.

1.2. Key challenges

 The key challenges identified and dealt with as part of the engagement are categorized and listed below:
  • Communication and collaboration challenges
    • Less communication between the offshore team members during transition
    • Little collaboration between the development team and the functional business analyst
    • Lack of coordination between the stakeholders
  • Environment
    • Novice junior offshore team caused high learning curve
    • Unstable offshore team with high attrition
    • Unstable technical environment
    • Divided by geography
  • Delivery
    • High number of tickets logged by the end users and low throughput
    • Number of tickets passed between teams due to ownership of the process
    • A significant time spent on reporting
  • Team dynamics and perception
    • Lack of direction
    • Team burnout when significant issues occurred
    • Team not business aware; this proves to be a major bottleneck in issue resolution

1.3. Drivers for Agile adoption

They key drivers for Agile adoption were as below:
  • Need to improve collaboration and communication
  • Expedite the knowledge transfer
  • Improve team's productivity leading to cost reduction and improved delivery
  • Team was burned out by regular outages and needed motivation
  • Expectation to move to 100 percent offshore delivery model
  • Need to create a business-aware team

2. Solutions and benefits

2.1. Communication and collaboration

Communication and collaboration were key areas to the success of any engagement. The daily stand-up style meetings were initially installed to facilitate open communication. Since there was a limited window of overlap between the offshore and onshore development, resolution of the problem was difficult. Initially, the onshore team took the responsibility of ticket analysis, suggesting the line of resolution to the offshore team. The offshore team invested time to resolve the issues and any doubts were dealt with the next day. This used to result in long meetings during the start of the handover phase. By the end of the storm phase, the offshore team was capable of analyzing the issues and sharing its findings with the onshore team. The issues of categorization, grouping, and prioritization were facilitated on the ticket management tool. Stand-ups were phased out and issues were discussed on calls and via emails.

Two separate 30-minute meetings were initiated with the third-party vendor and business stakeholders. These meetings were held twice every week to prioritize the issues in order to minimize business concerns. Later in the project, these 30-minute meetings involved offshore and onshore teams along with the business stakeholders, and the daily meetings were phased out. This helped the team become aware of the business concerns and prioritize the work.

Also, the transition of work was made easy when a key team member was replaced or rolled off. One hundred precent offshore development was realized with two FTEs on the project. This was a reduction of 400 percent in headcount over a period of three years.

2.2. Adopting automation

The team spent a significant amount of time creating various reports for the stakeholders. This involved 1.5 FTEs for reporting. Most of the reports were identified as optional, desired by the stakeholders but not mandatory. The stakeholders wanted to retain the reports, however, and the following approach was adopted:
  • The reports were classified as "must," "should," and "could" reports.
  • The reports that could be automated, and to what extent, were identified. The support required to automate the reports was also identified.
  • The opportunity to consolidate the reports for all stakeholders was identified.
  • The stakeholders recognized the value of this exercise and agreed to automated and consolidated reports.
The automation was done in phases by balancing the quick wins with the strategic solution to move to a completely automated solution.

Post-implementation, the effort was reduced to .25 FTE, which involved verification and consolidation of data.

2.3. Build relationships with all stakeholders

Rome was not built in a day, nor are relationships. It is important to maintain a trust-based relationship on the principle of open communication and collaboration. More often than not, the stakeholder relies on an honest advisor, motivated to shape the business. The two approaches that worked on this engagement were:
  • Small was considered good
  • Delivering demonstrable value-based results often, demonstrated by quick wins (though this should be balanced by the long-term strategy)

2.4. Team building and mentorship

Agile mentors (aka project managers/ScrumMasters/team managers) are the people advocates on the ground who help the team grow.

"Thank you" and "performance awards" were awarded to individual contributors for making significant positive impacts on the team's performance. The awards provided were specific to the contribution and confirmed what difference was made and how.

Team recognition was provided when the team achieved a given target or had to stretch for a successful delivery. This made the team feel recognized and motivated. The group was recognized through team lunches, performance awards, and thank you awards. Also, any significant milestone was celebrated, which unified the team.

It is important to foster a sense of belonging, so the team was encouraged to go out for team lunches regularly, especially to mark individual events (e.g., birthdays) and achievements (e.g., promotions).

The Agile mentor was also responsible for subtle course correction during the course of the project. The mentor maintained one-to-one relationships with the individual team members to understand their aspirations. This helped the project in various ways:
  • It helped manage project risks around attrition due to dissatisfied individuals.
  • It helped individuals shape their careers and transition to different roles.
  • It established realistic expectations for management of individuals through frank discussions.

3. Recommendation

This paper does not intend to confront any Agile methods/frameworks available in the marketplace, as they are based on industry-wide best practices.

This article does recommend the establishment of an Agile mentor to assess the value in adoption of process/practice. This should be based on hypothesizing the benefit a practice/process is expected to bring. He or she should also define a window of time to expect the benefit to be realized, and a way to measure the benefit through quantitative and nonquantitative success criteria. Not all practices/process yield same value (over a period of time), and there should be a conscious effort to assess practices to ensure that they truly are delivering value. Should this not be the case, the mentor should phase out the practices and processes that are not relevant and help replace them with better practices. The mentor should also ensure that the installed ceremonies are not an impediment to the functioning of the team.

Though the definition of team holds true in the project management world, the fact remains that it is made of individuals with different personalities. These individual members have personal aspiration(s) in addition to their commitment to the project. The team manager (or ScrumMaster, or another mentor within organization) must understand the aspirations of these individuals and help them be realized. This will improve the team's productivity. Also, this helps everyone engage to plan for any transition that may be required.

There should be an effort to recognize team members for their individual contributions. Individual recognition should be based on the "better among equal" principle and must highlight what differentiated the individual within the performing team. When the team has performed well in given scenarios (such as stretching contribution to meet delivery commitment), the whole team should be recognized.

From ancient times, relationships have been key to business and its success. The culture should be built to ensure that the stakeholders are identified as early as possible and that relationships are built on trust and commitment.

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 (1 ratings)


G. Manto, CSP,CSM,CSPO, 8/3/2013 10:12:21 AM
Thanks Sumant. We are undertaking the same and the concept and differentiation between 'storm' and 'support' teams, as you mentioned, is very important. Also, we are working through the "practice assessment" (which we call 'Norms') and following the same process. Great stuff.
Sumant Raja, CSM, 8/5/2013 7:53:22 AM
@[] I am please you could connect with the article and glad to know you are doing practice assessment. I would like to hear from you as you progress through. I am available on email if you would like to discuss ways to improve the practices. email me @

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