One of the ways I pass the time on my daily elliptical workout at the gym is to listen to podcasts. Sure, I can pedal faster and longer to some great tunes, but listening to business-oriented shows helps me keep up to date with what’s going on in business and technology, and even allows me to dabble in things outside my usual areas of interest.

One of the podcasts on my standard list is the HBR IdeaCast. Recently, they previewed some of the articles in the May 2016 issue of the Harvard Business Review magazine. I was particularly interested in their discussion of the article Embracing Agile by Darrell K. Rigby, Jeff Sutherland, and Hirotaka Takeuchi. This article focused on businesses that were starting to use Agile, not in their software development areas – where you usually find such a methodology – but rather in other business functions such as marketing or the executive suite.

The podcast was compelling enough for me to seek out a hard copy of the magazine to read the entire article. I was interested because I’ve been on the software development side of IT for most of my career – either as a software developer or as a leader of that function, and I’ve heard of Agile for some time. Now in the interest of full disclosure, and not wanting to come across as an ultracrepidarian*, I must state that I’ve never led (or been a part of) a real Agile team. I have, however, done a fair amount of reading and research on the topic, but I’m not a certified Agile practitioner.

In a conversation with my wife Beth I mentioned the article and some of its major points. She asked my thoughts about Agile, which I said I believed that there were times when that methodology was best, but I wondered if it was always the best solution. Later, she sent me a link to an article published on Inc.com by Alan Fridman titled The Massive Downside of Agile Software Development. Certainly each article held a different viewpoint – one showing Agile in a non-software development light and the other in the traditional software side. What intrigued me was that within a few days I was seeing articles focusing on both “sides” of the Agile argument. If you do read the Inc article, make sure that you read the comments (three at the time of this post) as the commenters, whom I assume to be Agile practitioners, or certainly Agile proponents, challenge the author on most of his points.

I’ve always had a fairly decent ability to see both sides of an argument. This, I believe, is both a blessing and a curse; blessing in that I believe it is open minded and allows for all participants to be heard, cursed in that during the evaluation of the various possibilities, I can seem to be challenged in making a decision on which “side” to support.

So, my dilemma was which methodology should I support? In wrestling with that question, I came to the conclusion: why do you have to pick one over the other? Can’t both have a place – depending on the circumstances? Well, yes, of course. The HBR article actually had a few guidelines on which conditions favored (or didn’t) the use of Agile. The article ends with several tips on destroying behaviors that impede Agile, such as getting everyone on the same page, naming only one boss for each decision, and leading with questions not orders.

All of this reminded me of a current Chevy truck commercial where three real people (not actors) are asked to cut a 2×8 piece of lumber. They are shown into a workshop where they find a power saw and a hand saw and are told to cut the board. All of them choose the power saw (duh) and the spokesperson then goes on to say that they’ve chosen the right tool for the job. I’m sure that the choice would have been different if, upon entering the workshop, the participants found that there was no electricity to operate the power saw, yet still had to cut the board.

* One who gives opinions beyond one’s area of expertise.

%d bloggers like this: