Right now I’m at the Agile Coach Conference in Ann Arbor, MI.  The regular sessions will start tomorrow.  For Friday evening, we had some delightful lightning talks.

As a manager, what would you like the software developers under your management to learn? This might be knowledge of some specific technology, some software engineering skill, some other skill or knowledge, or what?

Your answer doesn’t have to apply to all of your developers. Pick something that will make a noticeable difference in your organization’s effectiveness. And please be as specific as possible.

Of course, some of the answers were general advice rather than specific things at the answerer’s organization. But where the answers were specific, I typically followed up with two more questions.

What steps are you currently taking to help developers learn this?

What steps do you think you should take, but aren’t yet, for some reason?

I’d like to hear your answers, either as comments to this blog or privately in email.

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.

Imagine it’s getting late, and you’re tired from a long day’s work. A feature you’re implementing has exceeded your estimation. It should have been done by now, but there were some unexpected complications and you’re still working on it. You just want to get it done and go home, right?

Do you

1. make it pass the test, check it in, and go home, or
2. think about how this code fits into the bigger picture, and why you ran into those unexpected complications, make this code clearly reflect this code’s role in that bigger picture (perhaps extracting a class to explicitly acknowledge a secondary responsibility), as well as making it pass the test.

Which is better for long-term prosperity of the code?

Have you faced this dilemma before in this code base? Are those unexpected complications a consequence of code that was left a little less than clear in the past?

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?

Very reasonable questions, in my opinion. And so I branched the thread to one about pair programming, stating that I did, indeed, think there were valuable gains that were being missed. But rather than start with discussing the value of the practice (which doesn’t necessarily persuade people to try it) or specific techniques of pair programming, I asked about the context in which it had been tried and the experiences that resulted. Rather than give a sales presentation, I wanted to compare experiences so that we could each learn from the other.

Surprisingly enough, this triggered a response from someone else, ranting about zealotry, one-size-fits-all practices, and people-over-process that caught me totally off-guard. It was as if the very mention of pair programming on a scrum list was forbidden territory. Certainly I had said nothing about the practice being essential. And I’ve found pair programming to be an incredibly people-centric practice that defies attempts to control exactly how the process is followed.

I hope that the discussion will return to pair programming, itself, but the issue about whether it’s permissible to discuss a topic is also an important one. As I said there, talking about experiences, whether successful, unsuccessful, or somewhere in between, can help people learn and choose. Making such discussions forbidden is as much an indication of zealotry as is an insistence that a practice must be followed. Or, perhaps, more so–for a wise person can learn from the one-sided exhortation of a zealot more readily than from the silence of a forbidden topic.

Or, as Robert Frost was recently quoted on the XP list, “Education is the ability to listen to almost anything without losing your temper or your self-confidence.”

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:

If you don’t know anything else about Agile, know that it’s largely based on using feedback to drive the work and keep things on the desired track.

The use of feedback in Agile software development is pervasive. On a project level, if you use a burn-up chart to track the progress of a project, you’ll see how the progress is converging, or not, on the goal line and can take action if necessary. That action might be to move the goal line, or to make changes in the way the software is being produced to try to speed it up. On the lowest level, using Test Driven Development allows a developer to specify the next tiny thing the software is expected to do, and then get feedback when the code meets that expectation. When a developer asks the business Customer about a feature, he gets feedback on the desired goal. When the business Customer sees the incrementally growing software, she gets feedback on how well the software is converging on the desired goal.

In every way possible, reality should be tested against what is desired. The feedback should be generated with as little delay as possible. Reducing the time between when a decision is made and when it is validated will pay off in reduced waste.

This validation comes in many different forms, at different levels, and from different viewpoints. This is much more powerful than a single validation that must be perfect to be valuable.

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,

“That’s what TDD is, you know. It’s not just arrange and act and assert and testcases. That’s what TDD needs. But what TDD is… is freedom.”

TDD is the freedom to work incrementally without keeping detailed of the whole system in my head at one time. TDD is the freedom to refactor easily to a better design without worrying that I’ve broken other code that depends on it. TDD is the freedom solve simple problems and have the simple solutions collaborate into a solution to the larger problem.

But it’s not a testing strategy.

—-

BTW, I would have left this as a comment on Matt’s blog, but Blogger doesn’t work for me anymore. Perhaps it’s the fact that I’m using Firefox, but URLs like http://www.blogger.com/captcha?type=IMAGE&captchaKey=4ur3k6eh4ksv give me a 404 error. That leaves me with the ALT text “Visual verification” for the captcha and keeps me from posting comments. Is anyone else having this problem? Queries to Blogger or Blogger’s forums go unanswered.

Later: Never mind.  It seems to be a problem with blocking cookies from www.blogger.com.

There’s a whole class of arguments, however, that can be discarded rather easily. Those are the arguments that suggest the work should be arranged in a manner that makes personnel evaluation easy. This is pure BS! Surely a company doesn’t undertake a software development project for the sake of evaluating their employees. No, the purpose of the project is to gain the business advantage of having the working software at the end of the project.

This means that any argument suggesting pair programming is bad because you don’t know which of the pair did the better work, or that collective code ownership is deficient because you can’t judge the developers by the quality of their output, is inherently flawed. First figure out how best to develop the software, then how, in that context, how to compensate the developers.

What’s a good compensation system? It may be easier and less “numerically objective” to develop one than you think. I’m always suspicious of schemes that try to reduce the reward system to a numerical algorithm without any subjective judgment. Sure, that makes it easier, but not better. I’ve always thought that the concept of paying on a share basis, like whalers were and some fishermen still are, has a certain charm. In such a system, the shares were not equal, but the survivors of the voyage shared on a percentage basis in the profit generated. It is left as an exercise to the student how such a scheme can best be adapted to your software development project.

