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 3rd 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).
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.
You can read more about the Agile FluencyTM Model here at Shore's website.
