Agility & Managing Quality
Join the DZone community and get the full member experience.
Join For FreeThe 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.
Opinions expressed by DZone contributors are their own.
Comments