Monday, May 30, 2011

Oakland's City Council Is Up To No Good -- YET AGAIN

The Oakland Animal Services shelter is one of the only "no questions asked" shelters in my area -- they take everyone, including owner surrenders.

As someone who's helping a friend re-home a cat, I can tell you that it's incredibly hard -- if not impossible -- to find any place that will take an owner surrender of an animal with a less-than-stellar temperament (uh - not uncommon in cats, by the way).

Because no one will take these unwanted pets is one of the contributing factors to the stray and abused animal population. And this is one of many reasons why having an Oakland Animal Services is critical for all of us -- bipedal and quadrupedal alike.

A friend of mine is a volunteer at OAS and the stories she tells about the work they do is incredible. Ever watch any of the "Animal Cops" shows? Yeah: it's like that, only in real life.

And now they want to outsource (in essence, privatize) the City shelter -- HUH?

For those of you who are locals, please read and write, email, or otherwise speak up about this and help Save Oakland's Shelter.

Friday, May 27, 2011

Agile-ity Training: Dog Training as an Iterative Process (Part Four)

Then the team does it all over again...

So I've now shown how training my dog not to jump meant that I first performed a little bit of requirements gathering and then I had to do a little bit of design, coding and testing along the way:

I did this by initially starting in very small increments of time (given my dog's short attention span) and then  mark and reward in order to encourage even longer stays (increased increments of time). As the stays became longer, I also added other actions, i.e., door knocking, rattling the door knob, etc.. Finally, I tested (or "proofed,") the sit/stay, first by using her favorite person inside the house and then moving the entire process to outdoor areas (dog parks, hiking trails, etc.), ever increasing both time and distance.

As I've mentioned, my dog has about a 98% success rate of not jumping on her favorite people. Actually, this number is probably statistically higher -- we'll say 99%.  Liffey jumping on her favorite folks is entirely random -- I haven't quite figured out what makes her "lose her mind for a minute" and forget her training.

Is it because the favorite people are accompanied by her favorite (dog) friends? Is it because x number of days have passed since we've seen these people? And, since she doesn't do this every time she sees her favorites - be they dog or human - then it's much more difficult to pin down a solution. Is it something I'm doing or not doing that's triggering her jump mechanism?

Thus, the requirement for this second iteration has slightly changed from the first to: no jumping; specifically, no jumping on anyone, ever.  

The difference in this new requirement is that her behavior is sporadic and has no particular pattern that's apparent to me. Or, as a QA tester might put it, "this bug isn't perfectly reproducible."  My response to this is:  but it isn't perfectly irreproducible, either; until we confirm one way or the other, it's still a valid, OPEN defect.

For now, I'll just consider this feature to be still in the re-design phase...

Tuesday, May 24, 2011

Agile-ity Training: Dog Training as an Iterative Process (Part Three)

Did teaching my dog not to jump take time? Absolutely. The entire process is what I would certainly describe as “iterative,” – and because we're talking about an individual living creature with a will of her own and not an inanimate project, there was backsliding, too. So I had to inspect and adapt regularly as we went along.

For instance, one day she would do her sit/stays perfectly; the next, she would act as if she'd never received a day's training in her life (as if she were raised by.. you know -- wolves). Those were the days when it behooved me to be even more consistent, to reinforce even more positively and to get creative. I would make a game of it by getting her into a sit/stay, hiding somewhere, and then releasing her to come find me: doggie hide-and-seek.

So, from the very humble beginning of a basic “sit;” over time and in small, realistic iterations, happily benefiting from the little bit of value delivered along the way, I now have a dog who does not jump on strangers and who has about a 98% success rate with not jumping on her favorite people.  As for jumping on other dogs, well.. I think I'll let that one slide: the other dogs don't seem to mind, after all.

Monday, May 23, 2011

Agile-ity Training: Dog Training as an Iterative Process (Part Two)

After the one- or two-second sit was well in hand, we extended the time and continued adding more until it was no longer an issue – until Liffey could consistently stay until I released her, however long that may take. As more time is added to her stays, my dog is delivering more value.

And as the training progressed, I was able to inspect and adapt both her ability to sit and stay (until released) and the level of distraction within which she had to maintain those stays. As I've mentioned, we practiced at home and in fun and distracting outdoor spaces.  I also increased the challenge at home by going to the door and knocking on it; sometimes the knocking would be accompanied by door rattling or knob shaking - anything to make the sit/stay process that much harder for a happy, excitable dog.

When she showed that she was ready, I introduced the further challenge of an actual visitor.

Now, I'm sure that my dog would tell us, if she could, that one of the toughest challenges she had to face in her young life was to keep her rear end on the floor in the presence of her favorite person in the world: her dog walker. But she did do it. Again, at first it was for a mere few seconds; over time she was able to hold her stay until released.*

*Of course, I should also say that this required the cooperation of our amazingly patient dog walker (we miss you, Tami!): she would essentially ignore my dog until released and free to say hello – and then she would physically lower herself to greet my pup, so that keeping "four on the floor" was much more feasible.

Sunday, May 22, 2011

Agile-ity Training: Dog Training as an Iterative Process (Part One)

Recently, after spending a few hours with me and my dog Liffey, a friend asked me how long after I got her did I begin training her?

"Immediately," was my answer. He was surprised that I didn't wait for her to reach some developmental milestone before I began teaching her. I explained to him that he may have been thinking about old-school, traditional (aversive) training techniques, which generally recommend waiting until a puppy is four months old before beginning training.

But thanks to the work and research of animal ethologists, behaviorists, trainers and veterinarians from the last several decades, we know now that puppies are perfectly capable of learning simple behaviors like "sit," very early in their lives. Some service dogsinterestingly, begin their learning as early as six weeks old; a good, reputable breeder begins imprinting puppies even earlier than this.

[My pup came to me at 8.5 weeks knowing the sit,down, leave it and take it, which the fine folks at the East Bay SPCA had taught her and which we use to this very day.]

The fact is, that dog training is an iterative process; as such, the experts suggest we begin training our pups immediately, rather than wait for a select milestone in the project schedule.. er, I mean, a select milestone in their development.

What do I mean, exactly, by "iterative?" You'll recall that I previously quoted The Elements of Scrum:

a little bit of requirements gathering, a little bit of design, coding and testing, and delivers a little bit of value..”  and then you do it again.

We can certainly think of dog training in the same way.

Let's take jumping, for example. On a regular, consistent basis, I am jumped on by every kind of dog, from 90-pound American field Labs to 5-pound chihuahuas and everything in between. I have been jumped on by every age of dog, as well, including adult and senior dogs who should have been trained otherwise but were not. Let me say to those dog folks right now: it ain't cute. I don't like having to wear synthetic clothing (aka, my “crazy dog lady clothes”) every day because you don't and/or won't properly, positively train your dog to stop jumping on me, a stranger.

But, thanks to those remiss dog people, I have now gathered a requirement – I will teach my dog that jumping on humans is unacceptable behavior. But how?

Well, to start, I didn't teach my dog to "stop jumping;" rather, I taught her to sit, stay and then "say hello nicely."

In reality it was even more iterative than that; I got value in very small amounts: first, the “sit” had to be solid – whether we were at home, at the dog park, along a hiking trail, on the sidewalk in a busy shopping area, etc. Any place that is distracting/fun for a dog is always a good place to practice or “proof” the good behavior(s) you want.

Once the sit was firmly established, we moved on to our “stay” – first, inside the house. Initially, my wriggly dog could only do it for a second or two; she could only deliver a very little bit of value (I took it, happily).

To be continued...

Wednesday, May 18, 2011

Agile-ity Training: Dog Training as an Iterative Process? (Introduction)

Most of the development environments I've been around or exposed to have been more traditional than Agile and have therefore followed more traditional methods like Waterfall. There are other places to learn more about the history and theories of waterfall and other methodologies. I'm here to relate my own experience with these methods. (One day, I may tell you the story about the time I was involved in a project that had no method whatsoever -- a project manager worth her salt would call this "crazy-making").

For now, I can tell you that, in real life, developing software under traditional models mean that you plan, plan, plan/document, document, document: you write statements of work, marketing requirements, design documents, functional specifications, product specifications, database design requirements (if applicable); and if you're planning to actually test your product, then you'll need a test plan and a set of use cases at a very minimum. These are just the basics -- your company will likely have its own further internal documentation that it requires. In any case, it's all very linear. Technically, it's supposed to be sequential; in my experience, however, a good percentage of the planning and documenting happens concurrently.

So you plan, plan, plan/document, document, document and develop and test and expect - and hope - that it all goes accordingly and that the product you end up with is exactly what the marketing, engineering, quality assurance, management and client teams all envisioned it to be. Or not. Usually, realistically, not. The end product is typically some generally acceptable estimation of all that planning and documenting: you take what you got and then move on.

At the end of the day, what has happened is that the hundreds of man-hours put in by many people across multiple teams that went into all that planning is now moot -- and you've wasted, amongst other things, the most precious resource along the way: time. (Of course, finance team members will look their P&Ls and tell you that what they lost was money or possibly "opportunity costs," etc.; since I'm a project manager and not a money person, I'm going to say it's time).

