With our Art of Agile Planning training course coming up at the end of the month, Diana Larsen and I met for our normal pre-course review and revision. We had tried teaching the material top-down and bottom-up, and both ways caused confusion in the early stages of the course. When we started with release planning and risk management, students thought the material was impractical; when we started with tasks and iteration planning, they wanted more about the big picture. We wanted to revise the course so there wasn't so much early-stage confusion.

After tossing around a few ideas, we sidetracked into a discussion of Language Hunters. Language Hunters is an innovative system for language learning that focuses on fluency and the idea that it is possible to be fluent even at a low level of proficiency. They call this "Travels With Charlie."

WAYK Techniques: "Travels With Charlie" from Willem Larsen on Vimeo.

"Travels With Charlie" involves four levels of proficiency:

• Level 1: Tarzan at the party. "Beer!" "Good party."
• Level 2: Going to the party. "Where is the party?" "How do I get to the party?"
• Level 3: Discussing the party. "What happened at the party last night?"
• Level 4: Charlie Rose. "Should parties be illegal?"

In language hunting, "fluency" is described as "what you can do when you're woken up in the middle of the night with a flashlight in your face." While a level 1 speaker may be able to reach level 2 on occasion, it's not intuitive yet. Nonetheless, it's possible to be fluent even at a low level of proficiency. A fluent level 1 speaker may know of lot of words but not be able to string them together into coherent sentences.

Travels with Agile

As Diana and I discussed language hunting, we realized that this idea of multiple levels of fluency worked perfectly with Agile planning as well. It's possible to be very fluent at planning technical work without being fluent at planning from a business perspective.

Excited by this realization, we developed a framework for proficiencies of planning. The next day, at Agile Open Northwest, we workshopped the ideas with a standing-room-only crowd of participants, and came up with some great results. I think they have wide applicability as a framework for understanding Agile planning and how to improve.

For us, "fluency" means "what you do when you're under pressure to deliver yesterday." So while a level 0 team might be able to plan in terms of business value, when under pressure they revert to focusing on technology.

Just as in language hunting, it's possible to be fluent even at low levels of proficiency. I've met some teams that were very capable at planning from a technical perspective. That's a level 0 proficiency, as we've defined it, but it doesn't mean those teams were incompetent. It just means that their competencies were focused on technical considerations.

Finally, although I'm presenting these proficiencies as graduated levels, I don't think that means you should focus entirely on one level before moving on to the next. When coaching teams, I introduce concepts from all levels right away. Fluency tends to develop in the order I've described, but we practice techniques for all levels from the beginning.

Level 0: We build code.

At this level, planning is oriented around technical considerations: architectural layers, where the areas of technical risk are, or simply what's fun or interesting. When multiple teams are working on a single product, they split work according to technology considerations, such as having a UI team and a core engine team. Fluency at this level involves being able to decompose technical tasks, coordinating groups of programmers (possibly large groups), understanding what to buy versus build, and interfacing with people outside of the team.

Teams at this level are disconnected from their customers. They may be insulated from customers by requirements documents, intermediaries such as business analysts, or just don't consider their customers at all.

To be clear, it's possible to be highly competent at this level of proficiency. In our workshop at Agile Open Northwest, one participant noted that fluency at this level can sometimes prevent developing higher proficiencies: "We're very good at what we do," the thinking goes. "We don't need to learn anything new."

Level 1: We create business value.

Teams plan their work in terms of what's important to the business rather than what's important technically. They prioritize the most valuable things first and change their plans as business priorities change. If multiple teams are working on a single product, the work is organized according to business function rather technology.

Teams fluent at this level use techniques such as user stories, acceptance criteria, the planning game, and cross-functional teams. Teams treat their customers as a consumer--they solicit stories from customers and deliver software to them, but they don't involve their customers much more than that.

On the engineering side, teams enable a business-focused approach with techniques such as incremental design and architecture, simple design, refactoring, and test-driven development.

The Agile movement brought this level of proficiency to the forefront; a lot of the early Agile literature trumpeted the focus on business value and teams' ability to change direction. Every Agile team should be fluent at this level.

Level 2: We deliver business value.

Not only does the team create business value, they deliver it on a regular cadence. They're able to get their software done and out the door on a regular basis, which may be every day or every year, depending on their market. Either way, the team sets their cadence according to what brings the most value in their market.

Techniques include minimum marketable features (MMFs), developing one MMF at a time, defining and achieving "done done," estimating, iteration planning (or Kanban), stand-up meetings, understanding the team's velocity or lead time, and managing scope to meet the regular cadence. Teams collaborate with their customers to understand what to deliver and when.

Technically, teams have a solid automated builds and continuous integration. Teams with a fast cadence might use continuous deployment. Those that don't use good configuration management.

For most Agile teams I know, getting to this level requires focusing on their engineering practices. They're often ready to plan at this level before they have the ability to deliver reliably.

Level 3: We optimize our business value.

The team delivers the most valuable things first, adapts their plans to maximize value, and actively seeks out ways to create new opportunities. Teams at this level understand their customers, their industry, and the financials of their products.

Techniques include adaptive planning, a clear product vision, balancing short- and long-term thinking, limiting the size of the backlog, and considering decisions about what not to do to be as important as decisions about what to do. Fluent teams include people with strong business expertise as full-time members of their team and they take advantage of that expertise daily.

In my experience, once teams master the engineering practices required for level 2, they discover that they need more business expertise before they can reach level 3. Some teams don't have the expertise they need at all; other teams have the experts they need but not the time to spend on strategic planning. Teams that get to this level invest in more staff or develop existing team members.

Level 4: We optimize our organization's business value.

Teams fluent at this level of proficiency understand that their work is part of a much bigger picture. They coordinate and manage commitments to and from their teams, participate in optimizing throughput across the organization, and may identify strategic business needs for the organization. They also recognize when they aren't providing enough value and should be helping other teams instead.

Techniques include risk management, risk-adjusted burn-up charts, systems thinking, collaborating with other project teams, and even collaborating with competitors. Teams fluent at this level are strategic partners to their organizations.

Reaching this level requires making commitments and meeting deadlines. Some people would prefer not to make those sorts of commitments, but I've found it's necessary. Coordination with marketing efforts and strategic initiatives requires hitting dates. Teams that can do that gain the trust required to be a strategic partner within the organization.

Conclusion

Take an honest look at your product team (or teams). When you're under pressure to deliver, what level do you work at? How could operating at a higher level benefit your team and your organization, and what techniques do you need to master in order to get there?

I hope you'll give this system of proficiencies a try. If you're interested in seeing more, Diana and I will be using this system and teaching many of the above techniques in our upcoming planning course on February 28th and March 1st. Either way, we'd like to hear how they worked for you.