Agile - Levels of Fluency

Last night I went to the monthly AgilePDX meeting where James Shore talked about the Agile Fluency(TM) Model.  He began by saying that there’s been an explosion in agile adoption, but there hasn’t been the same growth in the “state of the art.”  Shore said this is disappointing because he wants every team who uses agile to be able to reach the highest success.

Then he began to explain an idea of which he had recently learned through Willem Larsen’s ideas of language fluency (see www.languagehunters.org).  Language, in this case, means natural language, not a programming language. Fluency in a language means that you think in that language – it’s the language you use when you’re woken up at 2 am in a surprising way.

According to Larsen, there are four well-established levels of fluency:

1- Tarzan at the party (eg: “Me want drink. Food”)

2- Getting to the party (eg: “The party is at 8pm, on West 3^rd Street”

3- Discussing the party (eg: “What wonderful hors d’oeuvres! I loved Caroline’s dress”)

4- Charley Rose (eg “Speaking of parties, what is the trend this year in centerpieces?”

(those are my examples).

Each level of fluency is useful, although there are greater nuances and capabilities as you reach higher levels.

Shore then suggested that there might be similar levels of fluency in Agile development practices:

Level 0- We build code (but we’re not agile)

• Domain driven design
• Programming
• Database design
• Configuration management
• Testing

Level 1- We create value (on a daily basis)

• Iterations
• Stories
• Estimating
• Planning game

Level 2- We deliver value (as often as our market can accept it)

• "Done done”
• Slack
• Risk driven architecture
• Velocity
• Continuous integration
• Risk management
• Test driven development
• Daily standup
• RABU charts

Level 3- We optimize our value

• Customer discovery
• Purpose
• Concept of “minimum marketable features”
• Last responsible moment
• Effect mapping
• One at a time
• Adaptive planning

Level 4- We optimize our organization (the work is done where it’s needed, not necessarily your assigned tasks)

• Systems thinking
• Lean startup
• Value-stream mapping
• One-piece flow
• ???

Shore worked with Diana Larsen to create the levels, grouping them according to how they’ve seen companies adopt agile development practices. Shore says that in his experience as a consultant most teams he sees are at level 1.  Level 2 is what people think of when they think “Agile,” and consultants are selling the idea of level 3 (although most teams are at level 1). 

In order to move from one level to the next there are certain changes which must occur. To move from level 0 to level 1 means changing your mindset so the team focuses on stories and value, which can sometimes be an eye-opening change.  Moving from L1 to L2 is another change, although slightly more nuanced: the concept of continuous integration, and metrics that allow you to predict development.  Moving up to L3 requires a paradigm shift at the management level of the organization, while L4 means organizational change.  Clearly an organization can’t jump to L4 without each employee becoming fluent in all of the earlier levels.

At this point in the talk we split into groups.  Everyone in the meeting had indicated (a) which level they thought their organization was at, (b) which level they’re working toward, and (c) which level they ultimately hoped for.  It was interesting that most people thought they were at level 1, were working toward level 2, and ultimately hoped for level 3.  That meant that most people didn’t aspire for a fully agile organization – just having a portion of the organization agile was sufficient.

Each group was centered around the level of fluency they hoped to achieve.  In my group, level 2, we talked about continuous integration, “done done,” and test driven development.  Originally I had thought that my development team needed to work more on test driven development, but as we talked, I realized that we’re already working on continuous integration (although we don’t call it that), and that we should continue to work on that until we’re fluent.

Shore then wrapped up the evening by asking us to reflect on what we’d discussed, and to write down one thing to bring back to our organizations. Although I want to explore test driven development (TDD), I’m committing to working on improving our continuous integration until we become fluent in that Agile practice.

Some thoughts about the presentation: It was nice to see a road map of goals for achieving the Agile Fluency (tm) model. Often people talk about agile, and I feel like I’m in a mist, where their concepts appear to be in one spot, then suddenly swirl to another. Laying out the road map this way also provides a common set of terms.  RABU, for example, was a term I hadn't heard before.

On the other hand, I was reminded of a class I had in 1999 on customizing the Capability Maturity Model (CMM) for your organization. Many people in the class seemed to think they could pick & choose the aspects of the model as if moving through a supermarket, which is not the case. In the long run both Shore’s Agile Fluency(tm) model, and the CMM have the same underlying restrictions: In order to achieve the highest levels, individuals and leaders must commit to internalizing – becoming fluent – in the earlier levels of the model.  It’s not enough to say “we’re working toward level three of the Agile Fluency (tm) model,” unless you have internalized levels zero, one and two for both the individuals and the organization.

You can read more about the Agile FluencyTM Model here at Shore's website.

Related articles

• Agile Maturity Model - 3 Different Approaches (setandbma.wordpress.com)
• CMMi - Capability Model (seeingfuture.wordpress.com)
• My Top 10 problems with using Scrum (mxmossman.blogspot.com)