Agile Development: Three Hurdles to IT Adoption in the Enterprise

How to overcome the biggest hurdles to agile adoption in Enterprise IT shops.

by Mike Jones

With more organizations declaring their use of agile methodologies (such as last month’s announcement by SAP of their new SaaS strategy that will be built using agile development) you might be wondering if the agile application development approach is something you should adopt in your IT shop. Before you “jump in,” it is important to understand the fundamental differences between an ISV approach using agile and Enterprise IT development. While most ISVs, such as SAP, have been using some form of agile since the beginning of this century, its adoption in Enterprise IT shops has been slower. In this article we will explore some of the key differences between these two types of software development teams and highlight some of the challenges an Enterprise IT shop must address before being able to adopt and scale an agile development approach.

The growing agile movement is slowly being pushed into Enterprise IT shops on the heels of hype. The good news is that when adopted correctly, there is evidence of improved IT efficiency, greater alignment between IT and the business, and the delivery of leaner, higher-value applications. With the continued interest in the use of agile development processes in Enterprise IT shops, some commonly documented hurdles must be overcome to truly embrace and scale agile and deliver on its promise of improved application development.

Hurdle #1: How do I get my agile project funded?

This is not an issue for ISVs because development teams work with a different funding structure that I call “product-based budgeting.” This means that they don’t worry about funding for individual projects/releases or features, and they tend to continue to develop until the product is ready to ship.

If you work in Enterprise IT, your funding structure is fundamentally different. You work within a “project-based funding” approach; you can’t simply keep on developing until the customer is satisfied. In the Enterprise IT world, you have to get funding for each project, translating to some form of project scoping and estimating. If this funding process is done the way it has been in the past, it will not be very agile. Also, if you embrace agile, the features that get pushed out of scope by the business to make way for more important features will have to be put into another project, which requires more scoping, estimating, funding and perhaps even a bid process with your third-party contractors -- again, not very agile. All this can defeat the benefits of agile and leave your business with the agile blues.

To overcome this hurdle, most corporations will have to address their procurement and project funding processes -- no easy task, but not insurmountable. The best approach is to start with a small project and use an experienced agile expert to help you rapidly develop your user stories and size your project. By keeping the first project small enough, you can sell the vagueness of the requirements as part of learning about agile. Success in helping change the corporate culture is based on your ability, within this small project, to keep the business involved and delivering a new application that evolves to meet the main needs of the business.

Hurdle #2: How do I get my business to participate in an agile way?

At ISVs, product direction and feedback is supplied by a staff of full-time product managers. Of course, you don’t typically find product managers in an Enterprise IT shop. This role is played by business users, so you have to work very hard to change corporate culture and get the business to play in an agile way. Agile development will require more time from the business users, more trust, and a shift of application ownership during development that, for many, is a culture shock. The business must be prepared for this new responsibility.

The good news is that after delivering your first few agile project’s iterations (sprints) on time and incorporating feedback from the business team members, you will be on your way to developing the trust necessary to drive agile adoption! Some good advice from practitioners -- keep your sprints short (no more than two weeks) and hit your sprint demo deliverables on time. If you do this, your business will quickly realize you are reacting to their feedback and hitting regular milestones -- probably a nice change of pace from what they are used to! Once the business gets a good taste of agile, they will not want to go back!

Hurdle #3: How do I embrace agile with constantly changing IT team members?

Most ISVs have stable, in-house development teams and utilize very few outside contractors or outsource development to third parties. In most Enterprise IT shops we find “flowing” teams comprised of a mix of internal and third-party resources. In addition, the teams tend to change dramatically from the development of the original application to ongoing maintenance. This makes the concept of agile more challenging, as it requires a different relationship with contractors and typically introduces lots of politics, negotiations, etc. Once again, not very agile.

Enterprise IT will have to find the right contractors and get the procurement organization to let them participate in an agile manner so they don’t risk losing their shirt or end up using non-agile practices. Good agile management tools will provide the needed control and project transparency to keep everyone informed on the project’s progress.

To overcome the challenge of shifting resources between development and maintenance you will need to embrace a set of development tools that support the concept of self-documentation so that your agile approach does not break down when responsibilities shift from the development team to the maintenance team.

We are a big proponent of agile. However, success in the Enterprise IT world requires considerable culture change. Although SAP may go agile in one big push, for the rest of the world we say be agile -- start your agile adoption one project at a time, thinking big but starting small and learning with your business as you go.

Mike Jones has spent 25 years in the technology industry. He leads OutSystems’ marketing team and plays the role of chief agile evangelist. OutSystems has implemented 500+ agile projects over the last 5 years using its Agile Platform.