A Framework for Assessing Organizational Agility

It seems that everyone you talk to these days is “agile,” but what exactly does that mean? What started out as a software development methodology nearly 2 decades ago has now spread and expanded to almost every part of the organization.

Even in the original manifesto, there were multiple dimensions (values and principles) of agile discussed. Overlay that on the relevant dimensions of the modern corporation and you quickly have multiple overlapping and sometimes conflicting elements. As a leader trying to make your organization agile it can be very confusing to even know where to start.

This article takes a look at common organizational building blocks in the context of organizational agility that expands beyond the original intent of software development. It is not an attempt to interpret the Agile Manifesto or comment on processes like Scrum or Kanban.

To help clarify agile and better understand how you can identify areas of opportunity in your organization, consider this frame:

Each of these areas has a role in agility and more importantly they don’t exist on separate islands. Getting these components to work together in the right way is really the key.

Fundamentally, being agile is about how quickly you can respond to something in the right way

and depending on what you do, that will mean different things. So there’s no single universally accepted definition of “agile.” You need to define agility for yourself based on what you do and what you want to be able to respond to. Take a look at the following examples and define what agility means for your organization.

Example definitions of “Agility”:

Once you’ve determined what being agile means in your specific situation, take a look at it against the above framework to identify gaps that must be filled, connections that must be made, and behaviors that must be changed.

The remainder of this article takes a more detailed look at the above dimensions of agility, as well as some key questions that may guide you through the thought process.

Processes, Systems, and Tools

An organization’s processes, systems, and tools define how individuals and teams perform the work that they are assigned and thus, are specific to the type of work and the organization they are used within. The primary goal here is to support the workers such that they can perform high-quality work in an efficient and effective manner.

For example, companies that develop new products typically have Product Development and Project Management processes. These in turn, may refer to a document management system, as well as various Engineering Test tools. Other examples may include:

Generally speaking, the more prescriptive the processes, systems, and/or tools the less agile the organization will be. This is not to say that highly structured and specific processes are always bad. For example, when manufacturing a life-saving drug it’s very important that each dose is exactly the same and meets the approved specifications. However, on the other hand if you’re doing creative work like designing a retail store “customer experience,” then being constrained to following detailed checklists, procedures, workflows, etc. will limit your flexibility in creating the best overall solution.

Companies often fall into the trap of trying to write a procedure for everything. This is especially true after something goes wrong, as they surmise that if there was a better procedure the problem won’t occur again. This may be true, but has a few potential unintended consequences:

1. By constraining the work process, you limit the final solution (see above)
2. Your team members stop thinking as they’re continually told to “just follow the procedure.”
3. Capability and skill development – the training of team members to truly understand the work expected of them, falls off the priority list as “no longer needed” because procedures are in place, i.e. the workers don’t really need to understand the job if they have been trained on and understand the procedure (see section in this article on Capabilities).

Organizational agility requires team members to be good critical thinkers. When asked to quickly shift directions they must assess the new situation and adjust their work accordingly. If all they can think of is “that’s not what the procedure says,” then you’re in trouble.

 You can’t "proceduralize" agility.

Key questions to ask yourself regarding agility and organizational processes, systems, and tools:

• Are your processes at the right level-of-detail for the work being performed?
• Do your processes require authorization or sign-off at various points? Is that authorization at the right level? (see section in this article on Decision-Making).
• Is the work being performed more routine in nature or does it require more cognitive thought?
• Are your processes supporting or constraining the team’s ability to apply critical thinking? See How to Balance Process Intensity with Creative Freedom.

The tools and processes that an organization uses must be aligned with the individuals/teams performing the work, as well as their overall capabilities, so go as light as possible while still being able to keep things under control.

In the context of agility, if your choice is to create a new procedure or train your people/teams, the better long-term investment will be in your people/teams.

Decision-Making

Depending on the size and complexity of the organization, there may be many layers of decision-makers. The more layers, the more complex the decision-making process becomes and the longer it takes. You obviously want to make the right decisions, but in the context of agility, you also want to make them quickly.

Think about Company A that takes 2 months to make a decision and Company B that makes it in 2 minutes? Which are you?

