Richard Dolman

Richard Dolman

Richard Dolman is a pragmatic Enterprise Agility Coach and Trainer who has been practicing Agile and Lean since 2001. As a Certified Enterprise Coach (CEC) he works at all levels of an organization to help them learn and improve. He is passionate about helping companies and teams to solve critical business and technology challenges, as well as empowering and enabling collaborative, high-performing teams. His goal is to help people and organizations unlock their hidden potential.

In addition to his extensive coaching and consulting experience, Richard has held a variety of executive leadership positions throughout his career, which enables him to relate to and understand the challenges leaders are facing in rapidly changing landscape.

Richard lives with his wife in Colorado, where they enjoy spending time in the Rocky Mountains, good food and wine, as well as traveling to experience different cultures.


STATIK (Systems Thinking Approach To Implementing Kanban1 2) can be a great technique to help teams get up and running quickly, even teams that are using Scrum.

Applying the STATIK approach leverages the first principle of the Kanban method, “Start with what you do, or know, now”, in order to help avoid over-thinking how existing work, structures, and/or roles “fit” within Scrum. To be clear, I am not talking about what is commonly referred to as “Scrum-ban”. Applying this approach designed for Kanban can dramatically accelerate the forming and improvements of a Scrum team.

Systems Thinking Approach to Implementing Kanban (STATIK) for Scrum Teams.

By Richard Dolman

STATIK (Systems Thinking Approach To Implementing Kanban1 2) can be a great technique to help teams get up and running quickly, even teams that are using Scrum.

Applying the STATIK approach leverages the first principle of the Kanban method, “Start with what you do, or know, now”, in order to help avoid over-thinking how existing work, structures, and/or roles “fit” within Scrum. To be clear, I am not talking about what is commonly referred to as “Scrum-ban”. Applying this approach designed for Kanban can dramatically accelerate the forming and improvements of a Scrum team.

As a long time practitioner and coach of Scrum, I’ve observed many teams struggle getting started with the framework. Change is hard for most people and we often get resistance at first. Even though the level of change is relatively low with Scrum, it can be a challenge for some teams to get started in certain environments.

A couple of anti-patterns I see repeatedly include:

  • Management struggling with how to address new role definitions like Scrum Master and Product Owner among other aspects of the framework. This causes anxiety and distractions for teams who simply want to get started working together.
  • Teams jumping into Scrum without getting grounded on the nature and characteristics of their work or ecosystem. This often means the teams are just going through the motions and may be slow to build shared ownership of their work and outcomes.

Over the years I’ve tried a few different approaches to help teams get started. I learned about STATIK from a colleague several years ago and began applying it as a model for my Team Chartering workshops. I have used this approach to help teams form and establish norms for them to work toward–including how they will norm around Scrum.

The STATIK method helps answer the following questions:

  • What is the purpose of the team?
  • What are the products or services we provide and to whom?
  • What is the current way of working?
  • What are the sources of dissatisfaction?
  • What are the sources of demand?
  • What are our current capabilities?
  • How does work flow through the team/system?
  • What kinds of services are there?
  • How to design a kanban system that allows us to visualize and manage the work?

For the purposes of this topic, I will be referring to the “kanban system” (lower-case ‘k’) rather than the Kanban (upper-case ‘K’) method, since I’m not limiting the use of STATIK to teams implementing Kanban. The kanban system represents the elements and boundaries of the team’s work. For a Scrum team, that may include from the point an item enters their backlog until the point they declare it “done”.

Here’s how it works –

At a high level, STATIK involves the following steps:

  1. Understand ‘fitness for purpose’ and identify sources of dissatisfaction
  2. Analyze demand
  3. Analyze capability
  4. Model the workflow
  5. Discover classes of service
  6. Design kanban systems
  7. Roll out – socialize and negotiate, measure, inspect and adapt…

Using STATIK with a Scrum Team

