Assessing the Fluency Your Agile Team(s) Need to Acquire
Agile has apparently '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. In fact, one estimate is that currently between 12 and 15 million people 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 small minority thought they were reaping the full benefits of agility.
I have no issue with the idea that many organizations who 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 much 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 so far, or are struggling to generalize benefits they have seen across the organization. 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. Nothing outside of development in the organization is affected, according to this view.
The reality is that Agile transformations are, by their very nature, disruptive at some level. There is a mindset and cultural shift involved that often challenges 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. Agile methods, on the other hand, 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 a hindrance to the rapid delivery of business value that it promises. Governance methods based on a team's responsiveness rather than process predictability is needed.
Financial planning can be another issue. Many companies spend a great deal of effort planning budgets on an annual basis. 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 are we going to 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 is planning on a yearly basis, its Agile teams are planning Sprints perhaps every two weeks or so. The mismatch between the two can surface painful tensions until these matters are resolved.
There are many aspects to achieving sustainability in Agile approaches but, to my mind, the bedrock is its team model. "Team" is a much-abused term in the industry in general. I think every manager I have ever met has referred to his or her "team" when, very often, they are talking about different individuals who report to them. A group of individuals is just that. Their aggregate performance comes from adding up their individual contributions. A team, on the other hand, owns a common goal and its members collaborate intensively to achieve it. Their performance is greater than the sum of their individual 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 are able to respond quickly and take advantage for the benefit of their customers. There are no hand-off delays 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. And 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 levels of disruption are tolerable? These are business decisions. They involve cost/benefit trade-offs 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.
Agility Fluency v 'Maturity" Models
My point is that Agile is not an end in itself, 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. The 'full benefit' of Agile is not some absolute standard that everyone should aspire to, but something that is completely qualified by the business goals that are being set for Agile teams.
The question '" How Agile are we?'" is the wrong question. It raised the spectre of 'maturity' models that are ghosts that should have been banished a long time ago. Instead of Agile 'maturity', we should be thinking in terms of 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 goals of the organization.
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. If, however, you needed to gain college credits you might learn from grammar books. Should you wish to move to France permanently, you would probably immerse yourself in conversational French so that you could socialize with your neighbours. 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. You would start practising real conversations from the get-go. The same applies to Agile development. The organization needs to determine its goals, and then invest, from day one, 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. There are four fluency 'zones' in the model: Focus on Value; Deliver Value; Optimize Value; Optimize Systems. At the risk of mixing metaphors, we can think of choosing a zone like we are buying a ticket on a city bus. Depending on where you want to get to, you buy a more or less expensive ticket to the zone that includes your end destination. Different types of Agile Fluency imply different levels of investment (training, coaching, tools, etc.) and different benefits. The model gives you guidance in making these cost/benefit tradeoffs in your Agile investment plan.
Agile Fluency Diagnostics
The model is supported by the Agile Fluency Diagnostic tools. 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. The facilitator runs workshops with each of the Agile teams, 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 that management can do to help them. These guided self-assessments can be repeated on a 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 say, 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 an 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 with them. They create momentum through initial success, "engage, challenge, educate and support the middle and senior managers"(2) and seek out senior champions at executive level if needed. Depending on the level of fluency needed, this group might be a single Agile development team, or it might be a "core team" of Agile coaches driving a wider organizational transformation. They normally need external support for a while, because the challenge can otherwise be too overwhelming. The more disruptive the effort, the longer is the partnership that is needed. 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 strongly 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 very useful 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." https://blo.learningtree.com/
(2) As Dan North puts it in his blog, "In Praise of SWARMing" https://dannorth.net/2018/01/26/in-praise-of-swarming/amp/
Advanced Certified Scrum Master (A-CSM) Training