Proficiency and Fluency in Self-Organization
Ever since I experienced the “Where Are Your Keys” language fluency game with Willem Larsen, I’ve been thinking about how to apply the concepts to learning other than languages. One of the fascinating concepts I gleaned from this game is the separate dimensions of proficiency and fluency. The proficiency scale that Willem uses is based on the ACTFL guidelines of Novice, Intermediate, Advanced, & Superior. Willem gave a memorable colloquial description of these guidelines in relation to a party:
- Novice: Tarzan at the party. Memorized phrases that can communicate simple needs in the moment. “Beer good.” “Where is the bathroom?”
- Intermediate: Going to the party–directions, time. Interactive, task-oriented or social situations. “May I go with you to the party?” “What time should we meet?” “How will we get there?”
- Advanced: Discussion about the party. Can handle a broad range of concrete topics. Think of the level of a Larry King interview. “Who was at the party?” “What was the most interesting thing?” “Why did they say that?”
- Superior: Philosophizing about parties. Able to converse about abstract topics. Think of the level of a Charlie Rose interview. “Why do we find parties fun?” “What purpose do parties serve in the survival of the species?”
Fluency, on the other hand, is a different dimension. Fluency describes how facile we are at speaking or understanding. We might be fluent at the intermediate level, but not very fluent at the advanced level.
A recent discussion about the Agile Skills Project gave me the impetus to try to apply these concepts in terms of Agile software development. Here’s the proficiency levels of self-organization that I proposed:
- Novice or Beginner:
- Can find meaningful work to do without being directed.
- Intermediate:
- Can find collaborative work to do without being directed.
- Can pull information needed to identify work, or to enable collaboration.
- Can identify impediments to own work.
- Advanced:
- Can find ways to remove impediments to own work.
- Can identify impediments to the team’s work.
- Can find ways to remove impediments to the team’s work.
- Superior or Master:
- Can find ways to advance the team’s ability to self-organize.
And the fluency levels:
- Successful occasionally
- Generally successful with patterns previously experienced
- Occasionally able to generate new successful patterns
- Generally able to generate new successful patterns
In accordance with the separation between these two dimension, one could be generally able to generate new ways to remove impediments in one’s own work (highly fluent at the Intermediate level), yet only generally successful with familiar patterns of removing impediments in the team’s work (modestly fluent at the Advanced level).
Many thanks to Willem for giving me this new (to me) way to look at learning. I’d love some feedback on my application of these language learning concepts to the field of teamwork.
This is amazingly relevant as we’re in the process of “leveling” people in our development organization (a necessary evil) and I like how this is a much more useful scale than the traditional “supervision”, “independence” and “knowledge” scales. I’m going to think about how to expand this into more concrete ways that people can measure themselves.
George-
I have been waiting for a breakthrough like this for months and months, hoping someone Agile fluency could create a roadmap. Count me as a *huge* fan of this draft of a possible roadmap.
Just thrilling.
-Willem
Willem, thanks for the inspiration and the encouragement.
— George
I’m wondering, “according to whom?” Who makes the observations/judgments as to proficiency and fluency in a self-organization context? And, in a team context, who exhibits these characteristics, since success in teaming means not necessarily individual but collective proficiency and fluency? Wouldn’t it? For instance, we’ve all seen individuals who’s fluency disrupts their proficiency, so distracted (and distracting) proposing new and alluring patterns that they become self-disorganizing. And, we’ve seen folks who working collectively somehow integrate such an individual and stumble ahead better for their presence. An observer might conclude that the overly fluent one is a disability to the team, that the others on the team are protecting him, when he’s really a part of an integral whole. So, who exhibits these proficiency and fluency traits and what do they look like in practice?
I like that you’ve posed these as outcomes and NOT as behaviors. This makes them more tangible, but only as post hoc phenomenon. I might be able to know after the fact that you were fluent and/or proficient, but not beforehand. And this leaves me wondering, even if you had an observer, what would he observe?
See http://softwaregreenhouses.wordpress.com/2011/01/30/using-wayk-to-describe-tdd-fluency/ for a look at TDD using the proficiency & fluency concepts of WAYK.