Scrum won’t work without clean, tested code
I was with Ken Schwaber before Christmas and of course, we talked about Scrum and the plague of flaccid Scrum and flaccid developpers.
Scrum is a very simple framework, which when used right, will bring to light a lot of long standing dysfunctions and bad practices. This is because transparency is emphasized in Scrum projects. One of the major dysfunctions development teams suffer from is completely inadequate development practices. This is true in a waterfall project but often hard to see clearly. On a Scrum project, on the other hand, the impact of writing poor and untested code will be seen every sprint. To quote Ken :
Emerging architecture only works if you write clean code and tests around it, otherwise by the third sprint, you’re dead.
It’s hard to say it any simpler than that.
On a waterfall project with unskilled developers that miss modern engineering, architecture and test practices, you’re usually dead by the third version of the product. You have to start over from a new code base while maintaining the old code. The all too common nightmare of our industry.
On a Scrum project with developers unable to write clean and tested code to produce a potentially shippable increment of the product within the sprint, you’ll be dead by the third sprint, which is good news.
As professional programmers, we have to stop the belief in magic. Writing poor or untested code to meet a deadline will lead you nowhere. It will only hurt long term product sustainability and viability. As Uncle Bob rightly said it in Clean Code, cutting corners to meet your deadline is the surest way to not make the deadline. The only way to go fast is to write clean code. We’ll fix it later always end up to be we’ll never fix it.
P.S. If you can read French, you might be interested in some advice from Marc-André to help you with your Flaccid Scrum
