Specialized Skills

Whether we’re talking about revolutionary new web services, IT systems to automate internal procedures, or products to sell in boxes, there are many different sorts of things that need to be done. We need to envision the product, decide what’s required to be done, design it, build it, make sure it works, and put it into production where we can reap the benefits. Except in the smallest of circumstances, doing all of these things requires the work of multiple people. And, given that we need multiple people, and that we need a variety of skills, it’s natural that some people specialize in some thing and others specialize in different things.

But we can take that specialization too far. And if we over-specialize, then we do these different things in isolation. (Continued)

Process Metrics

My good friend Jack Ganssle commented over at EETimes (also available on the TechOnline India site, with different comments) about my recent post on process standards.  In it, Jack cautions against relying on “a strong feeling that ‘things are better.’” He recommends using measurements to bring it back to the realm of engineering.

Bob Pease, analog engineer at National Semiconductor and writer at EDN Magazine, used to say, “when something seems funny, measure the amount of funny.” That’s easier done in the engineering domain than the people domain, of course.

These two simple guidelines will help: (Continued)

Project advice from a solo circumnavigator

Tonight, we attended a lecture by Rich Wilson about the 2008-2009 Vendee Globe, a race around the globe by solo sailors in 60 foot overgrown sailing dinghies.  While many sailboat racing talks get rather monotonous, this one was fascinating.  Instead of talking just about boats and gear, Rich spoke mostly of the experience and the people involved.

He offered some advice that I think fits well with software projects:

In a race of four months, going 22 knots for a day doesn’t mean much. It’s just an opportunity to break things. It’s more important to raise the average speed from 10 knots to 11 knots.

This says something about sustainable pace, but it also says something about our tendency to measure ourselves by our peak performance according to some measure.  Let’s face it–we’re only at those peaks for brief moments.

In the normal world of human endeavors, rather than artificial contests, the measure of “best” is never a measure of a single attribute. I would say that the measurement scales for our performance are so numerous and varied that we are never “best” by all of them at once. Perhaps we are not at our peak even for brief moments.

Yet we can always strive. And even when we don’t achieve that which we desire, or that which we think we’re capable of achieving, we may still be doing our “best” under the circumstances. In fact, how could we not?

Getting your money’s worth

Everybody wants to get full value for their money.  I can pinch a penny as hard as the next guy, maybe harder.  But I’ve learned in many ways and many contexts, the very things I do to get more for my money, often result in actually getting less.  How can this happen? (Continued)

Tracking your investments

The world is slowly recovering from a major financial meltdown.  People blame the collapse on a number of different things: a bubble of inflated housing prices, relaxed requirements for qualifying for a mortgage, predatory lending practices, greed on the part of mortgage companies and investment banks….  There are certainly many places to point fingers.  Each of these places, however, was doing what seemed logical when looking at a small piece of the puzzle.

As is often the case, we must back up and take a larger systemic view to see further.  Once upon a time, people borrowed money to buy a house, paid it back over time, and ultimately the bank was able to lend that money to someone else.  With the creation of the FNMA (Fannie Mae) in 1938, the income streams of those mortgages being repaid were converted to bonds, so that they could be sold to other investors and the banks to re-lend their money more frequently.  This allowed many more people to afford houses.  In the 1970s, private banks got into the business of creating their own bonds based on debt repayment streams.

Nothing ever stands still, of course.  People continued to look for new wrinkles on these themes to allow them to expand the business, or to increase the profit on the business they had.  Some of these investment vehicles got very complicated, intended only for professional bankers who could understand and evaluate them where the mass public could not.  Or, so went the pitch at the time. (Continued)

Should it really take that long?

In my previous post, Working Hard, or Hardly Working?, I mentioned how it was possible to tell the wheat from the chaff by observing.  Alistair Cockburn rightly suggested that the manner of observing that I suggested was more appropriate for a team leader than for upper management.  Yes, he’s quite right about that.  He had in mind a Vice President who, when told that the development team had estimated something would take two weeks, asked him,

How can I tell if it really should take that long, or they’re just padding to make their life easier?

How would you answer that question? (Continued)

Working Hard, or Hardly Working?

I first heard this joke way back when, at my first real job–I was a TV repairman when I was 14.  It may generate a polite chuckle when asked between peers, but it’s serious business when the boss asks the worker.  It’s also been a topic of conversation over on the Scrumdevelopment yahoogroup, where Graeme Matthew described the difficulty of determining this using velocity.

The unknown in all of this is that if a team have a velocity of 6 how do you tell if they should have a velocity of 8 i.e. they are underperforming. It gets complex. If they have a velocity of 16 are they doing well or have they estimated at the higher scale of story points.

I agree with Graeme that this is one of the difficulties with using velocity to measure performance.  I agree with Alistair Cockburn when he says

There is NO good measure of “programmer productivity”.

earlier in the same thread.  Yet when you work with people, you generally know who’s working hard and who isn’t.  It’s an interesting conundrum, isn’t it? (Continued)