I’ve been thinking a lot about the comments people made on the Best Practices Don’t Predict Project Success post. (Thank you for your comments.) Here’s my experience. Great people, people with sufficient functional skills and domain expertise can trump process, good or bad. Good process, process appropriate for the context, will help those people. But great people […]
© 2004 Johanna Rothman. This article was originally published in Better Software, January 2004. “We have world-class developers, but our testers are second class.” I hate hearing that. Too often, it’s true—and it’s not the testers’ fault. How did things get this way? I’ve been in the software industry for over twenty-five years. I can remember
One of the most useful decisions a project manager can make at the beginning of the project is to choose a lifecycle for the project. Here’s the way I think about lifecycles: Not every lifecycle is appropriate for every project. In fact, many lifecycles are inappropriate for many projects. If you can’t determine the requirements
Hal posted his take on creating faster cheaper projects. (See Creating Faster Cheaper Projects.) I see that I did not make my assumptions clear in my original post. Hal had three problems (at least!) with my post: Fewer people increase the length of the project. The longer the project, the more the requirements will change
Performing projects faster and cheaper seems to be the holy grail for most organizations. Here’s the secret: If you really want to perform projects faster and/or cheaper, start them earlier. When you start projects early, you can assign fewer people, so the costs start off lower. When you start the project early, you can
A Project Manager Described his Recent Agile Project in this Way: Agile practices helped us know where we were the whole way through the project, but we had a side benefit I hadn’t anticipated. The testers drove the project. In every other project I’ve managed, the testers were downtrodden, always complaining about the time they
With a little common sense and some dependable metrics, you can banish the “bug bucket” and keep the dreaded rework monster under control by creating a reasonable prediction of your project’s end. A reader recently asked me, “When planning a project phase, how do you account for the bugs that you know will be created?
Last night at my SPIN talk someone came up to me at the end of the talk. I’d discussed earned value and inch-pebbles in my talk but hadn’t specifically discussed how to avoid the dreaded “percent complete” reporting problem to management. The percent complete problem occurs when you have to report progress to management as
I’m at the 13ICSQ conference this week. One person (at least) was confused about agile processes: Conference attendee: “Agile processes are a license to hack!!!!!!!” JR: “No. Every agile team I’ve seen is highly disciplined. No hacking there. I’m sure there are people who say they’re performing agile development, and they’re just hacking, but truly
I met a test manager recently who was excited about starting a new position as a QA manager: “I really want to make a difference in the company, so I’m going to be the quality manager and set up all the processes for everyone to follow.” Uh oh. I asked if they were planning