Organizations like Company A have developed a culture of non-accountability where it’s not really clear who’s accountable for what. Therefore, decisions can’t be made at the individual or team-level and generally have to be pushed up to some type of management committee. Like a court, it takes time for the committee to even hear what the question is that they need to decide on and of course, once in committee it churns much longer than necessary.

Organizations like Company B have clarified decision rights at every layer along with corresponding expectations for accountability. Once made, the organization rallies around the decision, moves forward and rarely second-guesses it.

It’s a balancing act. To decide whether or not to pull the trigger on a $5 million investment probably does warrant bringing it to a committee of senior managers and tough, constructive debate should be expected. However, to decide to change a flat-head screw to a phillips-head inside the guts of a new product being developed should not require 11 signatures on the change request form when probably 1 would suffice.

Try mapping out the types of decisions your organization makes, the volume of each type, and who makes them.

In agile organizations, the high volume of routine, day-to-day decisions are made by the respective individuals, whereas there’s a low volume of strategic decisions that are made by management.

As management (at any level) gets more involved in decisions at the individual or team level, the less agile the organization will become.

Key questions to ask regarding agile decision-making:

• Is it clear who can make what type of decision?
• Do you have a culture of revisiting decisions after they’re made (and reversing them)?
• Are decision-makers, either individuals or committees, held accountable for their decisions?
• What is preventing you from pushing decision-making down from the management-level to the team-level? Or from the team-level to the individual-level?

Everyone has heard the saying to push decision-making down to the lowest possible level, but that’s easier said than done. You want the decision-maker, especially at the lower-levels, to make the right decision. This means setting them up for success and then holding them accountable.

When deciding on who should make what type of decision, consider:

• If the decision-maker has the right experience and capabilities (see section in this article on Capabilities).
• If they have access to the pertinent information necessary to make the best decision. Decision-makers higher up the ladder tend to not be aware of the details, but do see the impacts from the horizon that often need to be factored into the decision, while lower-level decision-makers may not even be aware of those factors.
• How you will empower and support the next level down to make the right decision.
• The consequences of getting the decision wrong. Most decisions don’t have a clear right answer, there are gradations. In hindsight, even when you see that the original decision wasn’t optimal, the lessons-learned for the individual and organization are still valuable for the long-term.
• Clarifying to the decision-maker how they will be held accountable for the results of the decision.

Also, don’t get too fixated on getting each and every decision exactly right. This mentality makes people uncertain and more likely to escalate the decision even when they are qualified to make it. Agile organizations have good decision-making across a large number of samples and over the long-term – they know that mistakes will be made, but are agile enough to learn and recover from them. 

Teams

Teams are groups of individuals. In the case of projects such as product development, IT, or process improvement, this would be known as the project team. In the case of operational areas like manufacturing or service, this would be the team of people doing the work of manufacturing or servicing the company products.

Aside from their specific work goals, high-performing teams:

• Bring together people of complementary skills to accomplish something beyond what any could accomplish individually.
• Develop a clear, shared vision of the team’s short-term outputs and long-term outcomes.
• Create a realistic plan for achieving the vision.
• Hold each other accountable for high-quality results.
• Do their work in a respectful, supportive, and sustainable way.
• Are continually learning.
• Maintain a laser-focus on achieving the work goals.

Agile teams are able to pivot from working on A to working on B in a quick and efficient manner. To a great extent this is related to the size of the team. It’s well documented that small start-ups are more agile than huge corporations. However, if you peel back the onion and look inside of the large corporation to an internal team that’s the same size as the start-up, would it be just as agile? Maybe, but probably not?

Consider the start-up versus large corporation analogy. In the start-up there’s 10 people sitting around the same table, they have very specific skills, but also a broad enough understanding of what everyone else is working on so that their work can be integrated into the whole. If the work shifts into a new direction, the team and each individual quickly understands the impact of taking this new direction and adjusts accordingly. The start-up mentality is that if the company succeeds then I will as well, so we better figure out this new direction fast!

In the large corporation, there are 10 people sitting in different corners of the campus or maybe in different cities around the globe. They also have very specific skills, but lack both a broad understanding of the overall work, as well as the desire to obtain one – because, for the most part they are rewarded for being an expert in a very specific skill area, not necessarily a collaborator or team member. When the work pivots to a new direction, everyone is confused, progress grinds to a halt, and a lengthy re-start process is needed to get going again.

