Last month I attended Product Camp Portland for the first time. I had heard about the conference a few times since I began working at Jama over two years ago - an occurrence that I can attribute to the strong product culture we have - but had never had much interest in attending. Many of my colleagues had attended (not necessarily on the engineering side of the house) and some had even been nominated for best talk a few years ago. For the sake of learning and curiosity, this year I decided to attend.
Background & Prior Art
Over the past year or so, I became more interested in Product Management via the experience I gained at Jama serving as the ScrumMaster for my team. At Jama, we do not have any individuals that are fully-resourced as ScrumMasters as is the case in larger organizations; instead an engineer per team takes on this role, and splits their time between engineering work and ensuring that things run smoothly from a process stand-point. This often involves working closely with product and engineering managers to ensure that our team is getting all the information, resources, and help that we need to be estimate, plan, and deliver new features.
Yet another layer deeper, my recent interest in the subject draws from initial reason for becoming a ScrumMaster, which was to deepen my understanding of Agile Software Development, and help Jama continuously improve on its ability to deliver value to customers. After working for the first-part of my career in technology companies that practiced varying degrees of Agile Software development, I finally came upon Jama, which had a relatively mature software development process.
Even after becoming a Certified Scrum Master and acting as one for the better chunk of a year, I realized 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 towards my product-development peers and my own professional growth.
On March 4th, I showed up at the Eliot Center in Downtown Portland, where this year’s conference was being held. During my day at Product Camp I didn’t learn much about the nuts and bolts of what it takes to be a great Product Manager, but I did get the opportunity to learn a few things about the Product Management perspective on creating software.
Product Camp is a conference that doesn’t have predetermined speakers; instead during a morning session topics are pitched, and voted on by the attendees, and finally filled into the schedule across four sessions. After this attendees choose which sessions they would like to attend. I missed the early-morning selection routine, but showed up in time for the commencement of the initial talks.
One of the more interesting talks that I attended was on the Agile Fluency model was facilitated by Diana Larsen, an Agile trainer and local celebrity in Portland’s software industry (full-disclosure, Diana facilitated a retrospective workshop at Jama a little over two years ago). In this session, Larsen explained the Agile Fluency model, and discussed with the attendees.
I found Larsen’s talk particularly germane to my own experiences of attempting to understand and improve our Agile Software development capabilities at Jama. If anything, it made me at peace with accepting that there is no one right way to do Agile, and that each organization goes through a progression that takes time, care, and great organizational investment to execute on.
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 on Martin Fowler’s website five years ago authored by Larsen & Shore (I recommend reading this article before proceeding with rest of this post).
The Model is used to describe the stages that a team goes through as they develop fluency with Agile Software development, and is used to “chart a course for the team, create alignment with management, and secure organizational support for improvement.”
In order 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:
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 CMMI. Instead it should be understood that 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, whereas approximately five percent are fluent in the three-star category, and an incredibly rare number are at the four-star level. Beginning at the three star level the main challenges & resistance come from inertia of the broader organization.
For agile teams in more bureaucratic organizations, they suggest that two-star fluency may be the best goal to strive for. Achieving agile fluency involves expending social capital and resources in the near term, to achieve better results over time. For certain organizations, this may unfortunately be seen as too high of a cost.
During the session I attended, we went through the different steps of the model, and discussed as a group what practices we though fit into each level of fluency. The article that originated the Agile Fluency Model provides some in-depth explanation of the specific Agile practices & skills that lend themselves to each tier, as well as the metrics and costs that are typically associated with their adoption.
Below I’ve outlined the basics of the tiers, the content of which is heavily sourced from the original article and related publications:
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 understands and benefits from the insights they gain from the process. The teams focus on the value delivered to stakeholders & 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.
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 at the initial cost of decreased productivity, but the benefit of increased productivity & higher quality following the initial investment. Two-star teams are able to ship at market cadence, and on 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.
Three-Star Teams: Optimize Value
A three-star team is one that has achieved the ideal of agile; rapid product-development that is responsive to change, business experts being 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 as external stakeholders. Managers are capable of working 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.
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.
Below is a helpful, powerpoint slide-worthy chart that I shamelessly copied 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|
Where does Jama fit in the model?
After learning about the Agile Fluency Model I began to wonder where Jama’s product-development organization currently falls within the framework. After reading through the examples of practices used in the first three levels, I began to see our organization did a little bit of everything, but also a few areas where we still needed improvement.
When I arrived at Jama, Agile Software Development practices were well under way and had been so for several years. During my tenure at Jama I have seen the fluency of the team grow as a two-star organization; the organization has made a series of investments in developing the software development skills of the team.
To this end, we have invested in refactoring workshops, put a focus on continuous-integration, test-driven development, pair-programming, collective-code ownership and emphasis on DevOps culture. Jama ships software at a cadence that makes sense for the various markets we serve; some with a tolerance for monthly releases, others with a biannual tolerance in accordance to their regulatory environment or risk-tolerances.
Where I think Jama most comfortably fits within the Model, is as an organization that has attained two-star fluency, with aspirations to be a three-star organization. I believe this because we have already adopted some of the tenets of a three-star organization.
One of the practices we have that is consistent with a three-star team, is that we have a system of self-organization within our engineering group. Engineers are free to move around to different projects and focuses as their interests change. At the same time, we also have strong support for gelled-teams; individuals whom enjoy working with each other and have gained an efficiency in doing so in particular areas of the product.
An important tenet of a three-star team that we do not currently have in place is permanent membership of business experts within a development team. While each development team that is working on a customer-facing project works with a Product Manager to help represent customer and business needs, or a UX Designer that helps ensure that a feature meets design quality, they are not permanently embedded or colocated with the team, and often work with multiple teams at the same time. At this juncture in Jama’s growth, I think that this is perfectly appropriate
I am both glad that I attended ProductCamp, and that I decided to attend Diana Larsen’s talk on the topic of Agile Fluency. I’ve found that the model is a great way to better understand the transformation that software development organizations tend to go through as they become more advanced in their practice of Agile methodologies.
A key point of the Model that stood out to me were that different levels of fluency are appropriate for different organizations; it shouldn’t be everyone’s goal to achieve three-star fluency if they are already gaining immense benefits from being a one-star team. Furthermore, the journey towards being a three-star organization can be a long process for more established companies, as it involves a organizational change not just within the product development organization, but across the entirety of the business.
If anything, discovering the Agile Fluency Model has gotten me even more excited to continue helping Jama find ways to deliver value to customers faster, and a series of goals that will help move our organization forward.
- Your Path Through Agile Fluency; Larsen, Shore; August 2012
- Agile Fluency: Finding Agile That’s Fit-for-Purpose; Larsen; November 2013
- AgileFluency.org; Larsen, Shore; 2016