Diana Larsen first told me about the Where Are Your Keys language learning game that Willem Larsen and Evan Gardner were playing in early 2009. I was initially intrigued, but when I experienced it with Willem later that same year, I became enthusiastic. My interest lay not in learning languages, but in applying the same techniques and framework to teaching Agile techniques. I immediately began thinking how to make that application, and I’ve been thinking along those lines ever since.
Thus, it was with tremendous expectations when I saw that Diana and Jim Shore had published Your Path through Agile Fluency on Martin Fowler’s website. Having read it, I’m both greatly encouraged and slightly disappointed.
The encouragement is triggered by how much thought and effort Jim and Diana have put into this. They’ve captured a common path for teams learning how to be more agile. The disappointment is that this is not THE description of Agile fluency that I’d hoped, for a couple of reasons.
First, the terminology of fluency is used loosely in this article. One of the great things that Willem and Evan borrowed from the ACTFL proficiency guidelines is the separation between the dimensions of proficiency and fluency. As Jim and Diana state,
Fluency is how a team develops software when it’s under pressure. Anyone can follow a set of practices when given time to focus in a classroom; true fluency is a skillful, routine practice that persists when your mind is distracted with other things.
Fluency is the ease with which you do something. The level of skill and sophistication, on the other hand, is the proficiency. When Jim and Diana use the term “four distinct stages of Agile fluency” they really mean “fluency at four distinct stages of proficiency.” When they say “higher fluency” they mean “fluency at a higher level of proficiency.” The latter is a little clumsier to say, but I find the distinction very important to understand the progression.
Second, I think that “we’ve seen that teams progress through the stages in a predictable order” implies more regularity than exists. I’m not questioning the statement. I don’t doubt that they’ve seen teams accomplish the alignment with the business before accomplishing the technical skills to work effectively in short cycles and abrupt changes in direction. That’s the way that most organizations seem to approach an Agile transformation. When the organization hires a coach to help them “go Agile,” gaining that alignment is usually high on their goals. When they use Scrum as the basis of their Agile practice, they get the alignment practices and have to add the engineering practices later.
But I think back to my own path. I started with the technical practices. Test driven development, in particular, was the brand-new (to me) practice that was different from what I’d done before. Soon I was practicing “XP for 1” in a non-agile organization. I had not improved the alignment of my work with the organizations goals. I was still implementing what they asked for rather than what they wanted. But I was doing so more reliably, recovering from mistakes earlier and more quickly, and doing so with less suffering and long hours.
I also think back to Kevlin Henney’s keynote at Agile 2011. On slide 21, he talked about the “Alignment Trap” that many organizations fall into on their way toward “IT Enabled Growth.” He pointed out that the better path seemed to be by emphasizing effectiveness before emphasizing alignment. Again, placing the technical practices before the management practices.
My conclusion is that it is not necessary to focus on value before focusing on delivery. It has been done both ways. And in my experience, it seems best to do a little of each at the same time, or doing a little of one and then a little of the other, repeating as needed.
What’s the best way? It depends. Depends on what? On the context. You may recognize that from Jim Shore and Arlo Belshee’s Agile 2010 farce, Bloody Stupid Johnson. It’s funny, but it’s also true.
I think we’ve got a lot more to do exploring the levels of proficiency in Agile. Perhaps the ACTFL guidelines are not the only proficiency scale for language acquisition, either. I don’t know about that. But I do know we’ve not finished with this topic in Agile adoption.