Skip to main content
Enterprise Agile Planning Image

This post is from the Collabnet VersionOne blog and has not been updated since the original publish date.

Last Updated Mar 17, 2012 — Enterprise Agile Planning expert

Learning Your Agile Scales / Part 2

Enterprise Agile Planning
In Part 1 of "Learning Your Agile Scales" I why it's important to learn and practice your scales in agile development. Here we will cover three forms of scales you should make part of your basic language: Test Driven/Development, Object Oriented principles (SOLID) and Patterns.Test Driven Development Writing a test prior to writing your code is not very controversial anymore.  Everyone recognizes the value in doing this.  And yet, most programmers will maybe write a few tests to get started, but then quickly move to an attitude of “I don’t have time right now; I’ll get to them later.”  This is totally understandable since the idea of writing tests first still feels counter/intuitive.  So do minor scales.  It takes repetition and practice to get this activity into our “muscle memory.”   Sometimes what we are doing is uncomfortable, or feels like it's wasting time.  We do it slowly at first.  But over time, it becomes an instinct. This instinctive activity is not going to happen just by doing it at work either.  Just as Uncle Bob Martin asserts in his latest book, Clean Coders, we need to practice at home, also. Find a project or site where you can practice writing tests and making them pass.  Get used to the idea of writing a test and then working to the "green bar."  We'll talk more about practicing in a later post, though.  Suffice to say, you need to practice, and a true professional will practice at home.SOLIDAnother form of scales is Object Oriented principles.  The best description of the principles that lead us to true success is the acronym SOLID.  This has been identified and explored in many forums, so I will only touch on them briefly.  For a deeper dive, check out Robert C. Martin's book, Agile Software Development, Principles Patterns and Practices.  Here is a link to an early article he posted on the subject. Meanwhile, for your dancing and dining pleasure, here are the SOLID principles, in brief:
  • Single Responsibility / An object should have one and only one reason to change.
  • Open/Closed  / A class should be open to extension, but closed to modification.
  • Liskov Substitution / Derived classes must be substitutable for their base classes.
  • Interface Segregation / Clients should not depend on methods they don't use.
  • Dependency Inversion / Modules should depend on absractions, not details.
One interesting parallel to our musical paradigm here is that, as you start to get very comfortable with staying within these principles, you start to notice things that are not quite right.  You are so used to looking at code that fits within the SOLID principles that it just seems natural.  Code constructs that violate these principles come across as out of tune // something we refer to in music quite often as "klunkers."  PatternsThe final scale I want to talk about is Design Patterns.  Patterns are another part of our basic language.  We need to work with them and be comfortable with them.  I am not a huge fan of saying, "Here is a problem; which pattern shall I apply to it?"  That feels artificial to me.  However, I also remember a time when I was just learning music that I did consciously say, "Now I am going to play notes from the B/flat blues progression."  As we are using patterns, we become more comfortable with looking at a problem and just knowing what we are going to do to implement it.  Later, when discussing it with someone, we note that what we did was apply a Visitor pattern. So, in conclusion, even though it isn't anywhere near as much fun as just going out there and soloing, we need to learn and practice our scales.  It isn't enough to read about them once, or to pull them out of our bag of tricks when we have enough time or remember to use them.  They need to be a part of what we do every day, and they need to be so ingrained in our brains that we don't even notice when we use them.  Hey, if it's good enough for the greatest performers and innovators who ever lived, surely it's good enough for us.What about Refactoring, you ask?  Refactoring is hugely valuable and extraordinarily important.  It is so important that I want to save it for next time, when we talk about Practicing.  Now I gotta run.  I gotta go practice.  

More from the Blog

View more
Apr 08, 2021

Making IT services more agile

Enterprise Agile Planning
The agile revolution completely transformed how we create digital prod ...
Read More
Feb 14, 2021

Reflecting on the 20th anniversary of the Agile Manifesto

Enterprise Agile Planning
Over the past 20 years, it’s been amazing to watch an idea from ...
Read More
Feb 08, 2021

How does agile apply to an entire organization?

Enterprise Agile Planning
Before we dive into the main subject of this blog post, it is importan ...
Read More
Feb 03, 2021

It took a pandemic to realize why digital transformation actually matters

Enterprise Agile Planning
Before anyone had ever heard of COVID-19, businesses across the globe ...
Read More
Contact Us