Skip to main content
Enterprise Agile Planning icon with arrows

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

Last Updated Mar 18, 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.


Another 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.”



The 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.


The post Learning Your Agile Scales – Part 2 appeared first on VersionOne Blog.

More from the Blog

View more Government Cloud
Apr 12, 2022 Government Cloud receives FedRAMP Authorization through sponsorship from the United States Department of Veterans Affairs

Enterprise Agile Planning
Flagship Agility solutions can effectively scale agile deve ...
Read More
Nov 22, 2021

What are the qualities of highly effective agile teams?

Enterprise Agile Planning
A team is the core unit of productivity in an agile organization. Wher ...
Read More
Nov 15, 2021

How an open-first attitude revolutionized government tech development

Enterprise Agile Planning
Public perception of government is often that it is slow-moving, reluc ...
Read More
cross functional
Nov 08, 2021

6 best practices for building resilient cross-functional teams

Enterprise Agile Planning
Agile frameworks prize the quality of resilience within every facet of ...
Read More
Contact Us