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?
No comments:
Post a Comment