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.