Tag Archives: Agile Benefits

The Implicit Agile Principles

23 Nov

The essence of Agile is supposed to be brought out by the Manifesto and 12 principles. However, there are few Principles which I believe are extremely critical for ‘Being Agile’, and these appear to be either unstated or implicit. Following are the ones I could think of:

  • Build Quality In

 It’s quite surprising that the word ‘Quality’ does not find a mention anywhere in the Agile Manifesto and Principles.  Better quality is perhaps one of the most underrated benefits of Agile (assuming Engineering Practices are also implemented, Practices like writing Acceptance Criteria upfront, Test Driven Development and Test Automation, combined with QA collaborating with the BA and Developers throughout the development cycle has resulted in Quality usually being a non-issue. Agile promotes the notions that Quality is the  responsibility of every single member of the team and that Quality is to be built in right from the beginning.

If the list  12 principles is to be expanded, this principle should be right at the top of the list

  • Shorten Feedback Loops

Almost all Agile Practices help in getting early and robust feedback from various dimensions:

  • Feedback from the ‘Product, through Unit Tests and Continuous Integration
  • Feedback from the Customer, through Acceptance Tests and Showcases
  • Feedback from the Team, through estimation and scheduling based on prioritization
  • Feedback within the Team, through Retrospectives
  • Feedback between the above mentioned entities

Shortening feedback loops across all entities as mentioned above helps to take corrective course of actions more quickly and effectively, and also enables a culture of Continuous Improvement

  • Fail Early, Learn Fast

A principle similar to Early Feedback, this principle too is extremely valuable for both Business and the Development Team. Businesses love Agile because they can the MVP to the market, and come to know if early if it is not going to work, thereby save on costs which they would have to spend if they had taken the ‘Big Bang’ approach. By showcasing Working Software at frequent intervals, any mismatch between expectations of the customer and what has been developed can be identified early  Engineering Practices like using Assertions in Unit Tests can help detect typo mistakes immediately, which can otherwise not only lead to, for example,  mysterious slowdowns of thee system, but also make it quite difficult to detect the defect. Given that the cost to fix a defect rises exponentially from the time the defect the defect is to introduced to when it is fixed, the ;fail fast’ principle in writing code is immensely valuable.

Agile recognized that if failure has to happen, it should happen early so that it provides an opportunity to learn/correct and, as in case of Early Feedback, adjust course more quickly.

  • Practice Brutal Transparency

Transparency is an absolute precondition for being truly Agile. Transparency helps in avoiding unpleasant surprises, mitigate risks and, most importantly, build Trust.  Transparency is about having the Courage, a core value of both Scrum and XP, to share bad news early, about acknowledging one’s limitations and asking for help, about making the work pipeline and key metrics visible through ‘single source of truth’.

This is probably the most difficult principle to follow in true spirit. However, without Transparency, chances of succeeding in implementing Agile are very bleak.

  • Accuracy over Precision

Given the nature of software development, and perhaps any other knowledge driven work, the unknowns and uncertainties between providing the estimate and delivery are far too many. The situation was very similar to days of ‘Carpet Bombing’ when technology was not advanced enough to deal with the uncertainties between the dropping the bomb and it reaching the target. Being precise about dropping the bomb on the target was not working and hence multiple bombs were dropped with the hope that at least one or some would hit the target.

The reason why Estimation and hence Planning have much more credibility is because Agile recognizes that precision is immaterial and it is accuracy that matters.  How useful it is the precise estimate that something will get done in 11.75 days, knowing very well that it is highly likely to change, or that it will take approx.. 2 weeks, for planning purposes?

Agile is helping us move away from having pointless precision to having meaningful accuracy. Hence, this principle, though explicitly unstated, is quite important.

  • Embrace Discipline

One of the stated 12 principles is ‘Build projects around motivated individuals’. There is perhaps an implicit assumption here that motivated individuals, who belong to a self-organizing team, are disciplined. In reality, this is often not the case, as the importance of discipline is not clear in the stated principles.

Agile is about team enjoying autonomy, and also about team practicing ‘brutal’ discipline. Imagine the amount of discipline which is needed to deliver working software regularly at very short intervals. Examples where discipline is always expected include the ‘ceremonies’ (stand up meeting etc.), writing unit tests, regular check-ins etc.  Discipline is an essential ingredient of a self-organizing team, which is such a critical element of Agility.

Can you suggest additions to this list?


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.