I hadn't heard of Agile Fluency until a few days
ago. I had recently joined AgilePDX (our local Portland group of
folks interested in all things agile) and the email reminder came in
about the monthly evening talk. Jim Shore and Diana Larsen were going
to discuss their Agile Fluency model as part of the group's annual
Agile Tune-up where everyone comes to think about what good goals might be for
their teams for the coming year.

The fog was thick outside. As bad as
I'd ever seen it (and it proved to be as difficult to drive in as I
feared). I thought about not going to the meeting, but then I googled
“agile fluency” and started to read a bit about Jim's background
(I hadn't realized InfoQ had named him one of the most influential
people in agile for 2012:
http://www.infoq.com/news/2012/04/agile-influential-people).
Then I read the article. Then I realized I really needed to go –
this was going to be interesting.

Okay, just in case you didn't go read,
I'll recap a little bit (most of this is in the article, some of it
embellishments from the meeting): Jim and Diana discuss a team's path
through agile fluency (based on their extensive experience in the
space and with many teams), giving each level a star:

With no stars, you can be
effectively building code. You write stuff based on specs others
give you and it mostly comes out fine. You're not agile and you may
not care.

With a team culture shift, you can
reach the one star level, focusing on value. You are likely using
Scrum or Kanban and working with User Stories and doing some
estimation and you see your progress in terms of business value.
You're probably hitting most of your iteration goals but you are not
necessarily continuously delivering and your scope is just your own
backlog. These are the Agile Fundamentals.

With a team skills shift, you are
now at the two star level and delivering value at the market's
cadence. You are capturing value and delivering it as quickly as the
market will absorb it – maybe it's a web app you update every few
hours or an enterprise application that delivers once a quarter, but
you are delivering reliably. You are likely invested in continuous integration, thorough unit testing, perhaps even TDD, and other XP practices. This level can be thought of as Agile
Sustainability and a team and product could be very successful at
this level for a long time. Depending on the size of the
organization, this may be all you'll ever need.

With an organizational structure
shift, you get three stars and reach a point of optimizing value
across the product. It's no longer just about your team or your
piece of the pie but the organization has shifted to optimizing
value across the product and throughout the organization. There are no
hand-offs and excellent product level decisions are getting made
routinely. This is “Agile's Promise” and what some refer to as
Enterprise Agile.

With a complete organizational
culture shift, you reach a four star level where you are optimizing
for systems across your enterprise. This is “Agile's Future” and
it's not clear that many organizations have neared this level yet.

What struck me most about the article
is the use of the word “fluency” and how it is defined by Shore
and Larsen. They draw a bright line between proficiency and fluency.
Proficiency means you understand the set of practices and are capable
of following them. In their words, “Fluency is how a team develops
software when it's under pressure. Anyone can follow a set of
practices when given time to focus...true fluency is a skillful,
routine practice that persists when your mind is distracted with
other things.” Like broken builds and disgruntled customers (or,
here in the Pacific Northwest, the first sunny day in weeks).

I'm reminded of a saying about
musicians: Amateurs practice a piece until they get it right; professionals practice a piece until they never get it wrong. For me
that sums up the difference between proficiency and fluency in this
context.

