The Agile Fluency Model: A look within

Jameson Nyeholt | May 19, 2017

Agile Fluency: A Look Within

After learning about the Agile Fluency Model at ProductCamp, I began to wonder where Jama Software’s product-development organization fell within the framework. While I could see evidence of our fluency in the first and second levels, I was uncertain about our competency in aspects of the third level.

At Jama Software, Agile Software Development practices have been in place for several years. In the past few, we have made a series of investments in both our engineers and the broader organization.

In particular, we’ve focused on refactoring workshops, continuous integration, test-driven development, pair-programming, collective code ownership, and DevOps culture. We ship software at a cadence that makes sense for the various markets we serve. Some markets have a tolerance for monthly releases, whereas others operate on a biannual schedule in accordance with their regulatory environments or risk tolerances.

Jama Software’s Approach to Agile Software Development

One practice we’ve adopted, which is consistent with a three-star team, is we have a system of self-organization within our engineering group. Engineers are free to move to different projects and focuses as their interests change. At the same time, we provide strong support for gelled-teams, which consist of individuals whom enjoy working with one other and have gained an efficiency in doing so in particular areas of the product.

An important tenet of a three-star team is that business experts have permanent memberships. So each development team on a consumer-facing project works with a product manager to represent customer and business needs, for instance, or a UX designer to ensure a feature meets design quality. However, those individuals aren’t embedded or collocated with the team. Instead, business experts often work with multiple teams at the same time.

Though we don’t fulfill the criteria of having dedicated business experts and designers embedded on our teams, at this juncture in Jama Software’s growth, it’s appropriate we operate this way. While we’re certainly no longer a neophyte startup, we try to stay lean in our operations. This ensures team members at all levels of the process have a better understanding of what we’re building and why. Practices such as including the engineering team early in the user research process, and brokering out what exactly is going to be built, is an important counter-weight to the direct embedding of an individual for a specific project.

Staying flexible with Agile Methodologies

As we continue to progress as an organization, there will be some practices of a three-star organization that we’ll strive to achieve for the benefit of our own agility. As I mentioned above, we release on a monthly cadence to our hosted customers. For our on-premise clients, we follow a six-month schedule. While Jama Software has a release schedule that may appear longer when compared to consumer market applications, “move-fast and break things” isn’t a mindset that would be appreciated by the companies using our product.

Jama Software builds a solution for customers developing complex, mission-critical products, many of which are regulated. Bugs in our product development platform can lead to bugs in their products, which can result in both financial and fatal consequences. Many of the companies with this kind of regulatory overhead engage in mutual validation of our product when new releases are made available, and only bring them into use across their organizations once it has passed internal controls.

To this end, while continuous integration is an important part of our engineering ethos, and we would like to reap all the benefits of continuous delivery, it’s unlikely that we will push updates of our product to customers multiple times per day.

For software companies making use of Agile Methodologies, it would be a disservice to consider their application an all-or-nothing situation. Applying the practices appropriate for your business context is the most pragmatic approach. However, it’s also important to continually challenge traditional methods of project management to gain the benefits provided by Agile.

One suggestion for those who want to up their game in Agile is to choose a practice and focus on integrating it into your process until you achieve mastery in it. Just as with software development, process improvement is a practice best undertaken with incremental and steady approaches.

For more insights into adopting Agile practices across your organization, check out our on-demand webinar, “Agile Product Delivery Connects Your Business with Development Teams End to End.”