As Jerry Ponders

Outsourcing your own job?

Jerry Deville — Wed, 27 Jun 2007 16:27:00 GMT

Did you hear the one about the programmer who outsourced his own job? http://www.wired.com/wired/archive/12.07/view.html?pg=2

Hmm -- perhaps I shouldn't ponder about this too much on a blog that my boss reads ;-)

Never underestimate the value of beer

Jerry Deville — Wed, 27 Jun 2007 15:53:00 GMT

During my seminars I often cite a light-hearted principle of never underestimating the value of beer. Of course, some of the attendees think drinking beer while writing code would be a wonderful practice. But the real principle is to get to know people as people.

It is somewhat amusing when you consider it. The stereotypical software person is the introverted geek. But software development is driven by people and so it can be thought of as a social event. Once you get to know the players as real people, you’ll be surprised how much you can accomplish.

So take the time to go out with your coworkers, your peers, and even that old grinch. You don’t like beer – that’s sad, but ok. Just go for lunch, have a latte or cup of tea, whatever. It is amazing what happens when you share food together. The inevitable conflicts may not disappear, but they will get resolved much quicker.

Perhaps, I ponder, that’s why breaking bread together is part of almost every major religion. But then again, perhaps I ponder too much.

Speaker at SD Conference

Jerry Deville — Fri, 15 Jun 2007 14:36:00 GMT

I will be speaking at the SD Best Practices 2007 conference in Boston in September. My presentation Applying Lean Principles to Plan-Driven Software Projects will introduce applying lean thinking when circumstances require using a plan-driven approach.

Book Review: The Myths of Innovation

Jerry Deville — Tue, 05 Jun 2007 19:04:00 GMT

I just finished reading Scott Berkun's new book, The Myths of Innovation (O'Rielly 2007).

While taking on the role of myth-buster; Scott provides insights into how innovations really happen and more important how they gain adoption. Like his first book The Art of Project Management (O'Reilly, 2005), Scott witty style makes the book easy and enjoyable to read. There's much in the book that makes you rethink and question the common views of innovation. While each chapter presents good insights, I especially liked chapter 9 "Problems and Solutions." Scott does a great job pointing that the real key is correctly defining and framing the problem.

Some relevant quotes:

Problem solving is not nearly as important as problem finding.

Problem finding--problem solving's shy, freckled, but confident cousin--is the craft of defining challenges so they are easier to solve.

Discovering problems actually requires just as much creativity as discovering solutions. There are many ways to look at any problem, and realizing a problem is often the first step toward a creative solution.

I guess this brings us back to the Problem Space vs. Solution Space discussion Earl Beede started on Construx's Requirements Forum.

I highly recommend this book. It's a short easy to read book; one that will keep you enterained during a cross-courntry flight.

What is a traditional Manager?

Jerry Deville — Wed, 23 May 2007 15:28:00 GMT

I've been studying a lot about agile management, and even completed the Certified Scrum Master training. But still I ponder about how they define a traditional manager. Am I traditional?

On one hand, I started managing software teams over 25 years ago. I graduated from the US Air Force Academy and completed too many Professional Military Education programs. I got my Masters in Management over 20 years ago. I've lead big teams and small teams. Sounds like I should fit into the traditional camp.

On the other hand, when agile writers talk about traditional managers, they often equate it to the pointy-haired bosses who dictate every action. They talk about total reliance on command and control authority, process for process sake, and rigid conformance to the plan. Do you picture Michael from "The Office?" Is that really traditional? If so, I am definitely not traditional.

Perhaps we're looking at it the wrong way. It's not a matter of traditional vs. agile management. It's really all about good and bad management. I have never worked for a bad manager - the one agile calls traditional. I know they exist, but I've been lucky.

I've had some good role models. They taught me years ago, long before the agile movement began, that good management is all about setting directions, getting the resources, removing barriers, and then getting out of the way.

This was drilled into me from very early. I still remember quotes I had to memorize when I was a smack (1^st year) at the Air Force Academy in 1976.

"Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." General George Patton

"A leader is best when people barely know he exists, when his work is done, his aim fulfilled, they will say: we did it ourselves." Sun Tzu

To me these capture the essence of good management. But perhaps, I ponder too much. What do you think?