Helping Pigs Fly

I think an appropriate first entry in Helping Pigs Fly is some type of explanation (rationalization??) of the title. To get to that, let's explore a bit about the blog owner (me.) I've been living on the earth for a bit over 50 years now. In dog years, that's a lot, but in human years, it's not so much anymore (depending, of course, where on the earth a person lives.) I teach, coach and live agile as in agile software development. I admittedly do not have much (any??) technical development experience. I came to the IT world from the business world about 10 years ago as a business analyst. I enjoyed the business world - but I tired of some aspects of it.

So, at the invitation of a friend, I ventured over to the software side initially in staffing. What a change! The vernacular, the styles and types of work (i.e. projects) and the people were much different (refreshingly so) than the business world. However, the bust of 2001 put an end to any ambitions I had to continue in IT staffing (not to mention my rather fervent dislike of the intensity and frequent frustration of having to continuously "source for talent' - aka head hunt.)

Another friend suggested that I actually give IT work a try, and though I had no technical background I did have a strong business background that made me a reasonably strong business analyst candidate. I was hired and moved to a rather small, sleepy Midwest city from the bustle of Seattle to work in a large IT shop. Within 18 months (in March 2003), I found myself ordained as a project manager (I had functioned or perhaps malfunctioned as a business manager for several years, so I think the people reasonably thought I could manage IT projects.)

Within a few months of experiencing the nuances and peculiarities of project management, I realized that much about it was rather illogical and assuming. I learned from an older, grizzled PM about the “PM bag of tricks” that provided remedies to the project maladies that every PM seemed to constantly endure – budget overruns, schedule delays, unreliable estimates provided by supposedly expert “resources,” poor quality product, etc. For example, I learned the trick of keeping 2 schedules (similar to keeping 2 sets of books) – the one that was viewable publicly and was always on time and on budget and the “real one” that reflected the actual state of the project – often running late and over budget. When I asked how a PM might bring the public schedule and real schedule to coincide near the end of the project, I learned of the death march and schedule crashing and many other evil PM tricks.

Thankfully, I soon tired of the charade, but rather than quit as a PM (something that is done more than I realized), I began to explore for alternatives to the “traditional” approach that depended upon being able to predict a project schedule from beginning to end. It was December 2003 when I stumbled upon an article in a software development magazine that described an agile process called, mysteriously, Scrum. The more I read, the more I realized that this approach made much more sense than anything I was doing at the time. Thus began my journey to Agile Oz on the Scrum Yellow Brick Road. What a trip it has been! (More about that in future posts.)

So, Helping Pigs Fly refers to my campaign to help people in organizations do work in a better way. That doesn’t mean simply adopting Scrum and agile, but thinking about things in a most different way and understanding how little control we actually have in this self-organizing world in which we live and work. I still see many pigs who could fly if they wanted and I see pigs who fly with the grace and elegance of the eagle and the determination of the migrating goose. So, this blog will be full of all kinds of stories, vignettes, and experiences with lessons gained or not. I hope people find the content enjoyable, entertaining and even worthwhile.