Short-term profit or long-term prosperity

David Maister asks, in a business turndown, do you respond with cost-cutting measures, such as layoffs of junior personnel, or do you reduce the profitability at the top, redirecting the efforts of your top people to long-term growth while the junior people attend to the reduced amount of immediate work? As he says,

As always, I have to stress that this is not a moral issue but one of pragmatics.

As I read through the comments on this post, I came across one that noted this was a case of

The classic fight between short-term “success” and long-term prosperity.

Suddenly I was struck by the parallels between this dilemma faced by business owners and those faced by software developers. Read More

3 Comments

Categories: Responding to Change

Tags:

Learning from experience

It is good when we learn from our experiences–much better than when we don’t learn from them. I recently wrote about learning, or failing to learn, from observing others. A recent discussion on the scrumdevelopment yahoogroup got me thinking about another way to learn from experiences, and that’s learning from the experiences of others.

The discussion I mean started in the middle of another thread, when Clay Dreslough asked about Pair Programming.

But I have never had any success with actual Pair Programming.

So … am I missing a key component of XP? Or have other people found the same reticence with adopting Pair Programming?

Are there some valuable gains here that I’m missing? And if so, how would you recommend getting programmers to change their habits? Read More

No Comments

Categories: Individuals and Interactions Responding to Change

Tags: ,

Advice to a CIO about Agile Development

Esther Schindler quoted me in her article, Getting Clueful: 7 Things CIOs Should Know About Agile Development, on CIO.com. Unfortunately, my advice got altered a little in the editing process. She says,

Consultant George Dinwiddie from iDIA Computing suggests using a burn-down chart to track project progress.

I actually recommend a burn-up chart to track project progress, and a burn-down chart to track iteration progress.  There are specific reasons that I think a burn-up chart is superior to a burn-down for tracking over the course of a project or release. I’ve been meaning to write a long post about this, but haven’t found the time. I just wanted to correct the record, in the mean time.

The full comments of my note to Esther: Read More

No Comments

Categories: Tools and Techniques

Tags: ,

What Test-Driven Development is…

I know this has been bandied about hither and yon by lots of people. But I still see statements like the one by James Bach quoted on Matt Heusser’s blog that “the part of the testing problem they address is a small fraction of the whole.” Well, yes. Of course it is.

Maybe that’s because Test-Driven Development (TDD) isn’t a testing technique. It’s a software development technique that happens to create a safety net of unit tests.

Or, to paraphrase Captain Jack Sparrow, Read More

2 Comments

Categories: Tools and Techniques

Tags:

Agile Compensation

The subject of determining compensation for developers on Agile teams comes up from time to time on the mailing lists. I’m no HR specialist, and I don’t have any easy answers to this question. It seems certainly true that some people will have provided more value than others and should therefore be given more reward. It is also certainly true that if the reward system is geared only toward individual achievement, then teamwork will suffer. Beware the law of unintended consequences.

There’s a whole class of arguments, however, that can be discarded rather easily. Read More

6 Comments

Categories: Individuals and Interactions

Tags:

What do you know?

A while back, I was working with a young and cocky software developer. He was a smart guy, and sure of his abilities. He had seven years of Java experience, he said, and he knew how to write code.

As he was a new member of the team, I described the strategy I’d planned for a bit of code. I showed him what I’d already written, and asked him to complete the functionality.

“But I can do it another way.” And he described a different technique. Read More

2 Comments

Categories: Individuals and Interactions Responding to Change

Tags: ,

Refactoring a House

Some of you may remember that I started a house construction project. Things are moving very fast, now, and the actual construction may take less time than it took to get all the necessary permits. So far, the project’s about 100% over the time budget. And people say that software development should be more like the construction industry!

But the fact that the construction has run slower than expected is not the reason for this post. Neither is the fact that this project has been consuming a large portion of my attention, and hindering posts on this blog.

This post is about an example of refactoring found in the house construction domain. Read More

1 Comment

Categories: Responding to Change Tools and Techniques Working Software

Tags:

Combined backlog for multiple projects

Our teams sometimes have multiple projects. I am wondering what is the best way and what is the SCRUM way of handling this. My feeling is that the best way is to have a single backlog per team (even if this means that in a sprint the team is working on backlog items belonging to multiple projects). I think the purists will recommend splitting the team and having multiple backlogs.

That’s what Gilad Gruber asked on the Scrumdevelopment list. This question reminded me of a client I once had. Read More

9 Comments

Categories: Customer Collaboration

Tags: , ,

In praise of small conferences

I’m just back from XPDay Manhattan, one of those small conferences that Matt Heusser and I have praised before. This conference was a mix of prepared talks and open space. I think this is an excellent format. It provides material for those who haven’t yet identified a topic they want to discuss, and it also draws in active participation from the attendees. The participation was enthusiastic! Some people traveled a considerable distance to attend.

Coming up very shortly is the Simple Design and Testing Conference. This is an open space conference in York, PA starting Friday evening, November 30, at 5:00 PM and running through Sunday lunch, December 2. Last year’s was my first experience with the open space format. This year, Naresh Jain, the organizer, is asking people to submit a position paper with their registration application. This doesn’t have to be a big thing, and I don’t think anyone will be denied based on the content or position taken. The point of this exercise is to encourage participants to think ahead about the issues that are important to them.  It’s a small price to pay for a free conference. I hope this helps fan the flames of passion for the craft and career that you’ve chosen.

P.S. The slides from my prepared talk are available.

1 Comment

Categories: Individuals and Interactions

Tags: