Application Services provides a platform for IT Development and Maintenance professionals to discuss and gain insights into best practices, process innovations and emerging technologies that will shape the future of this profession.

« Simplifying Upgrades: The Analysts' role | Main | How Business Analyst can add value to an Agile Scrum project? »

How enterprises can transition from traditional methods of software development to Agile methodology?

Introduction: The current situation

Enterprises spend nearly a third to half of their total IT budget towards application development and hence their success or failure influences the enterprise ability to succeed in the market. Large project usually suffer from factors like schedule overrun, budget overruns, lack of proper coordination among the distributed teams coupled with rapidly changing market conditions that result in fast changing requirements. The three most important stages in an application development process are requirements analysis, development and testing which in a traditional waterfall model goes through handoffs from a BA to a development team to a testing team with each group responsible only for their stage. For instance, any feature misunderstanding is blamed by development team on BA and any defects or code issues are blamed by the testing team on development team. So this sort of blame game is rampant in waterfall model with everyone shirking the end responsibility to deliver a fully functional, fully tested product. Also a lot coordination issues and mis-communications arise with the increase in complexity and size of projects which in turn leads to increase in project teams with each of them working in silos with in-efficient information flow within them.

Why Agile is better?

This is where Agile methodology of software development scores over traditional model of development. Agile intrinsically assumes that markets are dynamic and hence requirements are bound to change and thus proposes a closely knit cross functional and self-organizing team where the BA, development and testing team including product owner are responsible for the end to end product development cycle.

Faster time to market: Agile teams are more productive than traditional teams because there are no hand-offs, teams are working simultaneously on various aspects and they deliver product functionality incrementally so the company need not wait till the end for a big band delivery.

Better communication: In order to reduce any coordination or communication issues the team meets frequently during agile ceremonies like Planning, daily status calls, review and retrospective with a proper goal set to each of these meetings.

Higher quality: Agile Incremental development adopts techniques like continuous integration, TDD (Test driven development), Pair programming which result in early identification of defects and hence increase quality of the increment at the end of each iteration.

How enterprises can transition?

For any organization which has been following waterfall model of software development for almost a decade or two, it is less about the mechanics of agile or getting teams trained on agile but it is more about changing the mindset of team members on how to think differently about development.

The transition need not be an entirely top down or bottom up approach but a collaborative path where the management at the top is provides the vision, need for the transition and resources to support the transition like training etc. and Bottom-up participation is required as it will be the individual

Team members who work through the issues of discovering how Scrum will work best within their organization.


Big Bang approach or a pilot project:

Enterprises can roll out agile methodology across the projects, get teams trained, hire external consultants and send out a message clearly that the organization is decisive about the initiative and thus reduce the effect of wind blowing in opposite direction. But the downside could be that multiple teams might make the same mistakes initially and everyone has to learn it by doing it themselves. A pilot project on the other hand will start small, get the work done and expand it to larger teams by advertising the success of the project to the remaining teams. The downside could be that the failure of the project can severely embarrass the top management and give ammunition to other teams against agile. Also a pilot can help in increasing the awareness of scrum in the organization, increase the success probability and lower the costs of going big bang.



Agile manifesto says "Individuals and interactions over processes and tools". It means that Analysts, developers and testers should focus more on interactions and discussions than on tools or processes of software development. Teams must collaborate frequently over project status, issues, and discussions rather than spending time documenting them. Slowly collaboration should become part of corporate culture.


Establish an ETO:

An Enterprise Transition Office (ETO) is a group which encourages a smooth transition to agile by creating culture and environment conducive to change and by guiding teams embrace agile rather than forcing them by creating a bunch of rules and regulations to be followed. The ETO can consist of VP of engineering, heads of Quality, development etc. Some of the responsibilities of ETO can be to create an Agile PMO which is the guiding body for teams, training scrum master and product owners, collect case studies and propagate the success of teams throughout organization, remove any obstacles faced by teams in following agile model of development like blockades from sales or marketing etc.


Support from other Departments:

For an organization to go agile it is just not sufficient that only the software division be agile while the rest of the support system like Finance, Marketing, Sales, and HR continue status-quo. For ex: Agile projects are collaborative and is more team oriented than individual heroics and therefore HR has to figure out a way to reward/recognize/evaluate the team performance as a whole compared to other project teams. Similarly Sales should alter how they commit features or releases in the contracts with clients to support agile form of development like for ex: Sales can now propose to roll out newer and fewer features very frequently unlike a big set of features for every 6-12 months. 


Very informative and useful article to understand the transition approach. Thanks for it!

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.