What Is An Agile Organization?

When working toward becoming an Agile Organization, many companies begin by applying Agile methodologies at the team-level and then call the Transformation done.

The problem is that even when you do it perfectly, establishing a team-level Agile Delivery Model is almost always insufficient.

It’s insufficient because the rest of the organization isn’t built to be Agile.

We can’t simply provide the Teams with everything they need and assume they will figure out how to make good on the delivery. Teams don’t own the risk around finance, technology, brand, and so on, so how can we reasonably expect the Teams to make it all come together? The Agile principles established at the Team level can’t and won’t naturally scale to the remainder of the organization if the organization isn’t prepared to radically change. So how then do we go beyond simply going through the motions?

What does a true Agile Organization look like—and what must we change to get there?

Overcoming our Barriers

It’s not enough to have a ration of Sprint Planning and a slice of Jira and then call ourselves Agile. The bottom line is that Organizational Impediments get in the way of the Agile System of Delivery and must be addressed before we receive the benefits that Agile promises. These impediments often exist in many different reaches of the organization and are a symptom of the old ways of doing things.

It’s easy to assume that each unique organization will experience its own distinctive set of internal barriers that prevent Agility. However, most impediments are knowable, predictable, and can be approached in a planful way. When we become able to recognize what exactly within the organization needs changing, we can then begin our Transformation into being an Agile Organization.

Here, we’ll discuss some of the more common impediments to Agility and what an organization might look like when we overcome them:

Outdated Delivery Model

To become an Agile Organization, we must first establish a functional Agile Delivery Model. Many organizations operate “inside out” by creating project-oriented efforts that seek to keep their people busy and preserve the budget.

Instead, we need to operate “outside in,” considering what the most important things are that we need to solve in the market and what teams will be needed for it. We must also consider what capacity will be needed in the next 3, 6, 9, or 12 months and how we must operate within that. Additionally, we must build teams for resilience while we scale up and down. By doing this, we build stable teams and only spend money on the things we need to spend money on to solve a problem. What we reap is removal of dependencies in the organization and a smooth flow of work through the organization.

Product Mismanagement

Most organizations fall in one of two buckets regarding their Product Management:

• Sales-driven, order-taking, and building whatever the customer wants without considering which projects will actually move the needle
• Product owners building by directive. Build the plan, tell people what to do, and micromanage each task along the way

These methods prevent building the type of ecosystems and organizations that we want where we are learning and delegating and expanding our capability. This is not the fault of the product owner. We are placing project managers into a job with no clearly defined career path and holding them accountable to get the product out the door the way that we always have, meanwhile expecting that we achieve the Agile goals that we seek—adaptive teams that undergo dynamic learning and operate with predictability.

Do you see the problem?

We need to shift to command-by-intent. This way, we can deeply understand the customer and the markets that we’re going after. We can validate and justify our value propositions. We must be in tune with why we are trying to solve this problem, for this customer, in this market, relative to the other problems we could solve for other customers. We must connect our product management to the market and our value propositions to the delivery teams.

Inadequate Strategy Articulation

We find that Strategy for many organizations can be summarized by platitudes and slogans regarding who the organization wants to become. While these come from a good place, we can’t simply cross our fingers and hope to become what we say we can be.

Strategy is determining how we can manipulate our limited resources and capacity to achieve an outcome. Many organizations don’t have actionable strategies because they lack the ability to specifically articulate the plan. Value propositions, capability models, and OKR’s have proven to be resilient and allow organizations to have meaningful conversations about strategy.

We will fail to deliver Agility to organizations if we fail to connect our strategic goals to the tangible steps we must take to achieve them. If we cannot provide effective models for articulating strategy, we will continue working on projects that are not the most important to the organization.

Project-Focused Budgeting and Funding

Project-led funding leads to broken architectures and a lack of trust and confidence. We must move to a system that demonstrates our profitability and meets the expectations of regulators and shareholders.

Instead of a focus on Projects, we must lead with funding the Products we’re building. These changes in organizational design, development approach, team funding, operations, etc. afford an opportunity to reevaluate a company’s accounting for internal-use software and related capitalization policy.

We must clearly define and fund for business outcomes at the capability level so that investments are tied to tangible improvements. This method provides evidence of the returns generated from the investments that we have made.

Antiquated Technology & Business Architecture

To speak candidly, technical and architectural dependencies tend to be the hardest and most expensive impediments to deal with. For many organizations, the Legacy Application Technology and code base often support multiple slices of the organization and aren’t encapsulated. Additionally, the solutions architecture often doesn’t align with the product architecture, demanding that the organization orchestrate and coordinate hand-offs with other teams before getting the product pushed out. Each necessitated coordination effort creates a dependency which slows the process, creates blockages in production, and ultimately prevents Agility.

You must deploy software rapidly to respond to the market rapidly. You must be able to get things in the market safely, securely, and reliably. However, the architecture of many organizations doesn’t support this capability.

Agile Product Extraction enables us to take existing software applications and restructure them so that teams can push code into production independently. The goal is to enable teams to take an application, add features to it, and completely own the process end-to-end of getting it into production. By organizing teams in this way, and by modularizing our application software, teams become able to do their work in an Agile way that isn’t bogged down by excessive dependencies.

Compliance and Controls

We must be able to integrate compliance, controls, and auditing into our governance models and flow of work as opposed to these things being on the side. While we need independence of the review of our results, that doesn’t mean the audit and compliance regulators can’t help us plan the governance model so that they can still get what they need when they need it.

Mismatched Talent and Culture

What we often see is that we don’t know the nature of the people who should be in the positions that act as a catalyst to Organizational Agility. We cannot put people in a mismatched job, even if it is something that they desire. We cannot put people in charge of an advanced step in our Agile Journey if they are not wired to participate in the “continuous improvement game.” Our training in our organization must provide safety and understanding.

We need to be thoughtful when staffing our organizations by differentiating those who can operate with ambiguity and those who need to be stable and steady. Not everyone is capable of operating in a dynamic environment, and we must consider this fact when staffing our organizations.

Rigid Leadership

Establishing Organizational Agile Leadership is pivotal to building an Agile Organization. We must build a trustworthy system by encouraging our Leadership to become individuals dedicated to building a system that can operate the way we need it to. We must create leaders that understand the importance of functional systems and how exactly these systems will work. When our Leaders become pliable and buy into the Transformation, we create a support system that allows Agile to take hold of the organization.

Summary

An organization can’t reasonably expect to experience the benefits of Agility if they are not willing to fundamentally change their functionality to support Agile. The bad news? Most organizations weren’t built to be Agile and significant change is required. The good news? Most of the internal impediments that prevent Agility are common and can be overcome with a thoughtful and tactical plan.

Once we recognize the barriers in our organization, we can create a plan to systematically overcome each impediment to catalyze Agility when it makes sense and establish compensating controls when it doesn’t make sense so that we can better coordinate the work in a way that doesn’t impede the System of Delivery. And then, over time, we create the conditions where Agile can thrive.

Operating within your current constraints and overcoming these systemic barriers to Agility is how you become an Agile organization.