Last night I went to the monthly
AgilePDX meeting where
James Shore talked about the
levels of fluency in Agile. 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).
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 agile fluency. 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 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 model,” unless you have
internalized levels zero, one and two for both the individuals and the
organization.
You can read more about Agile fluency levels
here at Shore's website.
. Brooks' assertion is that "adding manpower to a late software project makes it later." I've seen many software projects where well-meaning managers attempt to speed it up by adding more people. Part of Brooks's thesis is that adding more people requires more overhead in the form of training and communications, but there's also the instability of a system under change, the baggage that each person brings to the project, and the hard reality that any complex system will have a certain number of errors.
