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

SOLID

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

 

Patterns

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
Jul 27, 2021

Digital.ai Becomes First to Achieve FedRAMP Moderate “In Process” Status for Enterprise Agile Planning Solution

Enterprise Agile Planning
Digital.ai, the leading AI-driven DevOps value stream delivery, and ma ...
Read More
Jun 21, 2021

How Agile can be implemented effectively across the organization

Enterprise Agile Planning
Just a few decades ago, a “disruption” was seen as an undesirable thin ...
Read More
May 31, 2021

Agile change management processes are key to delivering software faster

Enterprise Agile Planning
With its emphasis on delivery value faster, agile product management s ...
Read More
May 03, 2021

Bringing the agile planning approach to your whole business

Enterprise Agile Planning
The events of the last 12 months have demonstrated that the only sure ...
Read More
Contact Us