The more I visit companies and see mangled agile implementations, the more I’m convinced that quality, or lack thereof, remains the central issue to effective agility. Organizations begin agile implementations with higher quality as the goal, but then too frequently don’t carry through with the discipline to achieve the goals they have established. There are goals and desires, but not enough engagement and commitment. Admittedly, a critical problem is often the relentless pressure on delivery, but managers must step up and begin to transition from the vicious cycle of “incur technical debt, slow delivery, increase pressure, fail to repay debt, incur more technical debt” to a virtuous cycle of “build high quality, speed delivery, decrease pressure, and repay debt.”
When you are caught in the bowels of a vicious cycle, turning it
around is a management issue. Of course, the technical teams must
embrace the requisite practices and discipline, but without managers and
executives who are engaged in seeing that quality is critical to the
turnaround, teams will have a very difficult time delivering quality
products. The strategy needs to move from more features, more features
to fewer features, high quality, then more features.
But what does engagement in quality mean? Probably the most difficult task is for managers to really commit to the short-term pain required to deliver long-term gain. The gain may take only months to achieve, but there is always the pain of short-term performance loss (and the investment) while people learn new practices. Unfortunately, this pain leads to lack of full commitment, where managers fail to push their teams to full implementation—they get the pain, without the gain. This lack of commitment comes from lack of real understanding of how quality impacts speed, lack of understanding of how technical practices fit together (refactoring, test first and simple design for example), and lack of understanding appropriate quality tradeoffs.
For example, under pressure many managers succumb to feature delivery over quality because they think quality shortcuts are detrimental long term, while feature delivery is short term (short term gain for long term pain). However, what we now know from effective agile teams is that inattention to quality begins to degrade delivery velocity in only a few iterations. The road to fast, productive software development goes through quality—which has been proven again and again by metrics gurus like Capers Jones and Michael Mah—but which is still not believed by many.
Managers are often caught in a perceived dilemma between perfection and “nice to have.” On one side they are often skeptical of what they perceive as the technical team’s desire for perfection. They can’t discern the difference between perfection and excellence, so they fail to support adequate quality measures. They know whether or not a feature gets delivered to the customer, they don’t really know its quality. They also need to understand the difference between the two aspects of quality: reliability and adaptability. Reliability measures how well software functions today without errors. Adaptability measures how easily that software can respond to future change.
Quality software requires engagement and execution. Execution is the realm of the technical team. Engagement is the management side. Managers must do more than say “quality is job 1” every two months. They must understand the right quality framework; they must find the appropriate balance between features and adaptability; they must recognize the impact of technical debt; they must invest in training, tools, and time; and they must have the commitment and discipline to deliver quality products in the face of feature pressure.