Is Agile your way?

Is Agile your way?


Agile has become a buzz word in the recent past and there are pretty good number of organizations practising Agile across the globe. Organizations are yielding benefits such as better time-to-market, meeting changing requirements of customers, yielding high ROI, having satisfied teams etc., by practising Agile methodologies. Looking at the success criteria, many others are trying to mock the success by practicing various frameworks of Agile.

But by practising Agile, will organizations yield the desired benefits? What is the success percentage using Agile for organizations? Is Agile your way really?

These questions are to be answered before getting agile practices into the organization. In this article, I focus on few pointers which are to be gauged before taking on any agile framework.

Buy in from Sponsor & Leadership teams

Primary factor to be considered before the organization takes up any agile practice is that there should be clear buy-in from the sponsor as well as the leadership teams. They should communicate clearly why they are moving into agile and what benefits they are keenly looking for by adopting agile. The leaders in the organization will have to drive the message, remove the resistance, assist the teams in getting trained, arrange the coaches, and set up requisite infrastructure.

Volatility of requirements and nature of work

One should check how volatile their requirements are. Based on the volatility of requirements different agile practices have to be adopted. Maintenance and ticketing support systems demand high volatility and the priority of requirements change very soon. Such systems may go with Kanban as it restricts work in progress and facilitates smooth flow. For requirements which can be hold for at-least a week or so can go with other agile methodologies. Any agile methodology per se will be held in iterations which do not generally last for more than a month.

Projects with complexity of technology or requirements generally go with agile. Both technology and requirements being complex/simple will not encourage agile. Both factors being simple, it is better delivered using regular well known process which is in use. On the other hand if both the factors are complex where technology is unknown and requirements are also unknown, agile is not generally used.

Dependency & educated vendors/support teams

An organization whose projects are dependent on various vendor and support teams, it is to be ensured that those teams also practice agile. Both have to be in tandem to get the work flowing. Vendor teams and support teams have to be educated on why they are moving agile. Dependencies between teams have to be clearly listed and followed accordingly. Contracting should facilitate the co-operation between all such teams and contracts should change to T&M (time and Maintenance) from fixed bids. Such a style will enhance the innovation and will improve the quality of products delivered.

Define appropriate metrics

Metrics should be clearly listed to evaluate whether the project is on the path of success. Time-to-market, velocity, responding to changing requirements, customer satisfaction, value delivery are few of the metrics which are widely used to check if the project is heading smoothly. Metrics define whether the investment on agile is paying off or not. It is recommended to have right metrics defined and gauged at right intervals.

Training & Mentoring

Teams should be trained on the agile practices and they should also be mentored by agile coaches in implementing agile across projects. Teams should also be trained on required tools for the projects. Coaches will guide the teams in rightly implementing agile practices and will expose the teams to best practices of the industry.

Scale up in iterations

It is recommended to start small and then scale up the agile practices with the teams in the organization. A big bang approach of completely changing into agile may be very risky. Customer dissatisfaction, uneducated teams, missing deadlines, losing market share, buggy releases may be encountered. It is better that teams take up chunks of work in agile and then scale up. This will define the blast radius and necessary actions may be taken immediately to arrest the hiccups.

These will help define if agile is the way for the organizations to be beneficiary.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s