I really don't have time to be writing this blog entry. I should be working on the exam study guide for the Black Box Software Testing (BBST) course I'm taking through the Association for Software Testing (AST.) If not that, I should be finishing answers submitted some time ago to Ask the Tester through STP. I'm getting there, but a couple of the answers I wrote I'm not really satisfied with. I also should be polishing the slides for the presentations I'm doing at STPCon next month. ALMOST done, is not DONE. Right?
I needed to come up for air after having a bit of a break in my schedule though.
One of the commitments I have that is fairly long-standing is teaching drumming. Since July, I've been working with a group of absolute novice drummers with a pipe band on the East side of Michigan - about two hours from my home. So, we got together once each month in July, August and September, then twice a month since then. We met on Saturday afternoons for four hours.
The youngest student is eight years old, the oldest is in his late 30's. The goal was to teach them enough where they could play with their band. Two students had some drumming experience outside of the world of bagpipe bands: one is a middle-school student learning drums through school; the other is his dad. Dad had some drumming but no formal training. The lesson in July consisted of "This is a drumstick. This is how you hold a drumstick."
The first week of December, one of the students made a comment that he felt like they were doing a lot of exercises but bot really getting what they needed to actually play with a band. I asked what he meant. He said "We do all this stuff, I'm learning a lot but I'm not sure how it applies to me playing in the pipe band." My response was "You all are closer than you think. There is no reason why at least two of you will not be able to play with the band at the band's ceilidh (a party/celebration - lots of music and dancing and bagpipes) in February. Everyone else will be able to play with the band by May." They looked at me in complete disbelief.
The next lesson, shortly before Christmas, I passed out a new exercise, a full sheet of music. I told them, "This is a drum salute that you will all be playing in February. All of you can play everything on this page."
Their performance was last night. My lady-wfie and I, grandson as well, drove across the State to go to the band's ceilidh, which is their biggest fundraising event of the year. The place was packed - hundreds of people in a hall. A short introduction and the drumming students came out first - before the full band. Then they played. They did really well. I was terribly proud of them and what they had done.
When they finished as a group, the pipers marched into the hall and joined them. The students who were not quite ready stepped back and moved off stage while the other drummers played the rest of the performance. At the end of the night, this band came out again along with the two guest pipe bands and played together. Some of the stiudents went out to play with the other bands, some did not feel comfortable doing that. No worries. No pressure. The idea was to have fun.
All of them are reinvogorated. The most consistent comment I heard from them was how much fun they had playing. Even the ever-so-cool teenage boy smiled and said that was a lot more fun than his school stuff.
So, after driving back across the State this morning (hoping to beat the nasty weather predicted) I was thinking about the drumming students experience and my own with BBST. Part of the opening lecture was about reading carefully. I muffed two questions on the last quiz and one on the one before because I did NOT read carefully enough.
In working on answers to the essay questions in the exam study guide, I find myself challenging my own statements, thinking hard about the answers and running through them in my mind. I am finding myself more challenged than I have in some time to look at how I think about things, testing in particular.
In the current project at work (yeah, I'm trying to keep up with that as well) I find myself thinking about concepts I've just read or re-read from the course. (If the boss thinks I was passionate about how testing can be better at the company before this course, look out!)
It IS more work than I expected. I knew it was going to be a lot of work; it is simply more than I thought it would be. At the same time, I'm also having fun learning and stretching how I think about things. That is very rewarding in itself. So, yeah, like the drumming students, I'm having fun.
Oh. I forgot to mention that STPStanley came along with us. We took a lot of pictures and will be posting some of them shortly.
Showing posts with label Drumming. Show all posts
Showing posts with label Drumming. Show all posts
Sunday, February 20, 2011
Friday, October 1, 2010
Improving Processes and Other Stuff, Part 1
I've been teaching a lot of pipe band drumming workshops lately. Well, "a lot" compared to the last two years anyway. They can be hard, but generally are great fun. By the time I realize how tired I am, I'm half way home - close enough where a cup of Tim Horton's coffee will get me home (yes, there are some in Michigan.)
So, this last session was a mix of absolute beginners and those that were a step or two beyond that. They all play in the same band, or aspire to anyway, and so have a common bond between them. Part of the intention of the workshop organizers is to not only teach the beginners, but teach the more advanced players how to teach.
That actually is easier than it sounds, at least with drumming. I get to present an idea, work on some exercises, see who is getting it and who isn't. If it is a physical thing, there are other exercises to try. If it is a mental thing or thought process thing, then I present the same basic idea another way - changing the context sometimes makes it easier.
This last session we were working on triplets. Cool things, those triplets. They are also bread-and-butter stuff for pipe band drumming. The kind of thing where if you don't get them, your future as a pipe band drummer is quite limited. One guy was having a bit of a hard time with them than the other students. Mind you, these students ranged in age from 8 years to the mid-30's or so. This particular fellow was doing alright, but was having an issue with getting his head around the idea of "three notes where normally there are two."
I handed out a bunch of candy/sweets to the other participants and asked this fellow to play the bit he was having a problem with. Perfect. So I asked him to do it again. Perfect. Third time was still perfect. Hmmm... it does not look like its the actual "hard bit" thats the issue. So I had him play the exercise from the beginning. Trainwreck! Had him slow things down and do it again - same thing. The second time I noticed something in what he was doing. As he got closer to the "hard part" his grip tensed up (he gripped his sticks harder) his muscles in his forearms tensed visibly - both bad things for drummers. Try as he might, the sticks simply were not going to do what he wanted them to do. When he jumped right into it, things worked fine.
If the first step to solving a problem is recognizing you have a problem, how do you know what the problem is? In this poor fellow's case, he knew he had a problem and simply could not see what it was. It wasn't the problem he thought he was having - it some something else entirely. When he stayed relaxed throughout the line of the exercise, he played it flawlessly. Problem solved. But what was the problem?
When it comes to process improvement for nearly anything, I try and apply the same approach: There may be a problem, lets see what the symptoms are and see if we can isolate the problem - instead of whacking the symptoms or results of the problem.
When looking at Test Process Improvement in particular, the problem that gets described is usually a symptom or list of symptoms - not the actual problem. We can stomp on symptoms one at a time, without really addressing the crux if the problem. That will continue to churn and bubble and fester until something else breaks.
The "problems" presented usually are presented in a handfull of ways:
When I was younger and not as diplomatic as I am today, my reaction to each of those points generally ran something like "Compared to what?" Now, in my more mellow state and place of being, I only think that. Sometimes loudly, but what comes out of the mouth runs something like, "Can you explain what you mean by 'too long' so I can understand better what you expect? An awful lot of the time our original estimates on test effort or duration are based on the understanding of what the project will entail at the time the estimates are made. As the project develops, we learn more and that will impact both the revised effort estimates and the actual duration. What we are doing is based on the instructions given to us and the mandates for what critical processes must be validated. Perhaps this needs to be reconsidered."
So, I guess that's a long-winded version of "Compared to what?" but it tends to go over a bit better.
What I do wonder, however, when a boss-type says something like those statements, is "Are those symptoms or problems?" Are we running over timelines and cost estimates because of other things than lousy estimates? Are "due dates" being missed because of testing? Are there a flurry of defects keeping customers from using the new release?
Is there something else going on and these are perceptions of problems, rarther than symptoms of problems?
So, this last session was a mix of absolute beginners and those that were a step or two beyond that. They all play in the same band, or aspire to anyway, and so have a common bond between them. Part of the intention of the workshop organizers is to not only teach the beginners, but teach the more advanced players how to teach.
That actually is easier than it sounds, at least with drumming. I get to present an idea, work on some exercises, see who is getting it and who isn't. If it is a physical thing, there are other exercises to try. If it is a mental thing or thought process thing, then I present the same basic idea another way - changing the context sometimes makes it easier.
This last session we were working on triplets. Cool things, those triplets. They are also bread-and-butter stuff for pipe band drumming. The kind of thing where if you don't get them, your future as a pipe band drummer is quite limited. One guy was having a bit of a hard time with them than the other students. Mind you, these students ranged in age from 8 years to the mid-30's or so. This particular fellow was doing alright, but was having an issue with getting his head around the idea of "three notes where normally there are two."
I handed out a bunch of candy/sweets to the other participants and asked this fellow to play the bit he was having a problem with. Perfect. So I asked him to do it again. Perfect. Third time was still perfect. Hmmm... it does not look like its the actual "hard bit" thats the issue. So I had him play the exercise from the beginning. Trainwreck! Had him slow things down and do it again - same thing. The second time I noticed something in what he was doing. As he got closer to the "hard part" his grip tensed up (he gripped his sticks harder) his muscles in his forearms tensed visibly - both bad things for drummers. Try as he might, the sticks simply were not going to do what he wanted them to do. When he jumped right into it, things worked fine.
If the first step to solving a problem is recognizing you have a problem, how do you know what the problem is? In this poor fellow's case, he knew he had a problem and simply could not see what it was. It wasn't the problem he thought he was having - it some something else entirely. When he stayed relaxed throughout the line of the exercise, he played it flawlessly. Problem solved. But what was the problem?
When it comes to process improvement for nearly anything, I try and apply the same approach: There may be a problem, lets see what the symptoms are and see if we can isolate the problem - instead of whacking the symptoms or results of the problem.
When looking at Test Process Improvement in particular, the problem that gets described is usually a symptom or list of symptoms - not the actual problem. We can stomp on symptoms one at a time, without really addressing the crux if the problem. That will continue to churn and bubble and fester until something else breaks.
The "problems" presented usually are presented in a handfull of ways:
- Testing is taking too long;
- Testing costs too much;
- Too many defects are being found by customers.
When I was younger and not as diplomatic as I am today, my reaction to each of those points generally ran something like "Compared to what?" Now, in my more mellow state and place of being, I only think that. Sometimes loudly, but what comes out of the mouth runs something like, "Can you explain what you mean by 'too long' so I can understand better what you expect? An awful lot of the time our original estimates on test effort or duration are based on the understanding of what the project will entail at the time the estimates are made. As the project develops, we learn more and that will impact both the revised effort estimates and the actual duration. What we are doing is based on the instructions given to us and the mandates for what critical processes must be validated. Perhaps this needs to be reconsidered."
So, I guess that's a long-winded version of "Compared to what?" but it tends to go over a bit better.
What I do wonder, however, when a boss-type says something like those statements, is "Are those symptoms or problems?" Are we running over timelines and cost estimates because of other things than lousy estimates? Are "due dates" being missed because of testing? Are there a flurry of defects keeping customers from using the new release?
Is there something else going on and these are perceptions of problems, rarther than symptoms of problems?
Subscribe to:
Posts (Atom)
