Posted on 7 Comments

Does pair programming work?

The fact this question continues to come up time and again after all these years prompted me to wonder why the matter hasn’t been settled by now. Thousands of people have tried their hand at pairing in a wide range of circumstances. Some swear by the practice and feel as if something is missing when they must work solo. Others are convinced pairing is pure waste and cannot possibly yield good results. Both opinions are informed by real-world experience. What specific differences in these situations resulted in such radically different outcomes?

Continue reading Does pair programming work?

Posted on

We simple folk

I’m working as one of a team of coaches for a large client where we are introducing a basic “agile” development model. The external coaches and internal (client) mentors are having an off-site event soon to improve our cohesiveness as a team.

One of the things we’re doing to prepare for the event is to take an online self-assessment known as StrengthsFinder, offered by Gallup and based on the book, Strengths Finder 2.0 by Tom Rath. Unfortunately, my top five strengths are:

  1. Strategic
  2. Learner
  3. Connectedness
  4. Responsibility
  5. Deliberative

I say “unfortunately” because I can’t just let the assessment run its course. I feel compelled to take it apart, no doubt as a direct consequence of these particular “strengths.” Continue reading We simple folk

Posted on

Short-term planning: A continuum of effective practice

There’s been an ongoing discussion in IT circles about estimation. The discussion dates back as far as I can remember in my career. As far as I know, it began much earlier than that; possibly around the time people began to apply software to serious matters, which would have been a few minutes after the first digital computer was powered up.

People have focused on estimation for such a long time that I sometimes wonder if they have lost sight of the purpose of software. The practical value of software is not realized through an estimate. An estimate is not a product. Customers don’t buy estimates. Even when a client pays a consultant to provide an estimate for a project, the estimate itself is not the thing that ultimately interests the client. It is only a step toward making a decision about whether and how to go about a proposed initiative. An estimate is a means to an end, not an end in itself. Continue reading Short-term planning: A continuum of effective practice

Posted on

An old metric revisited: Comparing estimates with actuals

Back in the Old Days, project managers seemed to be obsessed with comparing time-based task estimates with the actual completion times of those tasks. When estimated and actual times didn’t align, we were advised to get better at estimating. The goal wasn’t really to learn to create perfect estimates. The goal was to achieve some level of predictability in an inherently unpredictable process for purposes of short-term planning.

Nowadays we know that the fine-grained estimates we might use to inform our short-term planning in the course of a project are not “the product” for which our customer is paying, and therefore are a form of “waste.” We’ve looked for (and found) alternatives to time-based estimation that can provide the information we need to plan our work without the overhead of preparing time-based estimates for individual tasks.

At two different clients this year, I’ve seen people comparing “estimates” (actually, relative story sizes) with the actual completion times of user stories, but not for the purpose of short-term planning. Continue reading An old metric revisited: Comparing estimates with actuals

Posted on 6 Comments

Testing as the core discipline of software delivery

Of the basic disciplines involved in software development and delivery – analysis, design, programming, testing, management, deployment, operations, architecture, etc. – programming is usually seen as the most technically demanding and complicated to learn. Many people look primarily to programming when they assess the effectiveness of their software delivery processes. Historically, the knee-jerk response to slow delivery has been to hire more programmers. After all, software is code, right? Therefore, if there’s a problem delivering software, it must have something to do with the way it’s coded.

After some 36 years in the IT industry, most of it in a hands-on software development role, I’ve come to the conclusion that the core discipline in software development is not programming, but rather testing. Even if programming is objectively more time-consuming to master than the other disciplines, it seems to me that testing is more critical to success. Continue reading Testing as the core discipline of software delivery

Posted on 7 Comments

I know how to tie my shoes

Recently there have been numerous discussions online about the difficulty of convincing people to try unfamiliar software development techniques that technical coaches and mentors consider useful. The same discussions have been taking place for many years, with no progress. Why is there no answer?

Continue reading I know how to tie my shoes

Posted on 4 Comments

The future casts its shadow across the past

I don’t know the origin of that saying. When I first heard it, it was presented as ancient Chinese wisdom. In the West we often attribute pearls of wisdom to some named or unnamed ancient Chinese philosopher. I suspect many of the attributions are not historically accurate. In any case, the saying suggests — correctly, I think — that by examining the past we can make some predictions about the future…within limits, of course.

One of the hot topics of discussion in software development circles these days is the question of how we can make useful predictions about the future for purposes of planning software delivery activities. The subject turns out to be trickier than I had, um, predicted.

Continue reading The future casts its shadow across the past

Posted on 6 Comments

Attitudes toward continuous improvement

Question: Is it a general pattern that organizations in need of improvement tend to be satisfied with the status quo, while organizations that pay attention to improvement tend to forget that they already do many things very well?

Here are sanitized descriptions of four client environments where I’ve worked in the past few years. Continue reading Attitudes toward continuous improvement