Presentation: Ken Schwaber on Code Quality as a Corporate Asset

Posted by Deborah Hartmann Preuss on Nov 13, 2006

Sections

Process & Practices,

Architecture & Design

Topics

Delivering Quality ,

Delivering Value ,

Agile ,

Agile in the Enterprise

Tags

Testing ,

Scrum ,

Antipatterns ,

Agile2006 ,

Planning

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.

1. Back to top

   A ray of hope

   by Cameron Purdy

   I tend to disagree with a lot of the Agile(tm) Consultants(tm) and Speakers(tm), but I really do like the core idea that one can view "Code Quality as a Corporate Asset". Whether or not one can have get "the CEO [to come] into the room and [say]" anything seems about as far-fetched as the other Schwaberisms, but we (anyone writing code -- even test code and example code) should always view "Code Quality as a Corporate Asset", and we should also view it as our craft, i.e. we should build it with great pride of worksmanship.
   
   Peace,
   
   Cameron Purdy
   Tangosol Coherence: Clustered Cache

   Reply

2. Back to top

   The importance of Transparency and Ethics

   by Noah Campbell

   Great presentation!
   
   I have to admit that I too find the Agile(tm) Consultants(tm) and Speakers(tm) to be a bit underwhelming in their rhetoric. Scrum as a management process is what usually draws me to these presentations and the key to this presentation is that Scrum builds in transparency into the process. That's not to say that RUP, Waterfall, etc. can have equal transparency, but short iterations do put the spotlight on potentially ugly practices...and that's the key to the this presentation. What do you do when presented with difficult decisions?
   
   In Beck and Schwaber's words: have the courage to do the ethical thing.

   Reply

3. Back to top

   Re: The importance of Transparency and Ethics

   by Deborah Hartmann

   Scrum as a management process is what usually draws me to these presentations and the key to this presentation is that Scrum builds in transparency into the process.

   Yes, this emphasis on transparency is one of the things that draws me to Scrum as well. But, as others have said, a good process cannot "fix" shoddy developers. Scrum relies on the team to bring skill and common sense into the mix.
   
   We can add: a good process cannot hide or compensate for a lack of coaching ethics. We need good processes and good people. If forced to choose... recent experience suggests: go with the good people :-)

   Reply

4. Back to top

   Re: The importance of Transparency and Ethics

   by Noah Campbell

   If forced to choose... recent experience suggests: go with the good people :-)

   
   
   Hopefully you're never forced to choose. I think your point about going with good people as a safe bet is that someone will emerge as a leader and put a process in a place.

   Reply

• Older >