And this is where Agile methodologies come in and ask,

Rather than pouring your heart and soul into a plan that you know will change, why not jump in, do the work and assess and change along the way? Wouldn't an "inspect and adapt" approach make more sense?

Yes; yes it would.

The fact of the matter is, "a software project is too complex and chaotic to be managed via defined processes;"* yet software development has been and continues to be done in this way: we keep trying to hammer a square peg into a round hole.

In the recently-released Elements of Scrum, authors Sims and Johnson explain that, in agile development, one doesn't complete a particular step before moving onto the next:

"an agile team [..] does a little bit of requirements gathering, a little bit of design, coding and testing, and delivers a little bit of value to the customer. Then the team does it all over again..."

When compared to the traditional way of doing things I've described above, Agile, too, sounds like crazy-making. For software development, Agile represents not just a paradigm shift, but a fundamental incommensurability of Kuhnian proportion.

Okay, so: traditional methods are planning-intensive and agile methods are not. You with me so far? Good. But where does the dog training fit in, you ask? In much the same way, traditional (aversive) dog training is about planning, too: you set a dog up to “misbehave” and then you punish her, hoping that, after a few times, she'll stop doing the thing you've set her up to do. Traditional training methods may or may not work – we could argue the point all day, no doubt. But the old way of teaching your dog is in stark contrast to positive-reinforcement training, which is much more an iterative process: when it comes to dogs, you gotta "inspect and adapt" as you go along.