In high-performing, agile teams, the individual players have figured out how to collaborate in an effective way. You can’t dictate that the people shall collaborate, you can really only motivate them to do so. When thinking about how you’re going to motivate individuals to collaborate as a team, consider:

• Everyone wants to know “what’s in it for me.” WIIFM is a powerful motivator at the individual level. The beauty is that WIIFM will also translate to the team level, but only if each person is clear on it and bought-in individually first.
• “What’s in it for me?” is not the same as “what’s in it for the team or organization?” For some individuals it may be the same, but for others not. Don’t assume.
• Hopefully, “you get to keep your job” is not your only answer to the WIIFM question.
• Personal learning and growth are good motivators.
• People want to be successful, so seeing a path to success is a great motivator

In addition to what motivates collaboration, think about the obstacles to collaboration:

• Collaboration takes time. Individuals need the bandwidth to be thoughtful and collaborate.
• People may see the collaboration as a “necessary evil” rather than a value-add, i.e. they are “giving,” but not “getting.”
• They don’t feel that they or their collaborator has the right skills/capabilities to be successful. Put the support mechanisms in place to help individuals see how they can be successful individually, and by extension the team can be successful.
• Physical co-location of team members is proven to work.
• Work-from-home and geographically dispersed teams are the future trend so additional time, new technology, and new behaviors must be adopted.

Key questions to ask regarding agile teams:

• Does the team have clear direction on what they should be doing?
• Is the team empowered to make decisions regarding the work that they do (see section of this article on Decision-Making)?
• Do team members have the capability to do their work or pivot to new work (see section of this article on Capabilities)?
• Is the team size proportionate to the work being done? i.e. are you beyond the point of diminishing returns with regards to adding another team member?
• Are team members collaborating at the level that you want?
• Do the team members have access to the right information to make good decisions?

Capabilities

Capabilities can be thought of at the organizational level (e.g. manufacturing capability), at the team-level (e.g. a project team), or at the individual-level. In any case, capability is about having the skills, training, experience, coaching, education, etc. to effectively do the work being asked of you.

Note that capability is different than capacity. The former is about your ability to do something, whereas the later is about whether or not you have the time available to do it. So to do a good job you need both capability and capacity. However, we often merge the two together when trying to get something accomplished, i.e. we first look for who’s available (has capacity) rather than who’s capable. Remember the old project management saying that availability is not a skill.

Availability is not a Skill

In the context of agile, not only do you need the capability to do your current work, you need the capability to do the work you may be asked to pivot to.

Since talent development or acquisition is somewhat of a long-term process, agile organizations anticipate where they may pivot to in the future and plan capability development accordingly. They are proactive in this respect versus reactive.

Developing the individual and team capabilities needed to make organizations more agile is becoming a lost art. As organizations and teams are asked to pivot to a new direction (and be agile), the managers typically jump into the fray to make things happen rather than the individuals. This approach may or may not be successful, but it’s certainly not sustainable. It also has the unintended consequence of subverting the overall capability development needed to support long-term agility, since managers spend their time solving tactical problems instead of developing strategic capabilities in their teams.

Key questions to ask regarding agile capabilities:

• Do your teams have the right capabilities to do their current job? An adjacent job?
• Are you proactive or reactive in terms of capability development/acquisition?
• Are teams/individuals rewarded and motivated to collaborate on the big picture or become experts in very specific areas? (see section in this article on Teams).

Developing new individual or team capabilities is somewhat of a multi-step process.

1. Identify the capability gaps. To do this, think about what your teams are being asked to do now and what they may be asked to pivot to in the future.
2. Provide training. This could be reading, an online course, a classroom workshop, etc..
3. Provide support. Often times training topics will sound perfectly logical while in the workshop with an expert instructor, but then get murky when the individual tries to apply the topic in a real-world situation. Ensuring that there is a local expert available to individuals/teams to act as a sounding board, answer questions, and provide general coaching goes a long way toward solidifying the capabilities learned in the training.
4. Have the individual/team apply the new capability knowledge as soon as possible. It’s well known that people forget what they don’t apply, so find real-world avenues for application and insist that they use the newly acquired capabilities.
5. Review, measure, and provide feedback on their outputs. Remember that people pay attention to what is measured, so if you want them to really use what they’ve been trained on then you need to measure them on it and hold them accountable for results.
6. Go back to step 1 as necessary.

