Presentation: Ken Schwaber on Code Quality as a Corporate Asset

Ken Schwaber, co-creator of Scrum and head of the Scrum Alliance, spoke at Agile2006 on code quality as a corporate asset, controversially telling conference-goers that "a drop in code quality is a drop in the value of a core asset of the company, and ... that [makes it] a CFO, COO, CEO type of decision."  InfoQ presents exclusive video of his talk, along with Schwaber's slides, in The Canary in the Coalmine. This presentation covers:

• The way product owners and teams should work together
• The place that product owners and teams come from, using Waterfall
• How Scrum falls apart if these habits persist
• How organizations have fallen apart because of these habits
• How to undo these habits.

When people try to use Scrum as a silver bullet, that is, to solve the unsolveable (for example, delivering 14 months' work in 9 months), Schwaber says he commonly hears it expressed as "Scrum doesn't work," but he knows that the flip side of this is: "Scrum has exposed an organizational problem, which runs really deep."  Experienced practitioners recognise these unwelcomed revelations as opportunities - they provide management and developers the chance to adjust direction early, and take aim toward success.  But it's not easy - Schwaber reminded listeners that courage is required to reap the benefits of of these uncomfortable moments of truth. 

One uncomfortable truth that Scrum can surface is the existence of a culture that produces unmaintainable, cobbled-together legacy code, or as Schwaber called it in this presentation, "Core Functionality".  Schwaber described it as follows:

Core Functionality

• Most significant new functionality builds on it;
  
• It is fragile, it doesn’t have test harnesses;
  
• Few people still know how to (or are willing to) touch it; and,
  
• It requires more time to work on (lower velocity) than new code.
• Sometimes called infrastructure or legacy software.

Schwaber talked about system maintenance as a key indicator of poor-quality core software, the extreme case being what he called "design-dead code", which paralyses development whenever integration of new code depends on changes to core code, where development is painfully slow and risky.  He pointed out that quality isn't some intangible thing: it can actually be measured by the amount of time the team spends maintaining the system. This becomes critical when it impacts delivery of software that could offer competitive advantage, giving the example of Microsoft's long product delivery cycle versus Google's very short cycles.  Even when teams use Agile methods, their "Agile advantage" can be more than negated if code quality slips, progressively reducing velocity until the team, and the company, are unable to respond rapidly to change.

We've all seen teams come up with creative solutions to deliver despite heinous quality problems in existing core software - including recreating core functionality inside their own application.  This is just one way that systems become fragmented and difficult to maintain, hampering subsequent projects, until a complete system rewrite looks cheaper than continuing to work with the degraded core codebase.

How do teams find themselves in this all-too-common position?  If IT has been acquiescing to unreasonable demands, we continually reinforce the idea that we're goofing off, since we always seem able to squeeze out more when push comes to shove.  Doing so builds up a perception that cramming in extra features is free!   Whereas, in fact, we're fitting it in by dropping quality.  Schwaber's point: "By dropping quality to save our jobs, our customers have come to believe that this 'magic' has no cost, whereas in fact we're severely damaging our companies in the process."

Schwaber says: "As long as we fold, they will continue to ask us to fold."  Schwaber's solution:

We have to be courageous.  The intention of this conversation is to make you aware that it's not just a phrase, "be courageous", but it's a professional responsibility which, if you follow up on it, not only will you feel better when you come to work, but it is for the good of your company.  And if you don't do it... it's going to kill your company. This is not just a  trivial little thing, "let's not refactor because...", this is a sacred trust ... to drop quality is a catastrophe for our company. 

Worse yet, our pattern is not to tell anyone, right?  So a classic thing we do now is: if you are in a release and the customer absolutely has to have it earlier and the quality has to be dropped... that is not a Product Owner decision, that is not a Customer decision, that is a drop in the value of a core asset of the company, and it has to go in the books.  That is a CFO, COO, CEO type of decision. 

Schwaber proposed strategies for disengaging from the vicious downward spiral, including building models and tracking delivery cycle time against competitors to evaluate the impact of decreased velocity due to poor quality, to allow executives to make informed strategic decisions.  He also proposed:

Apprise the CEO of this problem: that this is the root cause that the company cannot build new software to meet competitive threats.

Why? Because the only time I've succeeded in getting engineers over the fear of actually standing up and saying "I know that you really want to do that, but it's not a velocity that's sustainable to us at the quality that the company expects," is when the CEO comes into the room and says "If anyone tries pushing you or bullying you into something you can't do, you come to me," because now everyone knows the consequences.

Schwaber is an informative and entertaining speaker, even while he's tackling these uncomfortable truths.  Watch the InfoQ video of Ken Schwaber's Agile 2006 presentation: The Canary in the Coalmine.