Setting up the workshop: To make it relatable, I provide a “Story” card for each of the steps and set up a simple kanban board to visualize the activities as we progress through the workshop. For each Story, there are Acceptance Criteria that represent the activities that we will work through together and enable the team to agree on what is ‘good enough’ for the team to move forward.

This is how I design the chartering agenda

As with any team activity or workshop, it’s important to properly set the stage and get everyone connected. A simple connection exercise could be to ask the participants to consider and discuss the following:

  • What are the major characteristics of our Work, our Team, or our Process?
  • How do these characteristics impact our delivery?
  • How do these characteristics influence our decision-making?

This gets them thinking beyond just “We do ‘X’” and opens up the door for the Systems Thinking aspect of this. *NOTE: Depending on the knowledge and experience of the team, you may need to provide a brief overview of Systems Thinking3. I’ve generally found it’s not a critical barrier to running this workshop, but a little overview never hurts.

Step 1: Understand ‘fitness for purpose’ and identify sources of dissatisfaction

The intent of this step is to explore the criteria that define customer satisfaction and define the “fitness criteria” such as lead time or quality. These determine how the customer evaluates whether the service or product delivery is acceptable, or “fit for purpose.”

When working with teams that are applying Scrum, I will adapt this step (since Scrum addresses these differently than Kanban) by discussing fitness criteria, as well as conditions for success and the norms that they will need to agree on in order to fulfill their purpose. The team will create their Definition of Done in steps 5 and 6 and establish appropriate mechanisms to measure and enable customer satisfaction.

This step can be facilitated as a single story, but I tend to break it into two separate stories so that the team has a full appreciation of their current state before moving on to the next steps.


Story 1: As team members, we want to define and validate our Purpose and our ability to fulfill that purpose, including conditions of success, so that we have a strong sense of our team identity.


Acceptance Criteria

  • We have drafted a mission statement and team slogan
  • Our Values and supporting Norms are known (We believe in… Therefore we will…)
  • We have defined high-level Conditions for Success
  • We are able to serve the needs of the Customer


Story 2: As team members, we want to discover areas for improvement, what our customers and stakeholders are saying, and delivery or quality challenges we are facing, so that we can be more customer-focused and start building a backlog for continuous improvement.


Acceptance Criteria

  • We have exposed all relevant Sources of Dissatisfaction and/or things we struggle with
  • We have visibility to and understanding of Customer and/or Stakeholder feedback
  • A backlog for Improvement has been created or updated

When forming new teams, Story 1 is a great way to get teams started and centered on their team identity. Prompting questions can be something like–“Why are we being formed as a team?”,  “What do we stand for”, “How do we want the rest of the organization to view us?”.

At this first level, I try to emphasize fun and safety, keeping it light and even a little idealistic.  Things get much more detailed and analytical later, so providing engaging and uplifting conversations right off the bat sets a positive tone. During this step, I typically encourage brainstorming, but will also work in some form of diverge-converge activity to get ideas generated and shared.

A few things that quickly emerge here–introverts & extroverts, visual thinkers & critical thinkers, as well as those who “just want to start doing the work” & those who “want to feel like we’re a real team”. Don’t try to solve or fix any of that. It is, in part, what will define their norms as a team.

When working with existing teams, Story 2 may be a bit more impactful. Hopefully, there is data/feedback available from a prior Retro and directly from customers and stakeholders to leverage. If so, we will pull in the relevant data and/or feedback and go through some sort of a “reconnection” activity, asking everyone to write a few stickies (physical or virtual) for each item from the past Retro, relating to how it impacts them or their thinking.  We may do some dot-voting on items to see what people view as most important or impactful. If there is no prior feedback or data to reference, this presents an opportunity to do a Retro and seek feedback from others.

Before deciding what format would best serve the team, I probe into their norms and experiences. For example, if they’re not doing regular Retros–why is that? Or, maybe they’ve been doing them, but they don’t seem valuable or meaningful to everyone.

