I hadn't heard of Agile Fluency until a few days ago. I had recently joined AgilePDX (our local Portland group of folks interested in all things agile) and the email reminder came in about the monthly evening talk. Jim Shore and Diana Larsen were going to discuss their Agile Fluency model as part of the group's annual Agile Tune-up where everyone comes to think about what good goals might be for their teams for the coming year.
The fog was thick outside. As bad as I'd ever seen it (and it proved to be as difficult to drive in as I feared). I thought about not going to the meeting, but then I googled “agile fluency” and started to read a bit about Jim's background (I hadn't realized InfoQ had named him one of the most influential people in agile for 2012: http://www.infoq.com/news/2012/04/agile-influential-people). Then I read the article. Then I realized I really needed to go – this was going to be interesting.
I won't recap the article, you can read it here: http://martinfowler.com/articles/agileFluency.html. I won't recap the meeting, Moss Drake did a great job in his blog the next day: http://mxmossman.blogspot.com/2012/01/agile-levels-of-fluency.html (though I'll mention to him that it's really 2013 now). I'll presume you've already popped those links into a new tab and skimmed them. No? Go ahead, I'll wait.
Okay, just in case you didn't go read, I'll recap a little bit (most of this is in the article, some of it embellishments from the meeting): Jim and Diana discuss a team's path through agile fluency (based on their extensive experience in the space and with many teams), giving each level a star:
With no stars, you can be effectively building code. You write stuff based on specs others give you and it mostly comes out fine. You're not agile and you may not care.
With a team culture shift, you can reach the one star level, focusing on value. You are likely using Scrum or Kanban and working with User Stories and doing some estimation and you see your progress in terms of business value. You're probably hitting most of your iteration goals but you are not necessarily continuously delivering and your scope is just your own backlog. These are the Agile Fundamentals.
With a team skills shift, you are now at the two star level and delivering value at the market's cadence. You are capturing value and delivering it as quickly as the market will absorb it – maybe it's a web app you update every few hours or an enterprise application that delivers once a quarter, but you are delivering reliably. You are likely invested in continuous integration, thorough unit testing, perhaps even TDD, and other XP practices. This level can be thought of as Agile Sustainability and a team and product could be very successful at this level for a long time. Depending on the size of the organization, this may be all you'll ever need.
With an organizational structure shift, you get three stars and reach a point of optimizing value across the product. It's no longer just about your team or your piece of the pie but the organization has shifted to optimizing value across the product and throughout the organization. There are no hand-offs and excellent product level decisions are getting made routinely. This is “Agile's Promise” and what some refer to as Enterprise Agile.
With a complete organizational culture shift, you reach a four star level where you are optimizing for systems across your enterprise. This is “Agile's Future” and it's not clear that many organizations have neared this level yet.
What struck me most about the article is the use of the word “fluency” and how it is defined by Shore and Larsen. They draw a bright line between proficiency and fluency. Proficiency means you understand the set of practices and are capable of following them. In their words, “Fluency is how a team develops software when it's under pressure. Anyone can follow a set of practices when given time to focus...true fluency is a skillful, routine practice that persists when your mind is distracted with other things.” Like broken builds and disgruntled customers (or, here in the Pacific Northwest, the first sunny day in weeks).
I'm reminded of a saying about musicians: Amateurs practice a piece until they get it right; professionals practice a piece until they never get it wrong. For me that sums up the difference between proficiency and fluency in this context.
Having been involved in several team's attempt at agile transformation, I've seen a lack of understanding of the need for fluency disrupt the transformation. The team has had some training and faltered in their early sprints (as is common and generally expected) but they are using the retrospectives and honestly looking at what needs improvement. Then, before they reach a point of fluency, something distracts them, some disruption in the force tries to throw them off their game. And it is successful. Before they can get back on track, their manager decides (problem #1) that the retrospective meeting is worthless because nothing seems to get better – and it just sort of crumbles from there. They are now a Scrum-but team and may always remain one. Had they been given the space to reach fluency at their current level, the could have weathered this storm. Lacking that fluency, they could only return to what they used to be fluent at.
Reminds me of another saying from a different field: Under stress, you will not rise to the occasion, but default to your level of training. So your level of training needs to bring you to fluency at the things you care about and your product and team depend on.
Models like CMMI tend to focus on practices that you adopt – so perhaps you are proficient. But the Agile Fluency model's focus on fluency, not just being capable of the practice but having adopted it so completely that it's just what you do makes a lot of sense to me. I also like the model because it is not about some set of practices you have adopted or a particular metric you've hit but about who you are, how you behave. Your fluency allows you to “be” at that level – it's what your team has become, how it's focused, what behavior feeds its soul.
The article includes a nice diagram of the path as well as a discussion of the benefits, investments and core metrics at each level. It's frank about the type and size of investment required at each level. Two stars can be hard because of the breadth and depth of skills required and the level of practice to become fluent. If you work in an organization that cares about agile development, go read and share the links (and this blog if you are so inclined). The ideas are valuable and I expect you'll hearing more about them.