As is true with most popular phrases, the term “Agile,” is subject to personal interpretation. For me, “Agile” paints in my head the picture of a gymnast, acrobat or capoeira player.
Agility is the ability to – using discipline, control, focus and sensation – make movements that for most people seem impossible to achieve. Quality is the objective, collective perception of this movement to be a great and beautiful manifestation of the selected art, product or service – in our case, software products.
How does an acrobat or a capoeira player achieve agility? Through endless training. Through countless mistakes. By crying, sweating, and cursing for a long time. By occasionally losing hope of one’s ability or focus. By never giving up.
How do acrobats achieve quality in their art? By endless training. By attentively listening to mentors and trainers. By experimenting and creating their own way of doing it. By innovating the art to exceed the standards and achievement of their trainers. By outlearning the mentor.
The same applies to software development.
Our team recently set the goal to achieve a “quality process that everyone respects and agrees upon.” How do you gain respect? Specifically, how do you gain respect when there are people involved who do not even think the same way as you.
As an acrobat, you’re often dependent on your fellow teammates to catch you when you jump from that trapeze for the first time. As a capoeira player, you can’t achieve a high quality performance without your band playing the music around you and the support of the audience. Without these aspects, you’re ultimately just in another lonely training session.
As a software team we cannot do anything without trusting our fellow team members to make decisions; selecting a tool, for example, or following a new principle. Without trust, the process will stop at the training stage, without achieving that leap to performance. To achieve Agile Quality, you need to trust your mates to catch you even if you missed the pre–performance strategy gathering, a retrospective or sprint planning.
Agile Quality is only possible when you can trust your team to perform the art of creating a high-standard product, even when you’re not around.
For that you are not only dependent on your fellow software team, you are dependent on the whole product team. You also rely on the most remote parts of the team The janitor who ties the acrobatical tires you are walking on. To the cleaner making sure no trash is in the way when you jump. The marketer that “just” advertise your performance – so you’ll actually have an audience. The distant top executive manager, whom you hardly know the name of.
How to gain trust?
Start with yourself. How do you show trust toward the new acrobat on the team, or the beginner capoeira performer that hardly knows how to walk properly? Do you trust that he might outperform you? How do you know he will actually share the credit for that with you?
To build Agile Quality is to start to trust other people. To take responsibility to “let go” in the right moments, and have others make decisions for you sometimes. To dig in and not take “No” (or indifference) for an answer when it really matters. To have the maturity to make the difference between the two, and the childishness to just follow your impulse and innovate when everyone is against your idea.
Another aspect of Agile is the disciplined ability to adapt to new circumstances, new environments, new learnings and new people joining the team.
Agile Quality is a living definition and practice.
We must grasp the ability to – in a disciplined way – change and improve the way we perceive, define and implement quality thinking. We learn new things, and we set higher and higher expectations on ourselves and our products. To be Agile is to never be content with status quo; to relentlessly strive for even higher quality, and to stay in business.
At the same time it’s about having a “good enough” scoped thinking. We don’t need to be perfect to put on a performance (release our product).
We must have enough courage to question our last performance no matter how good it was. We must get the prerequisites to be able to constantly adopt to higher standards and ever changing expectations from our customers and end users.
In our team, we can see that we’ve done a lot of improvements on quality in the last year. Things we didn’t even consider important a year ago now seen as low ambition.
But can’t we just settle back and look back on all the good things we have done?
Yes, of course, that’s also part of Agile Quality. To dare to freeze the improvements for a little while, to take the time to gather data on what we have, before taking the next step. Agile is also the ability to STOP activities. To give ourselves and our team a break, to enjoy the quality efforts we have taken. Keeping the mindset of coming back to improve what we do, and creating better products that will delight our customers even more.
Agile Quality is to delight our customers. That is Agile Quality for me. What is it for you?
About the author
I have been developing software in different roles for 15 years. In 2005 I first started to work with Scrum, Extreme Programming and other Agile methods. For me that was something real to hold onto: usable guiding principles, practices & rules, something else than the abstract document-heavy project models I had learned before. The built-in practice of continuous learning in all these agile methods is something that I believe in and have seen create high performing teams and delight customers in different contexts.
Today I work as a ScrumMaster in one of SmartBears product development teams.