In the coming days, I'll discuss just how Agile methodologies line up with my real-life experience with positive dog training; both methods have much more in common than you'd think.

* Sims, Chris and Hillary Louise Johnson. The Elements of Scrum. Foster City: Dymaxicon, 2011.  p. 68.

Saturday, May 14, 2011

Cognitive Dissonance: A Start

In the last few months, I've found it challenging remembering normal, once- everyday words, terms and phrases. The example I'll give here is "cognitive dissonance," since, ironically, I experienced cognitive dissonance about forgetting "cognitive dissonance." 

I vaguely recall now that I'd originally learned about cognitive dissonance via Sterne's Tristram Shandy -- something about a hot chestnut in someone's trousers.

That I mention any of this at all should indicate to you that I have some free time on my hands, which is true.

One of the biggest downsides of unemployment (and there are many) is that a good portion of the knowledge you've accrued begins to dissipate: it seems to drift off into the vapor. Whether or not you'll gain any of it back is a matter of pure speculation and, sometimes, fear.

I've recently realized another problem - one that's apparently inherent in being unemployed and having a dog.  Spending a great deal of time hiking with and training a dog is a positive and rewarding thing to do; as the saying goes, a tired dog is a good dog. But there is a point at which using one- or two-word commands for a good portion of your day begins to inform the way you communicate with fellow human beings. A matter-of-fact and slightly firm, "Drop it" when a dog has a dead mole in her mouth is perfectly appropriate, whereas using that same tone to say, greet someone you like? Not so much. Or, though telling a dog "left, now" when a bike is coming down the hiking trail is okay (and preferable for the health and safety of all), demanding that someone "move, now" is most certainly not okay. Nor am I proposing that it should be:  we humans need a more robust way than sternly uttering a word or two to convey our ideas, thoughts, emotions, experiences, etc. -- and a complete sentence is still the best way I know of doing so.

So, in order to stave off further adventures into cognitive dissonance and just plain old-fashioned memory loss, I will post here occasionally about various topics, from Scrum to dog training, with a bit of literature and other miscellany peppered in (i.e., I've been thinking a lot lately about dog training as an iterative process..). Stay tuned.

*Please note that all dogs mentioned in this post were duly rewarded with yummy treats for their "drop its" and "lefts."