From here, I can then choose the approach that would be most impactful, rather than just repeating a technique they’ve seen before. One technique I find works well, in this case, is using the Sailboat/Speedboat format4. This is a great visual, metaphorical way of exploring how well, and under what conditions, a team is performing. We can glean insights and specific, practical ideas that will be used on upcoming steps.

If there is no recent customer or stakeholder feedback available, we will craft a simple survey or questionnaire that can be sent out. In this case, keep it simple, but try to create a sense of urgency so the team can get feedback quickly that they can use right away.

Step 2: Analyze demand

Story: As team members, we need to analyze sources of Demand, so that we have a shared understanding of who is requesting services/product from us and the characteristics of the items in our backlog.


Acceptance Criteria

  • ID primary (if not all) sources of demand – including from whom/where, frequency, complexity, and impact of requests
  • Understand the various characteristics of the requests and how that translates into work in progress
  • Agreement on critical gaps or risks to our ability to effectively deliver

Here we explore Demand. What are the characteristics and origins of our work? For a Scrum team, some may simply say, “we pull work from the backlog that our Product Owner has prioritized”. While this may be technically correct, we need to go beyond that to understand all of the sources of demand, as well as answering questions like:

  • How frequently does demand come to us? (known as ‘arrival rate’ in Kanban)
  • How complex is the work?
  • How much variability do we have?
  • What are our customers asking for?

I find it valuable to start with Stakeholder mapping. There are a myriad of formats, but I tend to start with a basic context diagram to visualize the team’s key stakeholders. Are they consumers or contributors, internal or external? Understanding these first two dimensions can help answer questions about how we communicate or interact, how frequently we interact, and where they fit in our overall workflow.

Once we understand Demand, we can then analyze the team’s capacity, or capabilities, to serve that demand.

Step 3: Analyze capacity

Story: As team members, we need to analyze sources of Demand and our Capacity to respond, including the skills and capabilities we need, so that we have confidence in our ability to deliver effectively and optimize our work.


Acceptance Criteria

  • ID primary (if not all) sources of demand – including from whom/where, frequency, complexity and impact of requests
  • ID our Capacity to focus on the work at hand, including the core skills and capabilities needed to deliver. (Initial Skills Matrix developed)
  • Agreement on critical gaps or risks to our ability to effectively deliver

This is another step that I will adapt for Scrum teams.  I will use one of two techniques: a) Market of Skills activity or b) Skills Matrix creation. My choice of technique depends on how I interpret the teams’ level of creativity or analytical preference.

The Market of Skills approach tends to suit teams that are more playful, open to exploration, or may have more of a “Clan/Collaborative” or “Adhocracy/Creative” cultural orientation.

Market of Skills is gamification that uses the metaphor of a market where you may sell goods. In this exercise, you are selling your skills and unique capabilities to your team members. When using this technique we may include a variety of skills beyond just the technical skills needed for the job. Someone may include musical skills or that they’re good at puzzles–this makes it fun and helps team members connect with each other on a personal level.

The Skills Matrix modeling may fit better with teams that are “all business”, very serious about their work and/or more of a Hierarchy/Controlling or Market/Competing cultural orientation.

A Skills, or Competency, Matrix activity is more direct and analytical. Step 1 is focused on identifying the technical and soft skills needed to do the work. Step 2 is to have each team member self-assess their competency level with each skill. Teams may choose how they want to reflect this–using a numeric scale (0-5), shading a quartile (see example), using symbols, etc. The key here is to encourage safety and honesty without judgment.

After each team member has self-scored, the entire team can then review the matrix and discuss the patterns they see.  Where are the gaps or weaknesses?  The team can then discuss how they will deal with that.

The bonus benefit of this technique is that the team can also use the Skills Matrix to identify knowledge sharing and cross-training opportunities. If a team member is an “expert” in a specific area where others may be novices, they may agree to form mentor-mentee relationships.

While these techniques are most commonly associated with forming new teams, I have worked with many existing teams that have never done this sort of analysis and benefit from it as well.

Step 4: Model the workflow

Story: As team members, we need to model how work, information, and decisions flow through our team/system so that we have visibility to where we will need to define explicit policies and potential bottlenecks as we design our kanban system.


Acceptance Criteria

  • Visual representation of how work flows through the team – May start with “most common” items and/or “happy path” workflow, then iterated to refine for exceptions or more rare scenarios
  • Activities that provide the most knowledge are identified
  • Tag potential bottlenecks or gaps that will need to be resolved

I often find this activity to be the most interesting and impactful, particularly for existing teams.  When I ask “Does everyone know what our process is for getting things done?” everyone usually nods and says “yes, of course.” However, once they start visualizing it, it’s not uncommon to see multiple versions emerge. It’s not that people don’t know their process or how work and decisions flow through the team. But, until they start mapping it out, they hold a bunch of assumptions and interpretations that may or may not be valid. That’s the power of collaboratively modeling the workflow.

David Anderson1 recommends asking the question, “What activity gives us the most knowledge?” I love this question. It helps the team think beyond the tasks they perform and gets into the meat of their learning and decision making. Building “why” and “how” into the system is just as important to the “what”. I encourage teams to map this into their workflow/kanban system and to incorporate it into future retrospectives.

Depending on the size of the team, we may break out into multiple, small groups (diverge), then re-group to compare and contrast. Ultimately, the whole team needs to agree on a reasonable representation of how their work, knowledge, and decisions flow through their system.  (converge).

For new teams, it’s obviously a little different. It can vary a bit depending on whether they are: a) newly formed, but experienced with the context or delivery approach, or b) new to everything – each other, the work, the context, etc. In either case, it’s more of a greenfield discovery activity and is generally done as a whole team rather than the diverge-convert approach. For new teams especially, it’s important to remind them that “perfection is the enemy of progress”, meaning we’re not going to get it perfect the first time. We just need to get it “good enough” so that we can start to do the work, then inspect and adapt as we go.

In all cases, it’s not uncommon that the team will identify multiple “what if…” or “yeah but…” scenarios. If time allows, explore those that may be critical or impactful.  For the rest, we tag those as “exceptions” and may add an item to the backlog to iterate through those in the near future.

Step 5: Discover classes of service

Story: As team members, we need to define the various classes of service that will require specific, Explicit Policies (rules), so that we are able to design our Kanban system to effectively optimize flow and give everyone awareness of the ”rules of engagement.”




Acceptance Criteria

  • Key Classes of Service are defined, including prioritization, service level agreements, definition of done, etc.
  • Team agrees on all explicit policies (rules) related to each Class of Service


A Class of Service is a set of policies which describe how something should be treated.

These definitions provide clarity on how to prioritize items as well as what and how we may handle an item, how to decide which items are more urgent–needing to be worked immediately–versus items that can wait.

A common example for a Scrum team might be to define how they handle new development work versus product support or maintenance work.

Often, the sources of dissatisfaction activity can uncover new or different Classes of Service. Teams may also need to define items with different business risk profiles that need different policies. Class of Service definitions (Explicit Policies in general) help teams deal with potential challenges from stakeholders (e.g HIPPO or WSFL challenges), as well as issues related to flow, WIP limits, and bottlenecks.

Another common definition for Scrum teams is the Definition of Done.  This is a form of an Explicit Policy and may be defined as a general definition for the team or it may vary depending on the rules or boundaries associated with a particular Class of Service.

Step 6: Design kanban system

This step is one of the reasons why I think STATIK is so effective. We don’t jump into designing the kanban system until we’ve done the discovery and analysis in the earlier steps.


Story: As team members, having now defined and analyzed the primary nature and conditions of our work, we need to design our kanban system, so that we can begin managing and improving our way of working


Acceptance Criteria

  • All Team members agree to an initial kanban system that will enable them to begin managing and improving the flow of work
  • The kanban system is visible*


Scrum teams often take the value of a well-designed kanban system for granted. After all, the Sprint is set and the Sprint Backlog is our “To-Do”, so all we need is to show “Doing” and “Done”. Right?  Well, not always. Scrum was designed to deal with complex, adaptive problems.

