Do You Speak Agile?

Assessing the Fluency Your Agile Team(s) Need to Acquire

Agile fundamentally has 'crossed the chasm.' Its early adopters have achieved sufficient momentum to ensure its entry into the mainstream of software and IT development if not product development in general. One estimate is that between 12 and 15 million people currently use Scrum daily. And yet a keynote speaker at the recent Global Scrum Gathering in Dublin claimed that Agile is failing, providing as supporting evidence a straw poll of attendees that showed only a tiny minority thought they were reaping the full benefits of agility.

Improve your operations and optimize customer value with Agile & Scrum

I have no issue with the idea that many organizations that have adopted agile are disappointed with the results so far. But the statement that Agile has failed begs two questions. First, who put a time limit on Agile's pathway? Secondly, and more importantly, what is meant by 'the full benefits'?

The Challenge of Complexity

Let's start with the indisputable fact that many organizations are either disappointed with the results they have achieved or are struggling to generalize the benefits they have seen. There is a widely held view that Agile methods are merely about executing the development of products and services more quickly than before. "Faster.Better.Cheaper" is the mantra. According to this view, nothing outside the organization's development is affected.

The reality is that Agile transformations are, by their very nature, disruptive at some level. A mindset and cultural shift often challenge the foundations on which the organization has been built. Project governance, for example, in traditional environments, assumes predictability and is usually focused on conformance to an up-front plan and the efficient utilization of resources in executing it. On the other hand, Agile methods are optimized for use in situations where levels of uncertainty and risk render master planning useless. Exploration and experimentation with frequent and rapid feedback cycles allow the best solutions to be discovered through intensive collaboration with all stakeholders. Effectiveness, not "efficiency," is the watchword.

Where this is not understood, the outdated traditional governance protocols quickly become obstacles to Agile adoption and the rapid delivery of business value that it promises. Instead, governance methods are needed based on a team's responsiveness rather than process predictability.

Financial planning can be another issue. Many companies spend a great deal of effort planning budgets annually. The Project Management Office (PMO), or its equivalent, is given a big slice of the corporate budget for IT and software development that it, in turn, has to be allocated to individual projects. Business cases are created by answering the questions "What are we going to get?", "When will we get it?" and "How much will it cost?"  Answers to these questions at the beginning of the planning cycle are, at best, speculative guesses. Nobody knows. While the organization plans every year, its Agile teams are planning Sprints every two weeks or so. The mismatch between the two can surface painful tensions until these matters are resolved. Within the Agile framework, CSPO Training prepares an individual to navigate budget, priorities, and backlog.

table with hands and devices with the word agile on the table

Team Building

There are many aspects to achieving sustainability in Agile approaches, but the bedrock is its team model. "Team" is a much-abused term in the industry in general. Every manager I have ever met has referred to their "team" when they often talk about different individuals who report to them. A group of individuals is just that. Their aggregate performance comes from adding up their contributions. On the other hand, a team owns a common goal, and its members collaborate intensively to achieve it. As a result, their performance is greater than the sum of their parts.

Agile teams are self-organizing. They are autonomous. No one tells them how to achieve their goals. It's up to them to figure it out. As new information surfaces during development, they can respond quickly and take advantage for the benefit of their customers. No hand-off delays are waiting for management's permission to act. At the same time, Agile teams take responsibility for their decisions and are collectively accountable for them. It takes time, effort and investment to build teams like these. The process of growing the teams so that they improve continuously never ends.

But how much investment should an organization make in its Agile teams? What are levels of disruption tolerable? These are business decisions. They involve cost/benefit tradeoffs based on business goals. And not all organizations have made the decision to "go Agile" based on clear business goals. These are the organizations that tend to struggle. Addressing this challenge is the role of a talented PMI Agile Certified Practitioner.

Agility Fluency v 'Maturity" Models

My point is that Agile is not an end, but a means to an end: the more effective delivery of business outcomes. And these goals are highly situational. They vary from organization to organization and even between different departments in the same organization. So the 'full benefit' of Agile is not some absolute standard everyone should aspire to, but something entirely qualified by the business goals for Agile teams.

The question '" How Agile are we?'" is the wrong question. It raised the specter of 'maturity' models that are ghosts that should have been banished a long time ago. Instead of Agile 'maturity,' we should think about Agile fluency. Fluency is what your teams do when under pressure - the 'muscle memory' with which they react instinctively, without too much thinking. That kind of fluency requires deliberate, routine practice over time. And the kind of fluency your teams should aspire to is determined by the organization's goals.

