Software Development and Testing Agility Demands Fungibility
My dad was a down-to-earth, blue-collar worker who had a sincere love of life and a simple view of the world. While kind and respectful, he didn’t have much use for those who used what he called “fancy language” to promote themselves. When he heard someone using an uncommon word he hadn’t heard before, he’d say, “I’ll give you a dollar for that word”—meaning he’d give you a dollar to stop using it!
Dad might give me a buck for using the word fungible. Nonetheless, I think it’s an important term in the context of our agile culture. Fungible means replaceable or interchangeable. Contrast this with transformation or improvement, which are about moving from our current state to some desired future state. Transformative change may be evolutionary or revolutionary. Fungibility is inherent: the ability to change without needing an external catalyst.
In our agile culture, fungibility is a critical characteristic. The triad of people, processes, and technology ideally should all be fungible. Just like perfection, this may never be attainable in our lifetimes, but it’s an important goal to work toward.
Imagine an agile team equipped with the knowledge and expertise to quickly adapt to multiple challenges or circumstances; processes that can be immediately aligned to support the current product owner and business needs; and technology that can effortlessly morph in support of the people and processes to complete a particular design, development, deployment, and delivery challenge.
I have the privilege of working with many software engineering and testing teams. These teams work extremely hard to develop, test, and deliver digital capabilities that meet their customers’ needs, yet many continue to struggle with the ability to change—to develop and draw out the characteristic of fungibility. One specific example is my experience with helping teams embed testing in every aspect of their projects, from concept to delivery. It’s easy to say “We want to drive testing earlier,” but it’s challenging to actualize this goal.
I often work with people in testing roles who are solely interested in how they can complete the functional testing in the current sprint, or with developers who are only concerned with completing the code for a given feature. These are certainly important responsibilities, and understandably, these roles are responding to the way they are measured. However, some teams miss the broader goal of not only delivering results, but also investing in the design, development, and implementation of fungible resources—equipping people with the skills, knowledge, and wisdom to adapt, to design processes that are adaptable, and to employ technology that is interchangeable.
Consider embracing the word fungibility and nurturing its characteristic within your agile teams. As your resources become more fungible, my experience is that they’ll yield more than just a dollar!
