Why Enterprises Need To Adapt To Agile

Today's large businesses are not too big and inflexible to be agile. Here's why.

Eric Reed, Chief Technology Officer, GE Capital

July 21, 2014

5 Min Read

Enterprises and start-ups alike have been drawn to agile development in recent years for its speed-to-market benefits. However, there's a misconception that enterprises are just too big to transition to the quick-moving and flexible agile approach. 

On the contrary, I believe agile methodology is scalable and that enterprises can learn to do it well.

In our own organization at GE Capital, we've adapted to the agile approach, recognizing that speed isn't everything. An even more important benefit of agile is its iterative nature, which means that companies have a better chance of giving their customers exactly what they want when they want it. We deliver "minimal viable products" or "MVPs," which are based on a core set of requirements and then further customized with customer input, every couple of weeks. This ensures the customer is invested in the development project and timeline, and therefore more likely to be satisfied with the outcome.

[Designing a mobile app that solves real business problems requires a four-step approach. Read 4 Steps To Build A Better Mobile Business.]

Our adoption of techniques like agile isn't new -- it's one of the ways a company like GE Capital continues to innovate. In fact, broadly across the company we have introduced FastWorks, a set of tools and principles that incorporate the external thinking of entrepreneurs and help us develop products, rapidly test prototypes, and iterate based on a continuous loop of feedback from customers. 

While it certainly isn't easy for a large company to make the transition from traditional development to agile, it is critical for its future success. How can these large enterprises learn to be agile? Below are four suggestions to consider: 

Agile doesn't have to be the Wild West
One of the biggest hurdles I hear about that scares enterprises is the idea that agile isn't governed. The reality is agile development doesn't have to be the Wild West. It just requires a different approach to governance. 

For example, in developing GE Capital's new iManage fleet-management software using agile methodology, we found that security tests and legal approvals were simply taking too long. Weeks-long approval processes are fine when using a traditional approach, but are incompatible with the speed of today's agile projects. We learned that we needed to rethink the way we approach reviews completely.

The iManage project team found a new way to show compliance through demonstration rather than through a traditional review cycle. For each iteration, team members demonstrated their product not just to the full product team, but also to the other stakeholders, such as the legal and security teams. This approach enabled the project team to ensure governance is handled at the speed of agile without compromising rigor.

We've successfully taken this approach on subsequent agile projects, and have also found success including security and legal experts on the project team. Of course, this might not be viable in all cases, but the key takeaway is processes built around traditional development are generally incompatible with agile development, and an organization must be willing to try new approaches.  

Going all in with agile
Another lesson I've learned over the years is the entire organization -- not just the development team -- needs to buy into agile. I once witnessed a project where the development team took an agile approach, but the rest of the business was stuck in a traditional development model. It's no surprise the project failed. 

This is an area where enterprises can learn from startups. I just returned from visiting several startups in Silicon Valley. These organizations were wholly committed to the agile approach. In the enterprise, we need to learn from their example and bring everyone, even the legal and marketing folks, into the conversation.

What this comes down to is a change in mindset -- a culture change. Teams must learn to become comfortable with the iterative approach. They need to get the business to understand that everyone is not going to get everything on the wish list in the first iteration of the product.

Taking steps toward an agile culture
Working toward this major change in mindset is challenging, but it is doable. To help accelerate this shift at GE Capital, we recently established the GE Capital Technology Center in New Orleans, an IT center of excellence where dozens of agile projects are currently underway. 

Whether developing a new capability for our customers to manage fleet performance or a new app for online banking deposits, our developers are constantly demonstrating the viability of agile and refining our approach to development through lessons learned.   

Competing in the age of agile
Development projects such as general ledger or ERP software may always lend themselves to traditional development, but for the most part, the future of development will be dominated by agile. Companies large and small who fail to recognize and adapt to this shift will find it difficult to stay competitive.

We've learned a lot about becoming an agile culture, and we're still learning. Being willing to change, get support from the entire organization, and use simple trial-and-error are some of the best weapons to make sure an enterprise is poised to thrive in the age of agile.

Here's a step-by-step plan to mesh IT goals with business and customer objectives and, critically, measure your initiatives to ensure that the business is successful. Get the How To Tie Tech Innovation To Business Strategy report today (registration required).

About the Author

Eric Reed

Chief Technology Officer, GE Capital

Eric is currently the Chief Technology Officer for GE Capital, a position he has held since mid-2011.  Prior to this role he held a number of roles in IT in both GE Capital and the Consumer & Industrial businesses in GE.  Prior to joining IT, he started his GE career in Engineering on the Edison Engineering Program and spent several years working in New Product Introduction (NPI) designing industrial solutions.  Eric holds a BS in Electrical Engineering and an MS in Electrical Engineering, both from The University of Connecticut. He can be reached at [email protected]

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights