Thursday, September 11, 2003

Can Productivity be Measured?

Martin Fowler says that we “cannot measure productivity”. I disagree! Much of my book is about precisely how to measure productivity - as Throughput - or the rate of delivered value. This can be done by tracking client-valued functionality delivered as working code. In FDD that means Features delivered in a given time period with Throughput defined as the value of those Features.

Actually, if you read the posting careful through to the end, you will see that Fowler actually agrees with me

The Forgotten Side of Outsourcing

Bart Perkins has a very intelligently written article about some of the hazards of outsourcing in this week’s Computerworld.

Misunderstandings about outsourcing can generate bad publicity. One company’s outsourcing plans were leaked to a state senator, who was told that the company was bringing in illegal aliens under false visas to replace U.S. citizens. The senator was prepared to take the issue to the statehouse, until the company cleared up the misunderstanding.

Wednesday, September 10, 2003

yet more Business Rules

Dave Thomas highlights the problem with business rules in requirements and implementing software systems. Dave has all the questions, luckily Nicola, Mayfield and Abney have the answers. Maybe I should recommend Dave gets a copy of Streamlined Object Modeling .

Meanwhile, my own copy of Principles of the Business Rule Approach turned up today. Like a bad student, I started reading at page 109, chapter 8 that describes how to define rules and gives advice on good and bad style. Having read one chapter and flicked through the rest, I’m convinced this is a technique that, when coupled to advanced analysis and design techniques will reduce variation throughout the lifecycle and improve repeatability. The effect will be to reduce required buffers and allow projects to be delivered faster with higher quality.

Coincidentally, I’m actually working on modeling a system of reasonable size - about 6 months work for a team of 10 - this week. [It’s good for a manager to do real work from time to time]. I am using business rules for real, as part of step 2 in FDD - Build a Feature List. I’ll post more comments when I’ve read the rest of the book and developed some experience using what I learned.

Manager’s Must Work Smarter

Johanna Rothman points out to me that it is manager’s who must work smarter. How right she is! A pity I didn’t make it clearer the first time.

Tuesday, September 09, 2003

Why Good Managers Still Matter to Agile Development

Johanna Rothman writes in her blog that managers still matter even with agile development processes.

<!—StartFragment—>“But what about managers? Earlier, I said that managers matter too. Here’s why. Good people can triumph over inadequate process or inadequate management. But even the best people with the best process can’t triumph over bad management. Bad management trumps everything else. I’ve worked for bad managers, and I bet you have too, so you’ve seen the damage bad managers can cause.”

This topic is close to my heart. It has a lot to do with why I wrote the book. Bad managers kill software productivity. I recall a conversation I had with the (then) CIO of Sprint PCS - Jerry Batt. We both agreed that management in IT was universally poor on the average. I said I thought it was because enough managers hadn’t been programmers - often getting into a PM track too early in their career and as a result developers didn’t respect them. He replied that he believed the reason that managers were so poor was that too many of them were programmers. We held the same view, agreed on its effect but disagreed on its cause.

I now realize that I was talking about leadership whilst he was (as a trained senior manager) talking about management - target setting, measurement, analysis of feedback, reaction and investment. In Leading Geeks, Paul Glen states that he believes management and leadership cannot be separated with respect to knowledge work. I disagree. I wrote a book about management. He wrote one (primarily) about leadership. Both are important. Both matter. Motivating a team of developers requires both skills.