Agile Fluency

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.


Categories: Responding to Change

Tags: ,

3 Replies to “Agile Fluency”

  1. Hi George, thanks for your thoughtful comments. You seem to be making two points:

    1) You’d prefer tighter terminology a la language fluency.

    To this, I can only say, “meh.” πŸ™‚ Technically, we’re talking about fluent proficiency, as you said. In the process of writing and editing the article, that distinction got edited out. I think the resulting article is more readable, and I’ll often favor comprehension over accuracy ( ) I’m okay with our little terminology fib.

    2) You think it’s better to focus on technical practices before “alignment with the organization.”

    You may have misunderstood what we’re saying. If so, I expect that it will be a common misinterpretation, despite our attempts to say otherwise. Here it is:

    –> Although we put one-star first, we don’t think you should start by focusing on one-star practices. <–

    Instead, we think you should use all the practices together. So if you're aiming for two-star fluency (or fluent proficiency, if you prefer πŸ˜‰ ), you should practice test-driven development from the beginning.

    Other than suggesting that you practice everything together, we're not actually suggesting any approach to implementing these changes. We're just describing how it happens in practice. And I'd be willing to bet that, even though you started with TDD, your *team* got to one-star fluency before two-star fluency.

    Arlo Belshee had a similar comment as you. He prefers to start with technical practices, and felt that two-star fluency should come first in the model. After a conversation with him, though, he retracted his point. He was seeing one-star fluency as being more sophisticated than it actually was.

    In the article, we tried very hard to be method-agnostic. Between you, me, and the several hundred people reading this comment, though, one-star fluency is pretty much "planning with user stories." (Okay, it's a bit more than that. But not much.) It doesn't mean you have alignment with the business–that's three-star. It just means that you're communicating what you're working on in terms of business value rather than technology.

    From this perspective, I hope you can see why one-star fluency is achieved before two-star fluency, even if you start TDD at the same time. It's *easy*.

    Now let's look at your experience. You focused on technical practices first. I have no problem with that. But did your *team* really achieve two-star fluency without achieving one-star fluency? That would mean that your team was shipping on the market's cadence but doing its planning in terms of technical elements such as architectural layers. Did that really happen? And if it did, would you consider it "agile?"

    Anyway, I may be nitpicking here. I ultimately agree that it depends on context. Mostly I want to be clear that our phases are descriptive, not prescriptive. We aren't saying "do it in this order." We're saying "do everything and you'll see fluency (proficiency πŸ˜‰ progress in this way."

    And most of all, we're saying, "Hey, look, everyone! That user story and backlog planning stuff you're doing is awesome! Now look at all the other cool stuff that's out there!"

  2. Jim, you say “That would mean that your team was shipping on the market’s cadence but doing its planning in terms of technical elements such as architectural layers.” I don’t think that’s a sure conclusion. The team could well be planning the software in functional terms, but doing a serial plan-design-build in the “business requirements.” As I was doing XP41, the team was rather small and it’s hard to measure some of the distinctions. πŸ˜‰

    And I’m not saying it’s better to start with the technical focus. Just that it’s an alternative.

    Anyway, I like where you and Diana have pushed this. I just don’t think we’re done, yet.

  3. Hi George,
    I appreciate you for tackling this from your own base of experience. We need this kind of empirical reflection to continue to evolve our understanding of Agile in general and specific. I’m glad you were interested enough in our model to contemplate it further.

    Also, I’d like to add a pitch for as a place to look further into the ideas surrounding fluency _and_ fluent proficiency. πŸ™‚

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.