Archive | July, 2012

Maximizing Benefits from Agile Adoption/Transformation

20 Jul

Given that being Agile has a direct correlation with business benefits, viz. Time to Market, Efficiency, Quality and Adaptability, senior stakeholders have high expectations about realizing benefits from Agile Adoption/Transformation. The expectations and urgency are higher from organizations that have decided to adopt Agile after being pushed into the corner.

Being Agile can bring in game changing benefits, some of which can be visible fairly quickly. In cases where organizations/teams have gone through trying times prior to Agile adoption, the initial benefits come with a high ‘wow’ factor.  The ‘wow’ factor can sometimes come in the way of visualizing the full benefits that can be derived from Agility and also sometimes give a false sense of  sustainability.

The following are some of the points that should be considered while Adopting/Transitioning to Agile, with respect to not only maximizing the benefits, but also making them sustainable.

Look Beyond ‘Scrum Only’


There is a fairly common misconception that Agile = Scrum. Actually, Agile is an umbrella for various set of practices, like Scrum, XP, Lean, Kanban etc. Each of these has areas of strength and limitations. Scrum practices largely deal with Requirements and Project Management, and are not strong with respect to engineering practices. XP, or Extreme Programming, on the other hand, focuses largely on Engineering Practices. Scrum practices are easier to introduce and quicker to deliver benefits, as compared to XP Practices. However, XP Practices are more sustainable as compared to Scrum Practices. .Under a majority of circumstances, combination of Scrum and XP Practices have shown to yield the maximum benefits. Moreover, there is evidence that Scrum and XP Practices reinforce each other.

Scrum and Kanban is also a valid combination, in some situations.

The key takeaway is that one needs to consciously think about which combination of practices are relevant for the context and introduce them accordingly.

Processes + Practices + Tools

Benefits from Agile Adoption/Transformation can be maximized by using the appropriate combination of Processes, Practices and Tools. The primary reason for doing so is that the right combination provides benefits which are greater than the ‘sum of parts’. In some cases, tools are mandatory to be able to derive meaningful benefits, e.g. Doing Test Driven Development without Test Automation Framework would yield benefits that are quite sub optimal.

Following are some of the key Processes, Practices and Areas where tools can be used:


  • Iterative Development
  • Adaptive Planning
  • Business Value Driven Prioritization
  • Continuous Feedback
  • Continuous Improvement
  • Sustainable Pace


  • Release Planning
  • Sprint Planning
  • Daily Stand Up Meeting
  • Retrospective Meeting
  • Sprint End Showcase
  • Pair Programming
  • Refactoring
  • Test Driven Development
  • Continuous Integration
  • Continuous Delivery

Areas For Tool Usage

  • Defect Management
  • Test Automation
  • Story Artifact Management
  • Project Management and Reporting
  • CI & CM

Optimize the Whole Process

Agile Adoption/Transformation scope should cover the entire development process in order to derive maximum benefits. While it is ok to introduce changes in stages, the roadmap and timeline to cover the entire process must be clearly laid out. Local optimization yields very limited benefits and should be avoided. Examples of local optimization include introducing Agility in only the offshore or onshore part of the team when the team is distributed, covering only the core development and testing processes, leaving out the requirements gathering and deployment processes etc. Such local optimization carries high risk of creating a divide within the team and that is a huge impediment to Agility.

Use of Appropriate Metrics

Agile is about delivering business value and not about tracking task completion. Agile is also about encouraging right behaviours and not about fault finding. The principles of Agility are quite different from traditional methods and this necessitates the need for a different set of metrics that are in line with Agile principles. An example of a metric which would be inappropriate in an Agile environment is to ascertain a tester’s effectiveness based on the number of defects found by him/her. This metric discourages the tester from collaborating with the developer, and therefore is regressive for Agility. The metric that used be used instead thee business value points that have been delivered and accepted by the customer. This metric, among many aspects, will cover Quality as well.

Changes to Ecosystem

In the process of getting teams to adopt Agile, a fact that is commonly overlooked is the influences of the ecosystem around the team on the team. There are several variables in the ecosystem which can enable or impede Agile adoption, depending on how they are managed. One important variable is the seating arrangement of the team.  The way a team is seated can positively or adversely impact communication and collaboration, which are some off the critical success factors for Agility. Team members separated by cubicles, especially when they are unable to see each other, or worse, seated on different floors, can create serious impediments in maximizing Agile benefits. On the other hand, the ‘dining table’ seating arrangements, adopted by ThoughtWorks, 12-15 people are seated on a single table, seems to significantly aid communication and collaboration.

Another variable methodology and criteria for performance reviews. The drivers of performance reviews in most traditional environments are measuring performance at individual level and that being determined by the manager (‘boss’) of the person being reviewed. In an Agile environment, while there is recognition of individual performance, the success or lack of it is determined at team level. And, as discussed earlier, success it about delivering business value and not about task completion. Moreover since Agile teams are self-organizing, feedback from team members is as important as that of the manager. Also, in Agile, getting regular feedback is not limited to customers only but includes team mates as well. These differences in methodology and criteria necessitate disruptive changes to the performance review process, which, if not made, can become a serious deterrent for deriving maximum benefits from Agility.