An analogy might help here. Imagine you want to learn French. Depending on your goal, you would approach learning the language in a particular way. Rehearsing questions found in a phrase book would be enough to ask for directions during a visit to Paris for a weekend. You might learn from grammar books if you need to gain college credits. Should you wish to move to France permanently, you would probably immerse yourself in conversational French to socialize with your neighbors. In other words, you would choose your learning practices depending on your goal. No one would recommend using a holiday phrase book as your first step to deep fluency in a language. Instead, you would start practicing honest conversations from the get-go. The same applies to Agile development. From day one, the organization needs to determine its goals and then invest in the practices the teams need to achieve them.

James Shore and Diana Larsen's Agile Fluency Model is a simple but powerful tool that helps organizations identify what kind of fluency their Agile teams need. I like it because it is both team-based and business-goal driven. The model has four fluency 'zones': Focus on Value; Deliver Value; Optimize Value; Optimize Systems. At the risk of mixing metaphors, we can choose a zone like buying a ticket on a city bus. Then, depending on where you want to get to, you buy a more or less expensive ticket to the zone that includes your end destination. Likewise, different types of Agile fluency imply different levels of investment (training, coaching, tools, etc.) and different benefits. The model guides you in making these cost/benefit tradeoffs in your Agile investment plan.

Agile Fluency Diagnostics

The Agile Fluency Diagnostic tools support the model. First, a trained facilitator works with management to understand its goals and what achieving them would look like. These are then mapped to the appropriate fluency zone. Next, the facilitator runs workshops with each Agile team, collates the results and feeds back the curated and anonymized results to management, making recommendations for an investment plan. The idea is to provide a mirror for the teams to reflect on their progress and identify the top two or three things management can do to help them. These guided self-assessments can be repeated quarterly or six-monthly basis as part of an overall continuous improvement effort.

Depending on the target zone, it may be enough to get the teams to understand and apply the rules specific to Scrum or Kanban (Focus on Value). If delivering products or services at the maximum rate the market can absorb is needed, then a significant investment in engineering skills will be needed: test automation, continuous integration and continuous delivery (Deliver Value). Significant changes in organizational structure are likely to be needed if the teams require the ability to make excellent decisions about, for example, which products to develop (Optimize Value). Strategic business knowledge has to be embedded in the teams. A mere handful of teams have achieved Optimize for Systems fluency, and most of those have been start-ups. The reason is that achieving that kind of fluency would otherwise involve turning organizational culture on its head. The inertia and historical baggage that large organizations have to deal with might involve as much as a 10-year journey.

Most successful transformations have been driven by a small group of determined Agilists who take the time and effort to bring people along. They create momentum through initial success, "engage, challenge, educate and support the middle and senior managers," and seek out senior champions at the executive level if needed. Depending on the level of fluency needed, this group might be a single Agile development team or a "core team" of Agile coaches driving a more comprehensive organizational transformation. They usually need external support for a while because the challenge can otherwise be too overwhelming. The more disruptive the effort, the more extended the partnership that is needed. Existing ScrumMaster's can get the training to advance to a Certified Scrum Professional to master their skills as an Agile coach. Each of the fluency zones requires both knowledge and practice to achieve it.

Classroom-based learning is necessary but insufficient. Training, coaching, mentoring and consultancy may be required at different points, but the aim should be to build a permanent, sustainable internal Agile capability to the appropriate level. Learning Tree, with its unparalleled Agile curriculum, its cohort of highly experienced instructors and consultants, and its record of working with organizations to assess their specific learning needs, is firmly positioned to become your organization's trusted partner in this journey.


To sum up. Agile development is a means for the effective delivery of business value. Its progress can only be measured against the business goals it is being employed to achieve. For organizations feeling disappointed about what Agile has delivered for them this far, the way forward is to invest in the growth of their Agile teams. The Agile FluencyTM Model is just one tool, but a beneficial one, that can be used to identify what kind of investment is needed, what kinds of benefit to expect as a result, and what kinds of external support might be required.

Governance in Agile adoptions is discussed more fully in my blog post "Don't Let Governance Threaten Your Agile Transformation."


Lean into a more responsive development process with Agile & Scrum Training and Certification. Available In-Person, Online, or as Private Team Training!


This piece was originally posted on Feb 20, 2018, and has been refreshed with updated styling.

Chat With Us