Sometimes agility is mistaken for scalability, which is merely one dimension of agility. Steering an enterprise organization toward agility necessitates a structure that is conducive to accelerated decisions, aligned processes, and customer value delivery. Establishing such an environment without a high-trust, collaborative senior leadership team is virtually impossible.

This is just one challenge to an enterprise company’s agile transition, but additional impediments to organizational transformation abound. And many of them will require changes to the culture.

Here are five traditional behaviors that impede agility, as well as some actions you can take to counter them by changing the mindset.

1. Treating innovation as risk

The uncertainty associated with innovation leads to less predictable outcomes, which threatens those who are used to the comfortable existing state of affairs. Innovation is treated as a risk to be mitigated, not an advantage to be exploited.

However, caution and over-reliance on the status quo can impede creativity. Risk-averse visions thwart innovation. Pace is then slowed by predictable outcomes.

For example, Sears, Roebuck and Company dominated consumer retailing for nearly a century by putting catalog-based images of products in the hands of consumers. However, they clung to this model for too long. Walmart derailed it with supply chain management, automation, and fiercely competitive pricing. Amazon then moved the catalog online and championed direct delivery. 

Changing the mindset: Agile organizations use approaches that allow them to deal with the constant upheaval caused by changing business needs. Using early and frequent delivery of value, agile organizations can prioritize their highest risks in their earliest development iterations.

If these risks cannot be addressed as part of value delivery, agile organizations can terminate innovative but risky initiatives much earlier in the delivery cycle than traditional organizations using long release approaches that yield slower feedback. Through early and frequent feedback, agile organizations can use risk as a differentiator, not a deterrent. 

2. Prioritizing stability over being dynamic or adaptive

When silos and review boards are the foundation of a culture’s decision-making processes, it ensures that only ideas that survive the gauntlet are considered. This approach typically results in only ideas that build on a rich past of mature products and services being considered, rather than unique, innovative ones. 

Changing the mindset: Agile organizations eliminate silos, queues, and handoffs, as well as the delays and defects that accompany them. Teams are cross-functional, responsible for delivery, and talk directly to customers. The organization actively pursues eliminating impediments that stifle value delivery. 

3. Maintaining project management offices

Project management offices have convinced leadership that without command-and-control processes—as well as a Gantt chart-, milestone-, and KPI-driven style of work management—project teams would perform even less predictably than they already do. Stated another way, “Doing it right trumps doing it better.”

In these organizations, safe is always better than sorry. Failing fast is merely the first step in a chain reaction, death-spiral sequence. And only the PMO can decipher between capital and expense dollars.

The VP of a prominent organization’s PMO recently told me that her first priority was to strengthen the group’s silo. I responded that I thought that thinking was made obsolete in the early ’90s—a point made well by Michael Hammer and James Champy.That VP had a short tenure, but not as the result of my influence.

PMO-heavy organizations are more likely to be structured (and move) hierarchically, with siloed responsibilities, excessive handoffs, stifling approvals, review committees, and a minimalist trust and collaboration model.

Changing the mindset: Agility is fostered when the business serves as its own voice, rather than the PMO serving as a proxy for the business. Engage business leadership directly. Establish a collaborative relationship before the need to collaborate exists. Treat the priorities of the business as priorities of the enterprise. Explore and discover minimal marketable features with thoughtful discoveries, akin to what systems scientist Peter Senge describes in The Fifth Discipline Fieldbook.

4. Freezing business requirements

Signing off on a requirements document before project funding is granted offers false confidence that the business opportunity is fully understood. The “predictive” methods codified in a detailed upfront project plan encounter frustration and disappointment as true needs emerge and are discovered. While iterative development accommodates the evolution of requirements and encourages experimentation, it is often portrayed as the cause of delivery problems.

To be fair, iterative approaches are not necessary for all projects. For example, if the team knows all of the “frozen” requirements for a product, the organization is familiar with the delivery platform and has experienced success in the past on similar projects, schedules funding is reasonable, the team itself is at least norming, and a single release to customers somewhere down the road is acceptable, one might credibly argue that iterative development provides no substantial advantage for the customer. 

Changing the mindset: Iterative development is better suited when the following project attributes prevail:

• Stakeholders have the courage to admit that they don’t know everything they will want when the work is initiated
• The business prefers to be an active participant in selecting priorities and value
• Expectations may evolve among stakeholders and sponsors
• Early value delivery is desirable
• Project management is based on the natural byproducts of Scrum-like information radiators
• Discovery could lead to better outcomes
• The organization needs to know early on if a hurdle is insurmountable
• Project cancellation or postponement could be a wise choice

5. Resisting change

Enterprise organizations may believe that change results in schedule disruption and delays, thereby emphasizing early requirements sign-off, detailed upfront planning, and exacting execution. Unfortunately, such projects are often not completed on time or within budget; many are in peril before they begin. Unclear requirements, unrealistic expectations, and moving the goalpost late in development are some of the contributors.

Changing requirements late in development often results from an accumulation of changes to postponed requirements earlier in the project. Onerous change-control processes discourage active business partner engagement while keeping the project status “green.” At some point, the business comes to the reality that their changing expectations have been delayed pending additional funding for a follow-up release. Perhaps schedule and budget have remained intact, but the value delivered misses the target. 

Changing the mindset: Two agile practices can help organizations embrace change and remove the need for frozen schedules and requirements: Iterative development (see #4 above) and having an active business partner or product owner can minimize, if not eliminate, misaligned expectations.

An agile mindset embraces shifting priorities by placing prioritization of those updates in the hands of the business. The top priority of the business is the top priority of the agile team. The business partner or product owner owns responsibility for the value delivered, and with it, the potentially shifting schedule. Whether late or early in development, agility fosters the collaboration, communication, and ongoing alignment of expectations between the business and the development team.