So, our kanban system should be a proper representation of the complexity and adaptiveness that the team needs to manage. Many teams have both new development and production support to deal with, multiple products that they’re responsible for, or multiple external dependencies that cause wait states or other flow variances. The more complexity that a team has to deal with often means they need a more sophisticated kanban system.

There is no right or wrong way to design your kanban system. I encourage teams to be creative and emphasize the things that enable flow and collaboration.

Step 7: Roll out–measure, inspect, adapt…

To close out this workshop, we do a “team priming” activity. This activity was co-create with a former colleague of mine, Daniel Lynn. He and I have paired on countless workshops and engagements.


Story: As a team, we need to be able to start doing and measuring our work and find out what our current impediments are so that we can hit the ground running and ideally be able to deploy an increment or change to production in our first sprint.


Acceptance Criteria

  • Create a flipchart or other artifact reflecting:
  • Tools we need
  • Knowledge we need
  • Environments we need
  • People we need
  • Identify and communicate impediments to delivering a shippable product increment
  • Create the team’s Technical Backlog (user stories w/ acceptance criteria)
  • Communication plan/feedback loop for stakeholders


In this step, we discuss whether the team will maintain both a physical and electronic kanban board. Most, if not all, of the electronic tools have both Kanban and Scrum views built-in. I encourage teams to maintain both a physical and electronic board (often within a tool like Jira or VersionOne) for a while to give them both the tactile and electronic experiences in parallel. It’s much easier to experiment and update a physical kanban board than to change a template in a tool.

However, given the global remote workforce trend (new normal), having a single physical board is not as feasible as it once was when we had more co-located teams. So, instead I recommend using a virtual “whiteboard” tool, like Mural or Miro, or something simple like Trello, that can be easily modified and experimented with in lieu of a physical board.

Roll it out, socialize it, experiment, and… inspect and adapt.


Whether you’re launching a new team or already working as a team with Scrum or any other approach, consider trying STATIK to see if you can gain better awareness, alignment, and visibility into how the team works.

What ideas or concerns has this article raised for you? If you’ve tried and/or adapted STATIK with your team share your experiences and insights below.

Additional Resources

© 2020 by Richard Dolman

All Rights Reserved

This article was originally published at




The recent Harvard Business Review (HBR) article “The Agile C-Suite1 and Forbes article “Agile Isn’t New: What’s New Is The C-Suite Embracing It” have prompted some good discussion around the Agile Velocity virtual water cooler.

While there is general agreement with most of what was published in these two articles, enough to elicit the ubiquitous ‘thumbs-up’ 👍, there’s a fair level of “Yes, and…”

The “Agile C-Suite” and The Critical Role It Plays in an Organization’s Path to Agility

By Richard Dolman

The recent Harvard Business Review (HBR) article “The Agile C-Suite1 and Forbes article “Agile Isn’t New: What’s New Is The C-Suite Embracing It” have prompted some good discussion around the Agile Velocity virtual water cooler.

While there is general agreement with most of what was published in these two articles, enough to elicit the ubiquitous ‘thumbs-up’ 👍, there’s a fair level of “Yes, and…”

As a coach, having worked with countless organizations and executives over the years, from fortune 100 level to start-ups, I’ve reflected on all of the patterns I’ve seen displayed by C-suite level leaders and what differentiates those that have helped create sustainable agility versus those that don’t.

With that in mind, I started to dig into these articles and relate to how we’re addressing organizational leadership with Path to Agility®. This post focuses on the HBR article–I’ll address the related Forbes article in a separate follow up post.

HBR article setup

Before digging in, it’s worth noting that this article is based on an unnamed company and its CEO, ‘Brian Johnson’. So, there are many clarifying questions I’d like to ask in order to have better context for evaluating the efficacy of the points being made, but I’ll press on with full awareness that there are underlying assumptions that might be false.

Balance from the Top