When senior-management models capability development and makes it an expectation with their direct reports, it cascades down to next level and next until it’s part of the organization’s culture and DNA. More specifically, organizations that are great at developing employee capabilities put mechanisms in place to motivate (functional) managers to make capability development a top priority (see section in this article on Organizational Structure).

Organizational Structure

The way organizations are structured influences how they perform work and thereby how agile they can be. In the context of agile organizations, you want to have the flexibility to reorganize quickly to respond to new needs. Generally speaking, the more complex the organizational structure, the less agile it will be. (i.e. can someone who works closely with a function or even within the function, describe its organizational structure and how works gets accomplished? or is it more like “I never know who to talk to?). In multi-dimensional organizational structures with many dotted-line reporting relationships everyone has too many bosses to be agile. Satisfying one or two bosses is possible, satisfying three or four is much more difficult.

Most organizations are set-up as a 2-dimensional matrix with the functions/departments on one axis and projects on the other axis where:

• Functions – are groups of people of similar skills, e.g. Production, Software Development, Business Analysis, Graphic Design, etc..
• Projects – are cross-functional efforts to create something new, change something, deliver a specific output, etc..

Complex, value-added work gets done and agility is achieved by (cross-functional) project teams, not the functions/departments themselves. This means that teams must be allowed to organize themselves in the right way to perform the necessary work at hand and project decision-making should reside with them rather than in the functions, which is the opposite of how most organizations operate.

The typical matrix organization is set-up so that the power resides with functional managers who “loan” resources to project teams (based on their assessment of the necessary capability and capacity needed) and reserve final decision-making on project decisions to themselves rather than their delegate. The project manager, if there is one, typically has little formal authority and must rely on influencing skills to move the project forward.

The irony is that as functional managers spend more of their time getting involved in tactical project-level decisions, they are letting employee capability development fall by the wayside (see section in this article on Capabilities).

Shifting the (primary) focus of functional managers from tactical project decision-making to capability development is key to developing long-term organizational capability and by extension, agility.

However, this isn’t necessarily the fault of functional managers as there are usually logical reasons for them to wade into the details of projects:

• They have the most experience and knowledge so it’s much faster if they do something themselves versus coaching one of their employees on how to do it.
• Projects have high visibility, so it makes sense career-wise to be seen as being part of important project decisions that are recognized immediately.
• Developing employee skills and capabilities is low visibility and results may not be apparent for months or years, so there’s typically no immediate recognition.

In order for functional managers to let go of their involvement in projects and focus on capability development, they need to see the value-add, as well as be recognized, measured, and compensated for being great at capability development. Once this happens, the conflict between project managers and functional managers will subside and overall agility will increase.

In project management language a:

• Weak Matrix – is when the functional managers have more organizational power than the project managers.
• Balanced Matrix – is when the functional managers and project managers have about equal organizational power.
• Strong Matrix – is when the project managers have more organizational power than the functional managers.

Assuming that you’re starting in a weak matrix structure, you’ll get the most gains in terms of organizational agility as you move to a balanced matrix.

One final note on organizations – as roles shift, i.e.:

• Functional managers shift from tactical decision-makers to capability developers
• Project managers shift from influencers to leaders

You may find that the people who are currently holding the functional manager and project manager roles need to have their skills upgraded as well to fulfill the new expectations.

Key questions to ask regarding agile organizational structures:

• How many “bosses” (direct or dotted-line) do people typically have?
• Are you a weak, balanced, or strong matrix?
• Are managers in the organization spending more time on getting work done or developing the capability to get work done?
• Are your functional managers and PMs the right ones to move the organization toward agility?

Leadership

Leadership is a broad topic, so let’s peel back the layers a bit. In the case of organizational agility, i.e., ensuring that your organization becomes more agile, there’s really two types of leadership involved — the leader who runs the organization (e.g. the CEO, VP, or company owner) and the leader of the journey toward agility (e.g. the transformation project manager). Let’s start with the former.

