Posted on

The Guinness model of release planning

This model isn’t based on release planning at Guinness. It’s based on drinking Guinness.

It’s the end of a work day. You and your mates are going out for a drink. Initially, you’re thinking you’d like to have three pints of Guinness. How do you place your order?

If you’re a traditionally-minded software development project manager, you’ll order all three pints at once, in the same glass. When the bartender tells you three pints of Guinness won’t fit in a one-pint glass, you’ll pound your fist on the bar and shout until he finds a way to make them fit. After all, the reason he doesn’t want to pour three pints into the glass is that he’s either lazy or incompetent, or both. Once you let him know who’s boss in no uncertain terms, he’ll get those three pints into the glass, one way or another.

Continue reading The Guinness model of release planning

Posted on

Tool mania

Sometimes people get fixated on a particular tool to the extent that they relate every topic of discussion to that tool. You’ve probably seen the pattern before.

I was reminded of it recently during a group discussion of metrics we want to use to track progress in a client’s process improvement initiative. One person kept bringing up Mingle, a tool her group uses to create story cards and track progress on software development projects. Her contribution to every subject of discussion was all about how Mingle supports or could support this or that metric.

At times, I felt as if I had taken my car to a garage and, when I asked the mechanic what the problem was and what sort of repair he recommended, all he would talk about was his favorite wrench.
Continue reading Tool mania

Posted on

The domino effect of technical debt

Most people who do coaching work in the IT space focus on one of three areas: (a) technical practices, (b) process improvement, and (c) organizational dynamics or “human factors.” It’s not unusual for a person to have skills in both process improvement and organizational dynamics. It is rare for the same person to work at both the level of technical practices and the level of process improvement, and even more rare for that person to be engaged for both purposes at the same time.

I’ve observed a sort of disconnection between process improvement initiatives at the organizational level and improvements in technical practices at the team level. I don’t know if the reason for this is, in part, the separation, first in formal education in universities and technical schools, and later in coaching, consulting, and training services, between technical practices on the one hand and process improvement and organizational dynamics on the other. Whatever the cause or causes, the situation appears to be that improvements in technical practices and improvements in process are treated as separate and disconnected issues.

I think the two are connected. Technical debt is more than merely an annoyance for maintenance programmers who have to deal with a challenging code base. A mass of tightly-coupled code can make it very difficult, time-consuming, and expensive to implement general improvements.
Continue reading The domino effect of technical debt

Posted on

The right kind of lazy

I consider test-driven development (TDD) to be a basic software development technique. I’ve used it in a wide range of circumstances for different types of applications in different domains based on different languages and tools. I coach people in using the technique, I run workshops at conferences on it, and I offer a two-day training class on it.

My only regret is that I didn’t learn about TDD earlier in my career. All those years doing things the hard way…time lost forever. Oh, well.

I use TDD and I like it, but I never try to “convince” anyone that they should use it, or even that it works well. I never suggest that TDD is a “goal” for an individual or for a team. TDD might help you achieve some other goal, but it isn’t a goal in itself. It’s just a technique.

And, let’s face it, nearly all the code in production today, worldwide, was developed without TDD. Nearly all the code under development right now is being developed without TDD. Clearly, programmers can get along without it.
Continue reading The right kind of lazy