Presentation: Ken Schwaber on Code Quality as a Corporate Asset
- 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.
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 FunctionalitySchwaber 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.
- 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.
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.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:
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.
Apprise the CEO of this problem: that this is the root cause that the company cannot build new software to meet competitive threats.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.
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.
A ray of hope
Tangosol Coherence: Clustered Cache
The importance of Transparency and Ethics
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.
Re: The importance of Transparency and Ethics
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 :-)
Re: The importance of Transparency and Ethics
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.