There are a number of great observations worth reflecting about in this article https://www.linkedin.com/pulse/do-we-still-need-quality-management-agile-delivery-world-shanks/ by Misha Shanks. Her discussion whether “Agile [is] more about quality or speed — or can it be about both?” caught my particular attention as I am repeatedly drawn into similar debates. Misha actually quotes Bob Galen, one of the veterans in the field:
Agile isn’t a “speed play” it’s a “quality“ play that might be able to go fast (under the right circumstances).
It’s not only that I strongly agree, here is my argument that I have often made successfully when trying to explain why I think so.
The key thought behind this hierarchy of engineering capabilities goes like this: Any software engineering organization that needs to deliver products has the need for achieving transparency — particularly concerning the true quality status of their deliverable(s).
- Only once transparency has been achieved, we will know where our challenges are, what about our current way of working will likely need improvement, so that we know which levers to pull to improve the outcome of our work, the product quality.
- Only once we have achieved transparency and quality, we have a real shot at achieving predictability — e.g. being able to deliver reliably on schedule once a quarter, once a month, once every week or every day — or even by the second or even less once the delivery model has shifted from traditional packaged (big) releases to ongoing feature streams following the devops model.
- Once we have satisfied these three basic or defensive needs of transparency, quality and predictability, we can shift our focus to the growth needs — obviously while maintaining and hopefully still improving our capacity to fulfill our defensive needs by the way!
- The first growth need is to increase the engineering outcome capacity. Only once we have build up all of these capabilities, we will be able to drive innovative solutions delivered in a sustainable manner. This assumes a strong product discovery stream through respective product management and / or technology research capability— which would be another big topic for discussion.
How to accomplish these capabilities? For example, an engineering organization that hasn’t defined even a basic definition of done (DoD) usually struggles debating whether a user story or feature or even an entire release is really “done” and can be released to users. Such teams usually lag transparency of their true product quality status.
However, transparency about your current situation including the shortcomings as a baseline are paramount to analyze and understand their root causes in order to define the target state plus the transformation activities needed for sustainable improvement. Defining and rigorously following a definition of ready (DoR) and definition of done (DoD) help to improve the quality step by step so that predictability becomes feasible. For software engineering teams this usually goes hand in had with introduction or strengthening of a common way of working that employs a state of the art devops toolchain including tools for CI / CD.
To close the loop, once all of these things and the many other agile ingredients like an agile mindset, agile principles and practices have been successfully implemented and fully embraced, then the right circumstances might be in place “to go fast”.
[This post appeared first here:
https://medium.com/@whilpert/is-agile-about-speed-or-about-quality-fbb5abe61096]