When developing or modifying your compensation scheme, you would do well to consider David Maister’s list of criteria for a good compensation system. It provides a good starting point without some of the a priori biases I’ve seen in some other suggestions.

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.

“Yes, but they’re already talking about changing this piece. Though it’s a little more code, this way is simpler and easier to change. It keeps the knowledge of the screen layout configuration in one place.”

“OK.”

Later, when I was reviewing code that had been checked into the source code repository, I saw that he’d done it his way. He has also left the beginnings I’d asked him to complete, though it wasn’t used anywhere, as dead code. And when I brought up the fact that he’d increased the coupling in the system, since now the database had to understand the details of configuring the screen layout as well as the code, he asked, “What’s coupling?”

I think that instead of seven years’ experience, he had one year, seven times.

As I write this, I’m reminded of a day when I was a teenager. The father of a friend needed to pick up a van from across town and bring it home, but he didn’t have anyone available to drive the second vehicle. He offered me a few bucks to go with him and drive the van back. “Sure.”

I was following him back, when he suddenly took an unexpected turn. “Where is he going?” I wondered as I continued on my way.

When I pulled into the driveway, his car was already there. He came out of the house saying, over his shoulder, “Never mind; here he is.”

What an idiot I was! Why wasn’t it obvious to me that he’d been over this ground many times and knew all the roads to his own house. I knew only one. Because I knew only one, it was THE way. I had been so proud of myself for knowing THE way that I’d bypassed an opportunity to learn more.

My friend’s father never hired me for another errand, either.

I’d like to say that, now that I’m older and wiser, I don’t do things like this any more. Perhaps I do it less, but I’m well aware that sometimes I pass up learning because I think I already know THE answer.

Do you have a story where you passed up a learning opportunity because you thought you already knew the answer?

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.

Here’s a photo
of the west wall of our new house as originally constructed. Notice that there are three separate headers, one over each of the window openings and one over the door opening. The builder decided that this wouldn’t be rigid enough, and had the framer’s refactor this design to
a single microlam beam across all the windows and doors. I wasn’t in town when this was accomplished, but I would have loved to see how they did it.

In any event, it’s a classic example of refactoring. The design is improved, but the function is unchanged. And it was done in place, without deconstructing and rebuilding.

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.This client did split the team and used multiple backlogs. It was very convenient for the Product Owners. The could each concentrate on their own piece of the pie and ignore the needs of the business as a whole. Had it worked well, I might never have worked with them. What went wrong?

First, it took a lot of pre-planning by the development manager to allocate developers to the various areas of the business. It’s not easy to guess, a year in advance, how much development capacity each would need. And since the development capacity was split by assigning developers to the business line, the allocation was more-or-less static for the year (unless you wanted to re-do this guessing more than once). But each Product Owner got his or her own piece of the pie–something they could count on having and not worry about sharing. Except when it didn’t work out that way.

Given the number of developers and number of product owners, it was not practical to split the teams into integer numbers. As it was, the developers assigned to any product owner was a small team, from two to five to a team. Some of the developers had skills in short supply, so they might be assigned on a percentage basis to two or three Product Owners. While this made the teams bigger (though still a little small), it also split the attention of the developers. Estimates being estimates, and the work to satisfy a Product Owner being lumpy from time to time, the hours and percentages of developers didn’t always work out easily. It was left up to the developers to make things work. Usually they’d negotiate with the Product Owner whose work was being delayed for another, but not always. In any event, it was the developers who were making the decisions about which work had priority.

I’ve described a situation here where development management is making the large-scale priority decisions balancing between business groups, and developers are making the short-term priority decisions of what gets done first. Wouldn’t it be so much better if the business people could get together and decide business priority instead?

Gilad, I highly commend your suggestion of a single “product” backlog per team, even though it may contain stories from multiple projects. It may even be that stories for multiple projects are picked for a single sprint, just because that’s how the sprint boundaries and priorities fall out. Yes, it’s true that it’s better (more efficient) if the team concentrates on one thing at a time, but that’s a small price and the team will probably work it out OK. It’s much more important to have clear priorities based on business value. And if the business can’t decide what’s most important, they should solve that problem rather than abdicate to development.

It’s been quiet on this blog for awhile.

For one thing, the house construction mentioned so long ago has finally started moving forward after a long struggle procuring the necessary permits. (That’s an external dependency that was estimated extremely optimistically!) For another, I’ve been traveling almost non-stop helping an out-of-town client with an Agile transition. This is made even more interesting by the fact that the team is distributed, and composed of people from two formerly separate companies. Tucked in among these was the AYE Conference—extraordinarily valuable, but also completely consuming while I’m there. I learn so much and meet so many interesting people that I never want to miss a minute of the action.

It’s all a great deal of fun, but leaves no time during the day. By evening, usually a peak time for me, I’ve been pretty exhausted. I’m not generally a morning person, though I’ve gotten up early this morning to write this note. Don’t expect me to get up early every morning, though!

Enough about me. I didn’t get up to write this posting to tell you about the complications of my life. That’s just the preamble. As I was thinking about these things that I’m doing, I also thought about people caught in an “interesting” Agile transformation or other change situation that makes high demands on them. Not only are they dealing with the normal issues of the Satir Change Model but when dealing with such change(s) and also being expected to maintain a high level of productivity during the change, maybe they’re just tired.

It makes me want to read the book, Slack by Tom DeMarco…. There, now it’s ordered for my reading backlog, along with The Deadline.

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.