Agile Fluency, or What I Learned at ProductCamp

Product Development & Management

Agile Fluency, or What I Learned at ProductCamp

By |

About a year ago, I became a Certified Scrum Master and took on the role for my engineering team. My desire was to deepen my understanding of Agile Software Development and help Jama Software continuously improve on its ability to deliver value to customers.

This often involves working closely with product and engineering managers to ensure the team is getting all the information, resources and help we need to estimate, plan and deliver new features.

Even after being in the role, I realized that I knew very little about the day-to-day life of a Product Manager outside of my interaction with them as it relates to executing on software development. I figured it was probably high-time that I take off my engineering hat for a day and pretend I was a Product Manager, both for the sake of empathy toward my product-development peers and my own professional growth.

Enter ProductCamp, which I attended for the first time. ProductCamp is a conference that doesn’t have predetermined speakers. Instead, topics are pitched during a morning session and voted on by the attendees. The winners are filled into the schedule across four sessions. After this, attendees choose which sessions they’d like to attend.

During my day at Product Camp I got the opportunity to learn a few things about the Product Management perspective on creating software. One of the more interesting talks I attended was on the Agile Fluency Model. It was facilitated by Diana Larsen, an Agile trainer and local celebrity in Portland’s software industry.

I found Larsen’s talk particularly germane to my own experiences of attempting to understand and improve our Agile Software development capabilities. It made me at peace with accepting that there’s no one right way to do Agile. To execute, each organization goes through a progression that takes time, care and great organizational investment.

Agile Fluency Model

The Agile Fluency model was developed by Diana Larsen and James Shore, another luminary in Portland’s software development industry. It was initially introduced in the article Your Path through Agile Fluency.

The Model is used to describe the stages that a team goes through as they develop fluency with Agile Software development. It’s used to “chart a course for the team, create alignment with management, and secure organizational support for improvement.”

To describe fluency, the “star” signifier is used. Each level provides certain benefits, but also comes with challenges. Below is a diagram that is provided in the original publication:

a-teams-path-through-agile-fluency

While this describes levels of progression insofar as fluency with Agile methodologies as a team, they do not describe it as a maturity model like the Capability Maturity Model Integration (CMMI). Instead, the goal for each team should not to be to reach the final tier, but to aspire to the level that is most appropriate for their organization.

In the article, the authors explain that most teams fit into the one or two-star range, and suggest that two-star fluency may be the best goal for teams in more bureaucratic organizations.

They note that approximately five percent of teams are fluent in the three-star category, and an incredibly rare number reach the four-star level. Beginning at the three-star level, the main challenges and resistance come from inertia of the broader organization.

The journey toward being a three-star organization can be a long process for more established companies, as it involves an organizational change not just within the product development organization, but across the entirety of the business. Achieving agile fluency involves expending social capital and resources in the near term, to achieve better results over time. For certain organizations, the cost may unfortunately be too high.

During the Agile Fluency session at ProductCamp, we went through the different steps of the model, and discussed as a group what practices we though fit into each level of fluency.

Below I’ve outlined the basics of the tiers, the content of which is heavily sourced from the original article and related publications. The Agile Fluency Model article provides a more in-depth explanation of the specific Agile practices and skills that lend themselves to each tier, as well as the metrics and costs that are typically associated with their adoption.

One Star Teams: Create Business Value

A one-star fluency team is an organization that practices the fundamentals of Agile and focuses on delivering business value, while helping the broader organization understand and benefit from the insights they gain from the process. The teams focus on the value delivered to stakeholders and customers, rather than solely technical architecture, typically articulated through user-stories.

  • Benefit: Greater visibility into teams’ work; ability to redirect.
  • Investment: Team development and work process design.
  • Core Metric: Team regularly reports progress from a business value perspective.

Practices: Scrum or Kanban, backlogs, retrospectives, iterations, Sprints and Kanban boards.

Two-Star Teams: Deliver on Market’s Cadence

A two-star fluency organization has made major investments in building the software development skills of the team. The initial cost is decreased productivity, but the benefit of increased productivity and higher quality follow the initial investment. Two-star teams can ship at market cadence and at will. Two-star teams adhere to the philosophies of Extreme Programming, Software Craftsmanship and DevOps.

  • Benefit: Low defects and high productivity.
  • Investment: Lowered productivity during technical skill development.
  • Core Metric: Team ships on market cadence.

Practices: Extreme Programming, continuous integration, test-driven development, pair-programming and collective code ownership.

Three-Star Teams: Optimize Value

A three-star team has achieved the ideal of agile: rapid product-development that’s responsive to change, business experts involved as full-time contributors and an improved ability to serve the needs of the business. Teams incorporate business experts — such as product managers, business analysts and quality assurance analysts — as full-time team members rather than external stakeholders. Managers can work across the organization to remove obstacles.

  • Benefit: Higher value deliveries and better product decisions.
  • Investment: Social capital expended on incorporating business expertise into team.
  • Core Metric: Team provides concrete business metrics.

Practices: Lean Software Development, Agile chartering, embedded product management teams, customer discovery and adaptive planning.

Four-Star Teams: Optimize the System

A four-star team is referred to as the future of Agile: tight collaboration with other portions of the business, “…whole-system thinking and a willingness to experiment.” These teams make use of “…advanced management theories and innovative product development methods.” This is kept almost deliberately opaque, as Larsen and Shore claim to have observed only very few teams that achieve this, most of which happen smaller teams.

  • Benefit: Alignment with organizational goals; synergistic effects.
  • Investment: Significant effort in establishing organizational culture; inventing new practices.
  • Core Metric: Team reports how its actions impact the overall organization.

Practices: Agile portfolio management, systems thinking, value stream analysis, whole system planning, intact teams, open book management and radical self-organization.

Below is a helpful, chart from the original post. It can be used to quickly illustrate what I described above:

Stars Benefit Investment Core Metric Time to achieve Achievement Rate
1 Greater visibility into teams’ work; ability to redirect. Team development and work process design. Team regularly reports progress from a business value perspective 2-6 months 45%
2 Low defects and high productivity. Lowered productivity during technical skill development. Team ships on market cadence. 3-24 months 35%
3 Higher value deliveries and better product decisions. Social capital expended on incorporating business expertise into team. Team provides concrete business metrics. 1-5 years 5%
4 Alignment with organizational goals; synergistic effects. Significant effort in establishing organizational culture; inventing new practices. Team reports how its actions impact the overall organization. unknown very few

Source: Your Path through Agile Fluency

I am glad that I attended ProductCamp, and that I decided to attend Diana Larsen’s talk and discovered Agile Fluency. I’ve found that the model is a great way to better understand the transformation software development organizations tend to go through as they become more advanced in their practice of Agile methodologies.

It has provided a series of goals that will help move our organization forward, which makes me even more excited to continue helping Jama Software find ways to deliver value to customers faster.

 

Jama Software
Latest posts by Jama Software (see all)