I've decided to mostly keep just one blog and start doing a better job with tags for separating out categories. In that spirit, this one is for my own tracking of piano progress. But, it will have some tangents with agile, anyway.
A few years ago when I decided I wanted to stop just toying with "Alfred's All in One Adult Beginner Course", I realized I needed to focus on one complete song, from end to end. I even joked with a coworker who I had helped introduce Scrum at a company with that I was going to work toward a "potentially performable songware increment", like Scrum's "potentially shippable software increment".
This absolutely worked for me. I focused on learning a relatively short song called "October", a song that features mostly piano, from the 1981 album of the same name by U2. I picked this because I remembered long ago wondering what I would have to do to play it if I actually knew how to play piano.
But, it also reminded me of my aunt Kara, because she had introduced U2's music to me when I was 10 years old in 1987 by handing me a copied tape of The Joshua Tree, complete with a photo-copied insert cover.
Kara was by this later time in 2008 ill with Lou Gehrig's disease. I wanted to be able to play the song someday for her. I soon became proficient enough with the song on my little electronic keyboard, and recorded it on MP3 and sent it to her. Later, after she passed away in early 2011, I performed the song at her memorial service, which was about a year ago now in June of 2011.
For me, someone who had only played a recorder in 2nd grade, to ever have imagined myself performing anything musical in front of people was a big confidence booster. I did not make any glaring mistakes either, which I was also happy about (phew!)
During the process of *learning how to play that first "playable song increment"*, there is no way a teacher would look at what I was doing and say my form was correct, or that my fingering was optimal.
I had one teacher as Little Five Points Music Center, Natia, who helped me get through that first song and started me on what has become a more "methodologically sound" approach to learning, which includes understanding reading music, understanding scales, intervals, chords, modes, etc.
But, again, in the beginning, I simply forced myself, note by note and measure by measure to figure out which keys to push down with the right hand and which to hold down with the left hand, and eventually when to push the pedal with my foot -- which I still don't have totally correct.
I have now been taking lessons with Charles Hutton, from Charles Hutton Piano Studio, for almost a year now after that first performance. He has helped me start from where I was to progress through playable "increments" of music that teach the fundamentals of scales, chords, inversions, and intervals. Each song has helped me to experience the important satisfaction of adding to my reportoire, or my "portfolio" if you will, while also learning about those musical theory concepts.
I would, as I am sure he would, still classify myself as an "Advanced Beginner". But, if you are the kind of learner, like I am, who cannot sit still, physically or mentally, without a combined practical and theoretical understanding, then I would definitely recommend Charles and his approach for learning.
Touching back on agile software, we know that Iteration is fundamental to Incremental delivery. That,is, one must build a software module in an iterative fashion. Iteration means approaching the analysis, design, development, deployment, and testing in repeated cycles. This is coupled with incrementalism, which means approaching the problem by breaking the large goal, the entire system, into smaller slices.
During each iteration, learning happens. This learning then feeds back into the next iterative step. This process cycles round and round and continues to pull in more and more incremental slices of the system as it goes. This process resembles the "Plan Do Check Act" approach, and even the basics of the "Scientific Method".
Given a piece of music, it is already replete with requirements! After all, the sheet music is staring you in the face. All you have to do is read that requirements document and just play it.
Of course, a software requirements document is rarely anywhere near as complete or unambiguous as a sheet of music is. No, not even close, and that is a subject for a different day.
It is actually highly possible for well trained, seasoned musicians, of course, to sit down in front of a piano and play directly from the sheet music the first time they see it. Sometimes in one sitting they can get it "right". Even then, they will rarely feel like they did it perfectly the first time, and will repeat it many times before feeling proficient.
I have been struggling to feel any real progress recently in learning new songs, partly due to lack of practice time, but partly due to gaps in my approach, which Charles has helped me to see and approach differently, and in fact much closer to the way I develop a software program anyway.
Here's how:
First, from reading Neil Miller's The Piano Lessons Book, I became convinced of the "Learn it Backwards" method, something Charles also said other teachers call "The Reverse Brick Laying Method".
This means take the last two measures of a song, learn those FIRST! Then, add measures backward toward the beginning.
Why? Well, when you start to play back what you have practiced this way, you start at what you more recently learned, and have played fewer times, and progress toward measures you have played more often.
Since you have played them fewer times, you are more likely to make a mistake on those, and will thus waste less time than if you were to always play back from the beginning and into less frequently practiced measures toward the end.
However, Charles helped me to start to logically segment pieces into phrases and groups of measures that flow well together. So, in my current piece, Sonatina I by Thomas Attwood, we have marked off measures 17 to 24 as a logical group.
Within that, we have:
17 to 18 Right Hand
19 to 20 RH
17 to 20 RH
21 to 22 RH
21 to 24 RH
17 to 24 RH
Then, same thing but with Left Hand, or bass.
And, then trying them with both left and right hands.
As you can tell, this is the epitome of an Iterative, and Incremental development process.
And, it is also an iterative and incremental analysis, design, and delivery method.
Here is how Charles has explained what should happen when practicing this way, and what it should feel like:
When playing 17 to 18, do it slowly enough to play the notes correctly, and with the correct fingering, ignoring the rhythm count for the moment.
Next, try it again, slightly faster.
If I make a mistake, then learning has not happened properly yet, and something is wrong. Stop the line. Correct it immediately. Go back.
But, wait, here is where we diverge from "Lean Manufacturing" and it's "stop the line" mantra you may recognize and move closer into agile software, at least the way I see agile.
As Charles explained it, helping me get past my reluctance to move further into more measures, you MUST move forward when still uncomfortable, and while still *making mistakes*.
That is: yes, stop and fix the measure, to a point. But, after correcting it to a sufficient degree, expand the surface area of practice. Move down to measures 19 and 20. If you flub on those, also stop and fix, but only to the point of basic comfort.
Then, cycle back (iterate) on measures 17 through 20.
Again, this iteration should procede slowly enough to get the notes correct the first time. But, next it should be played at a more uncomfortable, error-prone pace.
When making errors at this pace, seek to "pin point" where, and then "zoom in" on those points.
Are they transition points?
Are they fingering oddities or shifts?
Incorrect fingerings?
Incorrect timing? Held a note too long, not long enough?
The diagnosis will vary from "fracture" to fracture, now zoom in and correct it in *isolation*, or in collaboration with adjacent measures to assure smooth entry and exit.
According to Charles, doing this will NOT feel comfortable, and mistakes and fractures will happen. This is expected and good, and the remedy is the iterative process, the repeition, the cycle.
What mitigates against the failure besides the repitition? What ensures eventual success?
Well, quite simply: your own ears and others' ears. The expectation of correct playback is already encoded in our ears. We will know it when we hear it. Fair enough.
The parallel to software development here is more nuanced. We cannot know that a subsystem of function works by hearing or seeing it! Most of software happens below the user interface, and nobody ever sees or hears it.
This is why the test-driven, unit-test covered, and acceptance-test driven approaches to software are so important.
TODO: fnsh