Having been involved in several team's
attempt at agile transformation, I've seen a lack of
understanding of the need for fluency disrupt the transformation.
The team has had some training and faltered in their early sprints
(as is common and generally expected) but they are using the
retrospectives and honestly looking at what needs improvement. Then,
before they reach a point of fluency, something distracts them, some
disruption in the force tries to throw them off their game. And it is
successful. Before they can get back on track, their manager decides
(problem #1) that the retrospective meeting is worthless because
nothing seems to get better – and it just sort of crumbles from
there. They are now a Scrum-but team and may always remain one. Had
they been given the space to reach fluency at their current level,
the could have weathered this storm. Lacking that fluency, they could
only return to what they used to be fluent at.

Reminds me of another saying from a
different field: Under stress, you will not rise to the occasion,
but default to your level of training. So your level of training
needs to bring you to fluency at the things you care about and your product and team depend on.

Models like CMMI tend to focus on
practices that you adopt – so perhaps you are proficient. But the
Agile Fluency model's focus on fluency, not just being capable of the
practice but having adopted it so completely that it's just what you
do makes a lot of sense to me. I also like the model because it is
not about some set of practices you have adopted or a particular
metric you've hit but about who you are, how you behave.
Your fluency allows you to “be” at that level – it's what your
team has become, how it's focused, what behavior feeds its soul.

The article includes a nice diagram of
the path as well as a discussion of the benefits, investments and
core metrics at each level. It's frank about the type and size of
investment required at each level. Two stars can be hard because of
the breadth and depth of skills required and the level of practice to
become fluent. If you work in an organization that cares about agile
development, go read and share the links (and this blog if you are so
inclined). The ideas are valuable and I expect you'll hearing more about
them.

Following up a bit on the last topic (where I talk about how much I love the field of software development because I always have to be learning new things), a college professor friend of mine who teaches software development shared a disappointing story...

As he’s chatting with some students after class, they ask him which language or technology they can learn so that they don’t have to learn anything else once they get their degree.

This blew me away on several levels: (1) These are university students participating in a largely optional learning activity (college) and they are already trying to figure out how to stop learning?! That doesn’t bode well for their lives in general, much less their future as software developers, (2) They are studying a technology field and are old enough and smart enough to get into college, yet they’ve missed the fact that technology has done nothing but change their entire lives? There’s a chance that some of the specific technologies they learn in college won’t even be relevant by the time they graduate, (3) They think they’d actually want the job they are describing. [That last one is wrapped up with some personal bias, for sure -- I can’t imagine any period in my career where I would have been happy doing just that thing for the remainder of it.]

Yet, somehow I fear I may be the odd one here. One of my favorite interview questions (sorry, no bizarre thought puzzles like “how do they make M&Ms”) was “What was the last book you read and what magazines do you read regularly?” I rarely got a decent answer. Often I’d get quizzical looks and would have to eventually follow up with “Software development is a rapidly changing field. You’d like to come work for us as a software developer. I’m trying to figure out how you go about keeping up with change and staying abreast of new technologies and practices.” Unfortunately, they often now understood my question and still had nothing satisfying to say.

BUT, here’s the answer that I hated the most: “Yeah, you’re right, doing that’s a good idea but my company doesn’t pay for books or magazine subscriptions.” So you know it’s a good idea, that it would be valuable to you as a software developer and by extension make you more valuable as an employee, but unless someone else pays for the book or magazine subscription, you’re not going to do it? [imagine several more paragraphs of crazed ranting here -- it’s harder than I thought to not include them]

I’m afraid to ask this question any more. It’s so easy to follow folks on Twitter or Google+ or read their blogs or get entirely free magazines sent to you in email or buy even cheaper e-book versions of books that the interviewee’s quizzical stare would cause me to tilt.

To help fight this phenomenon I will occasionally curate a useful set of links or list of books that I personally find valuable. If you know of equally good or better books or links, please post in the comments -- I can’t read everything and I won’t post about something I haven’t actually read or used and found value in.

Recently, the topic of getting someone up to speed to work with Dojo came up. The team is using Agile/Scrum practices. Based on things I’ve read trying to climb the same learning curve, here are my recommendations (I don’t want to seem to support any one bookseller over another, so please just search on the title and buy where you’d like):

JavaScript Eloquent JavaScript: A Modern Introduction to Programming by Marijn Haverbeke (don't let the subtitle fool you, it's a good introduction and recently published).

JavaScript: The Good Parts by Douglas Crockford. See also www.crockford.com/javascript

JavaScript Patterns by Stoyan Stefanov, presentation by author at http://www.slideshare.net/stoyan/javascript-patterns

DojoGetting StartED with Dojo by Kyle D. Hayes with Peter Higgins. A gentle yet useful introduction, nicely organized and presented.

Dojo: The Definitive Guide by Matthew A. Russell. As I searched for a really good Dojo book, this one kept appearing at the top of people's lists. While based largely on dojo 1.1, it focuses on fundamental aspects of Dojo that I expect remain the same today. I understood things after reading this that I only thought I understood before reading it.

Agile and Scrum Implementing Lean Software Development: From Concept to Cash by Mary and Tom Poppendieck. This book "made it click" for me, providing a vivid description of how you can deliver high quality software of value to the customer while eliminating waste and constantly improving your team.

Succeeding with Agile: Software Development Using Scrum by Mike Cohn. I very much enjoy Mike's writing style and I give this book an edge over Ken Schwaber's original treatment, but either will suffice.

Agile Estimating and Planning by Mike Cohn. If you want to really understand how Story Points are meant to work and how Agile Planning seeks to mitigate risk, this is the book. If you're more into Cliff Notes, Mike provides lots of useful material at his web site: http://www.mountaingoatsoftware.com

I personally have a Safari Books Online (http://safaribooksonline.com/Corporate/Index/) Individual subscription. For $23 a month I can read any book I want, up to 10 at a time on my personal "bookshelf". You also earn credits that allow you to download books permanently to your computer, often in a variety of formats (PDF, .mobi, .apk, etc.)