You aren't Agile until your team has read and understood the 12 principles of Agile Manifesto.

Software development is not a one and done work. It is often being in a state of constant refactoring due to situations not thought of, new threats, user expectations or simply finding a better way to do things.

As simple as it may sound, if your company isn't funding your successful project next year - some reasons.- a potential change in environment that makes the project less useful in future. You may not know this yet. - they didn't understand the project in the first place.

Software is not a done and forgotten system. If your org doesn't allocate money to maintain software for a couple of years, you have already put the product at a disadvantage. At this point any additional upkeep requires huge investment. Some decide to fully rewrite the stack.

These companies tend to have more managers than engineers at the top. More yet, even in IT shop they will have a lot of sales and operations people managing IT staff.

They prefer expensive SaaS over homegrown products, because they don't want to be holding a system and engineers that they don't understand. If it's SaaS, they can outsource maintenance. After all success is not defined by cutting edge software in their industry.

If the higher ups in an org don't understand the basics of their own tech stack, then tech is not the primary driver for the company's success. This is not bad, low competition or high cost of entry markets could be like that. Not every company needs tech as the primary driver.

In large cos; the CxO's are often concerned about their next job and take conservative decisions that will never tarnish their names.

One another reason why small cos are innovative; they often have a few individuals at top and decision making is quick. The reduced layers improve feedback from implementation group to the management and vice versa.

The real change will come from the people on ground, the leadership however is expected to set the stage for teams to be innovative.

Often CxO's outsource this work to a pseudo CxO (Chief Innovation Officer whose job is to work with Big 4 and come up with a few roadmaps to appease the Board. This person doesn't have skin in the game like the real CxOs. So they don't accept the risk and take the risk free path.

We often associate innovation to success. Innovation carries risks; often it leads to failures, costly redo or reputation losses. Even more important for the people at top (CxOs) to acknowledge and approve these as important for the long term success of the company.

The collective pull of the legacy not ready for innovation org will negate any improvement made by the innovative teams.

Innovation is a top down exercise; if your CxO is not onboard, the innovation will not have a true lasting effect. yes, smaller scale project innovation can be beneficial but for an org to become innovative it is not enough for some individuals to be innovative.

In a revolving door enterprise, everyone takes decisions like how Art Howe explains in Money Ball - something to the like of 'making decisions that will sit well with my next companies'. Basically, take the conventional path and you don't have to own the failures.

Continuous improvement is frowned upon in enterprise as it tends to give a vibe that the original product is not good enough. So they build something very big that gets the board approval. All they need is to keep it running for the next 5 - 7 years (tenure of the CIO).

How different the world would be if the CIO's dedicate fixed cost to every project and let the customer / market determine what should live the longest vs forcing the build product onto the customers.

At the appropriate time (when new CIO comes in), they go in dismantle everything and build their own legacy with a completely new multi million dollar product based on conventional wisdom of the consulting companies.

The result is often a misaligned, expensive product that they spent millions on which can't be shut down (due to the millions spent), and every other decision in the company will be around keeping this product alive (at least until the CIO leaves).

Enterprises also don't do much of user research, they tend to think they know what their users want (based on Gartner reports) and they tend to think they know what the users will want for the next 5 years (based on McKinsey research).

You are not generally incentivized to test and learn, but build in a big bang fashion. This results in millions of dollars dumped into the system and because of these millions it can't be shut down and every other system in the company is forced to keep this alive.