I wholeheartedly agree with the need to “create balance from the top” as a central tenet of leadership engagement. However, the case being made in this article is that “Agile is primarily for innovation”. This is common misrepresentation and limits the C-suite’s thinking and ability to fully embrace agility. Agile is about being adaptive and creating the conditions (mindsets, capabilities, environments, etc.) that allow us to respond to change. If you include Lean thinking in the definition of “Agile”, we can include seeking continuous improvement anywhere in the organization.

So, an alternate definition for creating balance at the top might be to gain an understanding of complexity, by applying the Cynefin Framework2 or a Volatility – Uncertainty – Complexity – Ambiguity (VUCA) filter, as the foundation for decision making to enable agility wherever it is needed.

Balancing the Agile Enterprise

I appreciate the concept of the “business operating system” and balancing the agile enterprise. I like the visual tool and the overall concept acknowledging that there is a spectrum of “static” to “chaotic” for various “components” of the enterprise, along with an indicator of where an “ideal agile balance point” might be–where the organization is today and the balancing direction needed to close the gap.

This is, of course, all very subjective, but it may be a valuable tool to help tune decisions and prioritize areas of need.

The so-called “ideal” balancing point is not known, it’s a hypothesis that needs to be tested and validated. It’s also relative to what is known today versus what will be known in the future. So, there is a need to keep probing for where you are and where you think you’re going.

The authors explain that in order to find the optimal balance, “the agile leadership team typically begins by creating new metrics to help determine how agile the company is, how agile it should be, whether it is moving in the right direction at the right speed, and which constraints are impeding progress.”

I may just be splitting hairs here, but in my experience, we don’t look to C-suite level leadership to create new metrics. Instead, we expect them to articulate clear objectives and a strategy that provides a mechanism to measure and communicate progress toward the transformation goals.

The first steps in the Path to Agility framework involve working with C-suite and senior leadership to define and align on their Compelling Purpose (why the organization should change).  Aligning on and prioritizing critical Business Outcomes will guide the overall strategic vision for the Agile transformation.

Then, we typically see the creation of meaningful metrics and the assimilation of empirical data at the System and Team levels, with the front-line managers and teams that are closest to the work and the data. Top-down definition of metrics often comes with a ton of anti-patterns that can undercut the organization’s ability to measure progress.

The Agile Leadership Team

In describing the Agile Leadership Team (ALT), the article states that, “Typically, the agile leadership team includes part or all of a company’s executive committee. At a minimum, it consists of the CEO and the heads of finance, human resources, technology, operations, and marketing—the individuals most critical to the components of the operating system.” 

Yes, and there are often multiple conversations to be had in order to get the right mix of leaders and influencers on an ALT. For starters, whether or not it’s feasible to include the CEO and all other C-suite level leaders likely depends on the organization’s size and complexity. In most organizations, it can be very difficult to get C-level executives to commit to the level of engagement being suggested–although I do applaud the intent behind it and agree we should strive for it.

The formation of an Agile Leadership Team (ALT) is a central component to the Path to Agility framework. The ALT is a powerful guiding coalition that has the ability to drive change throughout the organization. This is founded on John Kotter’s 8-Step Process for Leading Change3Step # 2: Build a Guiding Coalition has been proven over and over as a central element to creating sustainable change. A common pattern we encourage when dealing with large scale organizational transformations is to have a Guiding Coalition (GC) for the enterprise transformation and an ALT within each portfolio group.

Even in smaller organizations, where multiple portfolios may not be an issue but C-suite bandwidth is still a challenge, forming both an ALT and a GC in parallel is an adaptation that I’ve seen be highly successful. The ALT is composed of key leaders, as high level as possible, but is not limited to the C-suite. ALT members may be at any level of leadership and have the ability to influence and drive change. However, there may be larger organization-wide impediments or changes that do need C-level ownership. The GC is made up of the most senior leaders that are needed to deal with the highest-level, most complex changes. The GC may not be a standing agile team, but are effectively on-call to deal with challenges that the ALT members need help resolving and are ultimately responsible for ensuring alignment of Business Outcomes and Strategic Vision.

