I keep getting a trickle of traffic from this post I made on an InfoQ forum back in July, so I really ought to write more on the topic (I finally did). But for now, here’s the comment that continues to spark interest.
Maybe outsiders see the lack of OUTWARD-FACING metrics, that can be compared across projects or even industry-wide. Agile thought leaders seem metrics-averse, maybe out of reaction to the way metrics have been used (and abused) in the past. As I see it, the basic four, productivity (X/effort), velocity (X/time), quality (defect/X), and value (benefit/X) still apply, and within a project, agile teams track and respond to them, in their own effective ways (measured velocity, continuous integration and automated tests, planning game). But when you need to compare projects, you need a more portable X, or what I call “an ounce of software.”
I used to do project set-up for a contracting shop that used agile methods. We needed a decent estimate before we even got the chance to establish a velocity. That estimate needed to be clearly traceable to the initial requirements, to help the client think “scope-to-budget” from the start. The estimate also needed to be tied to actual results on other projects, so it couldn’t be pressured down. Based on these requirements, I introduced Function Points. Usually dismissed with a sniff by agilists, they did just what we needed, and didn’t interfere with people and interactions at all. They also helped our initial story development by revealing gaps and implied stories
You can read the complete thread, “Agile Measurement – A Missing Practice” on InfoQ.
I’m a recovering perfectionist, and it’s not by choice.
I started out a great student, became a pretty good scientist, and was then a good software developer.
Now I’m a software management consultant and aspiring bioinformatician. I don’t have to network much (and I’m a mediocre networker on my good days) to meet people who have better training and more relevant experience than me. On paper, I don’t stand a chance, and sometimes that really gets me down.
Then I remember two things.
First, prospective clients aren’t choosing between me and perfection. They’re choosing between resources they already have, me, and whoever else they know about.
Second, I don’t have to be perfect, or even the best option, in order to be useful. What’s more, I’m more confident of my usefulness to clients than ever, because now no one else is placing me. If I’m not sure I can be useful, I don’t write a proposal. So far, I’ve always been useful. Every time.
If any clients are reading this, please tell me otherwise. But if I did have a client who found me useless, I doubt s/he is reading my blog.
Hereâ€™s what IT is.
The parts of IT. Software-Intensive Businesses have differentiating apps.
Iâ€™ll explain later, after commenting on why I posted this to begin with.
In his book The Big Switch, Michael Carr argues that within 10-20 years, IT will become completely commoditized, like electricity. In his review of Carr’s book, titled Big Switch, little experience, James Carlin, columnist for the Wisconsin Technology Network, says,
If you are not using IT strategically, then maybe you should step down as a CEO because you are still living in a 1950s framework of corporate strategy. If your CIO or CTO are not focused on harnessing new capabilities to expand and create new markets using information technology networks and instead, are just looking at how he or she can reduce IT budgets to get their yearly bonus, it is time to replace them.
Depending on how you define Information Technology, they’re both right. Are switches, routers, servers, and storage arrays IT? Certainly! Is the proprietary, custom software that runs the Chicago Mercantile Exchange IT? Sure it is. (Carlini used the CME software in a discussion with Carr).
The term â€œInformation Technologyâ€ is too broad. I suggest that we make Mr. Carlini and Mr. Carr both happy (or angry) by dividing IT into two parts, that which can be commoditized and that which canâ€™t.
All businesses have the former. They need an office network with file and print, desktops with the typical productivity applications, connectivity to the Internet, and email. Some businesses stop there. Their competitive advantage has nothing to do with hardware, software, or any of that. For them, Carr is probably right.
But Carr is definitely not right for what I call Software-Intensive Business. As one of my former bosses would say, theyâ€™re â€œup to somethingâ€ with their Information Technology.
In my own series of WTN articles, starting with That Sinking Software Feeling, I hope to help the executives of Software-Intensive Businesses (SIBs), especially those with no software management experience, provide effective guidance to those programmers theyâ€™ve hired.
The next article in the series will be called something like â€œSoftware is Different.â€ It will explain the diagram at the top of this post.
Hooray! I’m published on the Wisconsin Technology Network (WTN!) Read That Sinking Software Feeling.
They didn’t publish the picture of the leaky boat with the auger sharks, so here it is:
This is the first of a planned series of six articles about software for non-software executives.
Biotechnology, pharma, and the like are among the last adopters of the concept of project management as a discipline, according to UC-Irvine, which is launching a Certificate in “Project Management for Life Sciences.”
It’s going to be a challenge. Says author Kathleen Ryan O’Connor,
When you are working on an invasive medical device like a heart valve, you’ve got chemists involved, you have fluid dynamicists, mechanical engineers, you’ll have people in material science who spend their life worrying about and thinking about how does the human body react to the implantation of these devices, and it varies widely. So you have scientists, you have doctors, you even often have DVMs, doctors of veterinary medicine creating animal models. For many normal projects, I’m a pretty good electrical engineer and I can program, so I can run a program that has electrical software and mechanical and that’s OK–I can understand enough of it to know what is going on. But when you are running a project with eight or 10 or more specific scientific applications, unless you have time to go to school for the rest of your life and get 12 PhDs, there is no way you are going to understand it all.
Read the full article, Common Cause, at Projects@Work (requires a free subscription, but they don’t bury you in email if you do subscribe).