The buck has to stop somewhere and that’s usually at the top, so while the delegation of responsibilities to subordinates is a key trait of effective leaders, the implementation of a key strategy like improving organizational agility is not something to delegate. The troops will sense it if the top leader is disengaged, which is not inspiring.

First and foremost, you have to set your organization up for success. It’s not fair to ask the team to do something without providing the support, training, resources, tools, etc. to be successful. Start by creating your own definition of agility – in an emerging area such as this, without clarity no one will be on the same page. Once established, repeat the definition often and embed it into your narrative. Refer to the examples of how agility could be defined in different business situations presented in the first section in this article.

Second, look at the key elements discussed in this framework and do your own quick gap analysis. After a candid assessment, identify the significant gaps that need to be addressed.

Key questions to ask regarding agile leadership:

• Does everyone involved understand what agility means to you, as well as how it impacts the company and themselves? Leaders are typically good at communicating strategy, but that doesn’t necessarily mean that people understand it and have internalized it. Instead of asking employees if they can recite the organization’s definition of agility, ask them to tell you how their day-to-day work will contribute to or be impacted by it. As people start to see the positive impact of the vision on them personally, bottom-up demand and further momentum is created.
• Are mechanisms in place to reward team performance rather than just individual performance? Agility is almost always cross-functional in nature which means that success largely depends on people being motivated to work together rather than individually. Take a close look around and ask yourself “are my employees more motivated to work as a team or individually?” (see section in this article on Teams).
• Individual career advancement and financial motivations are often intertwined with human resources (HR) procedures. Are HR policies and procedures supporting or obstructing the transformation toward agility?
• Have you defined your expected outcomes, short-term and long-term, as well as how they will be measured?

Instead of asking employees if they can recite the organization’s definition of agility, ask them to tell you how their day-to-day work will contribute to or be impacted by it.

Organizational agility isn’t something that happens overnight – it must be looked at as a journey from where you currently are to where you want to be. This may seem obvious, but to do this you need to know where you are today, as well as where you want to be. Will you learn and change direction along the way? Yes, in fact it’s likely, but directionally you want to be going the right way at the start.

Don’t assume that just because something’s important to you and your team is working on it 24/7, that anyone outside of that bubble knows about it. Strong leaders are great communicators!

This brings me to the second type of leader, the transformation project manager. The journey towards agility should be treated as a project with a project manager, schedule, resources, metrics, milestones, stakeholders, status reports, governance, etc..

Leading an agile transformation is much different than leading an IT project or a product development project and thus, while foundational knowledge of project management is required, the PM’s strengths need to reside in a firm command of business acumen, organizational politics, stakeholder management, and how things generally get done in the company. Assigning even the best available (traditional) PM may not work?

Agile transformations are big efforts that require senior leadership. While the sponsorship comes from the highest-level, e.g. the CEO, the tactical leadership should also have executive-level visibility. For example, consider having a VP-level business leader partner with a senior project manager on transformation leadership. The former brings the necessary business insights and the latter the discipline to move the effort forward.

Once the project leadership is established, one of the first orders of business is to put together a project plan and a communications plan. These plans are an important step in setting organizational expectations on what will be happening, when, by whom, etc., and by extension establishing leadership credibility, i.e. these guys know what they’re doing.

Key questions to ask regarding the journey toward agility:

• Has a business executive been put in place to co-lead the transformation?
• Has a project manager been put in place to co-lead the transformation?
• Is there a plan or what are the steps to creating one?

Summary

Creating an agile organization is no simple task that can be checked-off in the next few months. It’s not about a new technology, writing new procedures, a 3-day workshop, new roles & responsibilities, or a new org chart – although they are all part of it. Furthermore, achieving agility is very specific to the organization at hand, so while we can think of the six overall “levers of agility;”

• Processes, systems, tools
• Decision-making
• Teams
• Capabilities
• Organizational Structure
• Leadership

Whether or not you push or pull on each lever, how much, in what sequence and when - is all part of your individual journey to transform into an agile organization.

This article was originally published at https://garylchin.com/a-framework-for-assessing-organizational-agility/

By Gary Chin, VP of Client Solutions, Action for Results, Inc, MedTech Product Development Consultant & Coach

Connect with Gary at linkedin.com/in/garychin