Key Points worth Elaborating

“To create a truly agile enterprise, C-suite must embrace agile principles.”

Yes, and one can argue that Agile is simply a set of values and principles, so by embracing Agile principles, you’re “being” agile. When I’m working with leaders, one of the questions we begin with is “What is Agile?”. My basic definition is “Agile is a set of values and principles, focused on teamwork, value for the customer, and adaptiveness, that provide a mindset for decision making.” So, it is important to get grounded on principles.

Unfortunately, this has become a bit of a cliché. One can embrace a principle, without really having to change anything. In principle, I believe in exercise and a healthy diet. In practice, I may avoid working out and go for an extra scoop of ice cream. Leaders need to go beyond just embracing principles–they need to also model the behaviors and mindsets they expect from the rest of the organization.


“Rather than predict the unpredictable, agile leaders build rapid feedback loops.”

Absolutely yes, and aside from setting and articulating the Vision and Purpose, the ALT’s primary role is to nurture and amplify feedback loops. This helps build an organization-wide mindset around inspect & adapt and continuous learning. When done effectively, everyone starts to feel confident that they have a voice and are in the loop, which helps support a culture of shared, collective ownership.

The article properly points out that “An agile environment has a way of challenging leaders” with a certain style or mindset, like an old-school style ‘command and control’ leader. The article goes on to say, “Agile, in short, requires humility from leaders.”

A resounding yes!, and this is where it gets messy… change is hard. Changing one’s mindset, after years of success and validation that “Doing things my way is what got me into this position”, is very long and non-linear evolution. Humility is a central characteristic of “post-heroic” leadership, which shows up as openness to change and a willingness to rethink basic assumptions.

The article concludes with – “Agile teams often cite leadership and culture as the greatest barriers to the successful scaling of agile. But most leaders aren’t fighting agile. They simply haven’t understood how it applies to their roles or how to perform those roles in ways that enhance agility.”

Yes, and this is supported by the annual “State of Agile” survey conducted by Collabnet/VersionOne –

And while I agree that most may not be fighting agile, many are likely fighting change itself, overtly or not. It’s a natural human response when faced with a threat to your norms, expertise, or status. Resistance to Change is ranked on-par with culture and leadership.

Bill Joiner’s Leadership Agility4 model suggests that only 10% of leaders have mastered the level of agility needed for consistent effectiveness. That’s the post-heroic level mentioned above. The vast majority of leaders are stuck at the “Expert” level which limits their thinking and behavior to more tactical orientation along with a lot of “I/Me” focus. For these leaders the approaches and tactics suggested in this HBR article may be reasonable–give C-suite executives specific responsibilities and tactics in order to personally embrace agility. But the question remains whether that will be sustainable and yield significant change if leaders don’t also evolve their leadership styles and fundamental ways of thinking to align with and support agility.


The journey toward organizational agility can be long and challenging. Our experience and research has shown that the vast majority of organizations who take on an Agile transformation will either experience “superficial agility” which usually results in resorting to old, ineffective behaviors, or see “pocket agility”, where some things may improve, but falls well short of the true organizational improvements needed to be more resilient. I think that is due, in large part, to the inability of leadership to personally embrace agility and at the same time create the conditions for the rest of the organization to do so.

We are able to address this with the Path to Agility, in a couple of ways.

We’ve designed the model in two primary dimensions:

5 Stages of organizational change – Align, Learn, Predict, Accelerate, and Adapt.

In our experience, these are the typical stages that an organization needs to transition through in order to achieve a sustainable Agile transformation. Each stage provides a point of reference and context for change.

As I mentioned above, change is hard and it takes time, but there also needs to be a sense of urgency. Leaders need to establish a delicate balance of urgency and patience–understanding where you are along the path and knowing what and how to respond given your relative stage is crucial.

