Why Enterprises Need To Adapt To Agile

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

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.

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 WestOne 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 agileAnother 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 cultureWorking 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 agileDevelopment 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).

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 ... View Full Bio

@moarsauce123: what you're pinpointing really is a flaw in leadership, not a flaw in process. That is spot on. I've seen so much wheel-spinning happen in my career because of executive indecision. I can see why agile would be attrractive though, the thought being: If we can get a first iteration of this off the ground and show it to the stakeholders then maybe they really will make a decision...

@moarsauce:
> In other words, we no longer have to make decisions and have the dev
> teams spend weeks on building something based on a few vague bullet
> points and then we tell them what we really want
You have hit the nail on its head. I have seen it happening a couple of times. And it still is funny and sad at the same time every time.
>

I love your article, since it touches on some of the pain points we are currently facing. I especially admire the tip about replacing legal reviews with demonstrations. I am going to suggest it right away to the team.

It's my strong impression that many organizations are motivated to claim to be using agile methodology, because they've heard that's supposed to be a good thing, but their commitment doesn't go any further than saying the words.

Xerox203, to your on-target point about CIOs being too busy hitting today's deadlines to consider an article like this, I think that's why it's all the more important that someone like Eric takes the time to share lessons learned with his IT peers in this community. An article like this gives fuel to the Agile evangelists -- who are often a step or two removed from the CIO chair, initially -- a conversation starter, or a re-starter. I've shared this article directly already this morning with one Agile evangelist who I know is out there trying to drive this kind of cultural change.

Thanks for sharing your thoughts with us, Eric. You're certainly right - Agile is not going away, and companies that want to pretend it is risk going the way of Music Publishers (vs. digital downloads) and Blockbuster (vs. Netflix) - I think it's that fundamental of a change. On that note, we see an alarming trend when it comes to businesses and traditions, don't we? Saying the we 'fear change' is a bit of an understatement - we have processes, support systems, and cultural idioms in place to justify ourselves avoiding and downplaying change in the business world. We say 'risk-averse' and 'dependable' instead of admitting we fear change. So, you're right again - it's the culture that needs to change.

I always have a secondary concern when reading something like this - while all your points are very good, I'm concerned whether the target audience for something like this (that is, CIOs who are resistant to Agile) are the kind of people who read technology blogs in their free time. It's a big world out there, and there are lots of companies large and small who are still not embracing Agile (or, any new trend) - and those CIOs may be focused on getting today's work down more than worrying about tomorrow. Maybe there's an additional lesson that we can only control our own actions in this big ocean... the best we can do other than that is pass some advice on to the next person.

First of "the entire organization -- not just the development team -- needs to buy into agile" is the best piece in this article. I'm suffering through agile for about three years now and that is the key point that is missing. We need to roll out new product, but the hosting team takes months to fire up a few servers. We review new tech but cannot use it because a year ago during budget prep we had no idea that we would benefit from something that didn't exist yet.

Also, many who want to do agile jump into scrum and see their projects fail. The reason is that especially scrum adds an excessive amount of overhead with daily meetings and retrospectives and so forth. At the same time no effort is spent on planning and documentation. Yes, agile means less documentation, but not no documentation.

No matter how projects are approached it all comes down to the clarity of requirements. No matter if agile, waterfall, or something else, if there is no clear request for "Build this!" then projects will always take longer than expected if they work out at all. The biggest problem with agile is the idea that "we hit this in the next iteration" or we "can iterate over the same thing a few times". In other words, we no longer have to make decisions and have the dev teams spend weeks on building something based on a few vague bullet points and then we tell them what we really want.

Since all this wobbling and indecision requires so much rework the entire project takes longer so something always has to be cut. That is typically quality because in the qarterly plans functionality was already committed to. Agile is the death to quality and the breeding ground for corporate indecision.

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.

When this works I would think this strategy would satisfy many departments at once. Plus, it would be cohesiveness to the company because everyone has the same info about the same project at the same time.

InformationWeek's IT Perception Survey seeks to quantify how IT thinks it's doing versus how the business really views IT's performance in delivering services - and, more important, powering innovation. Our results suggest IT leaders should worry less about whether they're getting enough resources and more about the relationships they have with business unit peers.

They say perception is reality. If so, many in-house IT departments have reason to worry. InformationWeek's IT Perception Survey seeks to quantify how IT thinks it's doing versus how the business views IT's performance in delivering services - and, more important, powering innovation. The news isn't great.