Agile - Levels of Fluency

A quick overview of the Test-driven developmen...
Last night I went to the monthly AgilePDX meeting where James Shore talked about the Agile Fluency(TM) Model.  He began by saying that there’s been an explosion in agile adoption, but there hasn’t been the same growth in the “state of the art.”  Shore said this is disappointing because he wants every team who uses agile to be able to reach the highest success.

Then he began to explain an idea of which he had recently learned through Willem Larsen’s ideas of language fluency (see www.languagehunters.org).  Language, in this case, means natural language, not a programming language. Fluency in a language means that you think in that language – it’s the language you use when you’re woken up at 2 am in a surprising way.

According to Larsen, there are four well-established levels of fluency:
1- Tarzan at the party (eg: “Me want drink. Food”)
2- Getting to the party (eg: “The party is at 8pm, on West 3rd Street”
3- Discussing the party (eg: “What wonderful hors d’oeuvres! I loved Caroline’s dress”)
4- Charley Rose (eg “Speaking of parties, what is the trend this year in centerpieces?”
(those are my examples).

Each level of fluency is useful, although there are greater nuances and capabilities as you reach higher levels.

Shore then suggested that there might be similar levels of fluency in Agile development practices:
Level 0- We build code (but we’re not agile)
  • Domain driven design
  • Programming
  • Database design
  • Configuration management
  • Testing
Level 1- We create value (on a daily basis)
  • Iterations
  • Stories
  • Estimating
  • Planning game
Level 2- We deliver value (as often as our market can accept it)
  • "Done done”
  • Slack
  • Risk driven architecture
  • Velocity
  • Continuous integration
  • Risk management
  • Test driven development
  • Daily standup
  • RABU charts
Level 3- We optimize our value
  • Customer discovery
  • Purpose
  • Concept of “minimum marketable features”
  • Last responsible moment
  • Effect mapping
  • One at a time
  • Adaptive planning
Level 4- We optimize our organization (the work is done where it’s needed, not necessarily your assigned tasks)
  • Systems thinking
  • Lean startup
  • Value-stream mapping
  • One-piece flow
  • ???
Shore worked with Diana Larsen to create the levels, grouping them according to how they’ve seen companies adopt agile development practices. Shore says that in his experience as a consultant most teams he sees are at level 1.  Level 2 is what people think of when they think “Agile,” and consultants are selling the idea of level 3 (although most teams are at level 1). 

In order to move from one level to the next there are certain changes which must occur. To move from level 0 to level 1 means changing your mindset so the team focuses on stories and value, which can sometimes be an eye-opening change.  Moving from L1 to L2 is another change, although slightly more nuanced: the concept of continuous integration, and metrics that allow you to predict development.  Moving up to L3 requires a paradigm shift at the management level of the organization, while L4 means organizational change.  Clearly an organization can’t jump to L4 without each employee becoming fluent in all of the earlier levels.

At this point in the talk we split into groups.  Everyone in the meeting had indicated (a) which level they thought their organization was at, (b) which level they’re working toward, and (c) which level they ultimately hoped for.  It was interesting that most people thought they were at level 1, were working toward level 2, and ultimately hoped for level 3.  That meant that most people didn’t aspire for a fully agile organization – just having a portion of the organization agile was sufficient.

Each group was centered around the level of fluency they hoped to achieve.  In my group, level 2, we talked about continuous integration, “done done,” and test driven development.  Originally I had thought that my development team needed to work more on test driven development, but as we talked, I realized that we’re already working on continuous integration (although we don’t call it that), and that we should continue to work on that until we’re fluent.

Shore then wrapped up the evening by asking us to reflect on what we’d discussed, and to write down one thing to bring back to our organizations. Although I want to explore test driven development (TDD), I’m committing to working on improving our continuous integration until we become fluent in that Agile practice.

Some thoughts about the presentation: It was nice to see a road map of goals for achieving the Agile Fluency (tm) model. Often people talk about agile, and I feel like I’m in a mist, where their concepts appear to be in one spot, then suddenly swirl to another. Laying out the road map this way also provides a common set of terms.  RABU, for example, was a term I hadn't heard before.

On the other hand, I was reminded of a class I had in 1999 on customizing the Capability Maturity Model (CMM) for your organization. Many people in the class seemed to think they could pick & choose the aspects of the model as if moving through a supermarket, which is not the case. In the long run both Shore’s Agile Fluency(tm) model, and the CMM have the same underlying restrictions: In order to achieve the highest levels, individuals and leaders must commit to internalizing – becoming fluent – in the earlier levels of the model.  It’s not enough to say “we’re working toward level three of the Agile Fluency (tm) model,” unless you have internalized levels zero, one and two for both the individuals and the organization.

You can read more about the Agile FluencyTM Model here at Shore's website.
Enhanced by Zemanta


My Top 10 problems with using Scrum

English: The Scrum project management method. ...Image via WikipediaWhat are the top 10 problems I've encountered using an agile methodology like Scrum?

10) The waterfall mindset.  Management prefers the monolithic plan, regardless of how unwieldy it may be. Additionally, development teams who have done waterfall development will tend to slip back into it.

9) Ignoring the "definition of done." Either features that meet the definition stay sticky, where some team members want to further perfect the feature, or the feature is considered "done" without having really been completed.

8) Sprintus-interruptus. Although the team is working in a sprint, management interrupts the team with a high-priority external project.

7) When sizing stories, people start to think of features in absolute sizes rather than relative sizes. Each team is different, so sizing only makes sense to that particular team.

6) It takes a while to get a rhythm for a two-week sprint. Sometimes the team doesn't deliver value until halfway through the sprint, and by then it's almost too late.

5) Stories might be ill-defined.  I've seen stories that omitted who wants it, why, and what's the value.

4) Teams forget to share the work. People prefer to work in their own area, ignoring what other people need or are working on.

3) Team members ignore aspects of Scrum -- such as sizing or prioritizing the backlog. Without a sized, prioritized backlog you aren't managing the process, the project manages you.

2) It's hard to know where and how to document requirements as they evolve

1) People fail to use face-to-face communication.  This is the most efficient way to communicate nuanced information.

Enhanced by Zemanta