3 Levels for development and improvement of Agile Capabilities – Organization, System, and Team.

The Organization level is where Leadership develops a modern mindset, increases visibility throughout the organization, creates alignment around vision, goals, and measured success for sustainable organizational change. C-suite leadership is ultimately responsible for ensuring outcomes and capabilities are being realized across the organization and by truly embracing an agile mindset and modeling those behaviors the rest of the organization will follow.

For each level and stage, there are a set of Outcomes and Capabilities that have been mapped and validated based on proven patterns through our collective experience leading Agile transformations. These components of the Path to Agility provide a framework and roadmap for leaders to improve transformation consistency, quality, and results.

We help leaders, C-Suite or otherwise, get started on their path by establishing an understanding of the advantages of an outcomes-based approach and taking responsibility for them:

  • Compelling Purpose – the reason(s) why the organization should change. Creating a sense of urgency, defining and communicating a guiding vision, and setting clear objectives for everyone.
  • Business Outcomes – alignment and prioritization of the core need(s) for the business. This, by definition, means we’re engaging executives from across the organization, not just within IT.
  • Rollout Strategy – establishing an ALT and a transformation roadmap, taking into account new organizational structure demands, key risks, and incremental rollout.  This also involves engaging key stakeholders and designing the mechanisms to measure progress, then empowering action at the System and Team levels.

This framework provides leaders and organizations with clarity and confidence as they take on the challenging work needed for organizational agility.

Closing Questions

If you’re a C-suite or senior-level executive leader –


  • What are the keys to your ability to internalize and model agility?
  • What are the primary impediments to embracing or sustaining agility?
  • How can you create the environment where change is enabled?
  • Do you have a support system, a peer, a mentor, or a coach?


If you’re a front-line Manager or Coach –


  • How do you get C-suite level leadership to go beyond simply ‘supporting’ agility to actually being the embodiment of it for the whole organization to see and follow?
  • What are some obvious impediments to this that we’ve seen and/or solved?
  • If you put yourself in the shoes of a C-suite Executive, what ideas can you take action on?


Reach out if you’d like to discuss or debate any of the ideas or perspectives shared in this article.


  1. Darrell K. Rigby, Sarah Elk, and Steve Berez Bain & Co. – HBR article May-June 2020 (
  2. Dave Snowden – Cynefin Framework (
  3. John Kotter – 8 Steps for Organizational Change (
  4. Bill Joiner – Leadership Agility (



© 2020 by Richard Dolman

All Rights Reserved

This article was originally published at


About Best Agile Articles Project

Best Agile Articles is a collaborative project of the Agile community to bring you the best of the best publications each year. Our goal in publishing these yearly editions is to cull through the many articles that are published each year and provide you with a curated set of high-quality articles that capture the latest knowledge and experience of the agile community in one compact volume.
Our purpose is twofold. First, we understand that it’s hard to figure out where to go when looking for ideas and answers. There are thousands of blogs, videos, books and other resources available at the click of a mouse. But that can be a lot to sort through. So, we thought we could be of some help. Second, we wanted to bring some visibility to many people who are doing outstanding work in this field and are providing helpful resources. We hope that this publication will help them connect to you, the ones they are writing for.
Our intention is that this publication is to be by the agile community as a service to the agile community and for the agile community. With that in mind, we pulled together a great group of volunteers to help get this work into your hands.

The articles in this volume were selected by:
• A diverse Volunteer Committee of sixteen people with expertise in a variety of areas related to agile.
• The agile community. A call for article nominations went out in early 2020 and several dozen 2019 articles were nominated by the community.

The articles themselves cover a wide variety of topics including organizational structure, culture, and agile leadership. There is something for almost everyone here. All editions of the Best Agile Articles publication are available on Amazon and free to download on the Best Agile Article site.
We are thankful for the great participation by the agile community at large. If you would like to participate in delivering this publication in future years, we would welcome hearing from you.

Subscribe To Our Newsletter

Get notified about new blog posts, classes, discounts, and more!