Software Construction is Fast and Easy

November 30, 2010

Do you consider design and development to be different activities? If your thought process is along the lines of, “Our design is complete, now it’s time to start construction!” – with construction meaning programming – you’re being trapped by the construction metaphor. Here’s why.

Giving Thanks for Scrum

November 26, 2010

The Leader’s Guide to Radical Management by Stephen Denning, is an excellent, well-written book that I found particularly interesting because Stephen talked about his objective being one to discover workplaces “… where work is highly productive, new ideas are embraced, and jobs are deeply satisfying.” Stephen admitted surprise when he noticed that an unusually high proportion of these experiences came from software organizations.

As Stephen looked deeper, he “…discovered a way of managing that was much more productive than traditional management and where the people doing the work were having serious fun.” His results were documented in his book.

And what is the secret? In a word: Scrum.

A Manager’s-Eye View of TDD

November 23, 2010

Although we haven’t tried Test-Driven Development (TDD) at my company yet, I expect that sooner or later, one of our teams will want to. This post is about head-checking my current understanding of TDD with you, and asking those of you experienced with TDD some questions along the way.

Just to be clear: My goal is not to understand Test-Driven Development so that I can mandate it. I want to be prepared so that I can have intelligent conversations with my staff about it as well as have reasonable expectations about what it will take to adopt it.

An Agile Story: Progress versus Success

November 19, 2010

Mitch Lacey has an interesting presentation from Tech-Ed Europe, Working Software is Not Enough! that is long (about 60 minutes), but well-worth your time.

One of the twelve Agile principles is that working software is the primary measure of progress, but Mitch asserts that he and his team were wrong in believing this. After viewing the presentation and listening to Mitch, my take is slightly different.

The Benefits of Pair Programming

November 16, 2010

In my last post, Results through Pair Programming, I took a quick look at what pair programming is, and noted that there are two flavors:
  1. Collaboration with driver/navigator roles, splitting responsibility for the tactical coding and strategic aspects.
  2. Collaboration by sharing and dealing with the tactical coding and the strategic issues together.
Purposeful collaboration is the common component in both cases; pair programming is not about someone looking over your shoulder and making comments like, “Oh, you missed a semi-colon!” The compiler can do that job, and quite frankly, that would drive me nuts.

Results through Pair Programming

November 12, 2010

When you hear the term Pair Programming, what thoughts come to mind?

Let’s talk about the elephant in the room: As a manager, does pair programming conjure up thoughts of paying two people to do the job of one?

Why Processes Ultimately Fail

November 9, 2010

“Just follow our ABC process, we guarantee success!”

How many times have we heard that one? In a world where there is relentless pressure to deliver, the hope of a guarantee is attractive. And to be fair, the various software development methodologies out there certainly aren’t snake oil; they have every intent of helping organizations to be successful. Yet things still go wrong.

Do You Value Innovative Risk-Takers?

November 5, 2010

“Pearls don’t lie on the seashore. If you want one, you must dive for it.” – Old Chinese Proverb

Once upon a time, I worked for a company whose message to us employees was, “We value risk-takers.” It was clear from this oft-repeated message that our senior management team understood that achieving greater growth meant that playing it safe – always seeking to avoid failure – equates to missing opportunities.

I was a couple of years out of college at the time, and it was exciting to be working for a profitable company that wanted to continue its successful streak. I was intrigued to see how this valuing of risk-takers would play out.

Catalysts, Inhibitors, and High-Performing Teams

November 2, 2010

As a manager in an Agile development shop, I find that an important consideration when staffing our self-organizing teams is to answer the question, “Who is the catalyst on this team?”