Managing Product Development

I don’t have much use for Gantt charts; if you’ve determined the tasks in enough detail and far enough out to really see the critical path, you’ll be wrong in 24-48 hours. If you don’t put in that much detail, it’s a pretty picture, but not enough information to manage the project. (Of course, Gantt charts are used by people other than the project manager and the project team–but mostly for nefarious purposes

Tate Stuntz in The demise of the Gantt Chart in Agile Software Projects has a great article about why Gantts are not useful in Agile projects.

Aside: I’m happy to report there are no Gantt charts in Manage It! Your Guide to Modern, Pragmatic Project Management. That’s because there are other charts that provide much more detail, with more accuracy.

Labels: Manage It, project management

I taught my Pragmatic Project Management workshop in Israel last week. I was talking about defect charts and what they mean and how I use them. (No, I don’t include priority or severity data on defect charts; just # opened and closed by week and # remaining open each week.

One of the participants explained that he also tracks # Fixed Private Defects. What are those? Fixed defects in a developer’s sandbox, not checked into the mainline. Why are they not checked into the mainline? Because the organization does staged integration of several highly complex sub-projects, each of which has interdependencies with the other. And the build takes over a day.

This participant’s defect data is not about defects. This data is about the cost of the build and possibly the product’s architecture. When you can’t build the whole product every day (this organization builds a couple of times a week), you create a bottleneck of fixes waiting to be integrated into the build. You slow down development–dramatically at the end of a project, badly enough during the project–to keep the build going.

Let’s run a few numbers and see what it costs them to continue staged integration. Let’s assume it costs just one person-day to create a fix. (That’s optimistic, but not unrealistic.) Now, assume that for three months of a project, they have a weekly average of 50 “private-fixes” waiting to be integrated. (I’m assuming the 50 here, I have no data. But I think it’s not far off reality.)

To keep staged integration going, they spend 50 person-days every week for 12 weeks. (Remember, this is a large project, really a program.) That’s 600 person-days. I wonder if they could spend 600 person-days and fix the build so that they could build every day, without the need for staged integration. I don’t know, but I suspect they could.

Watch for what your data is telling you. You might think you’re measuring one thing, but you’re really measuring something else. In this case, the defect data is not about defects; it’s about the cost of an inadequate build system. What else are your defects telling you about your system?

Labels: measurement, project management

While teaching a management class recently, one participant came up to me at a break, and said, “Why are you teaching us project management with this portfolio stuff? This is supposed to be a management workshop.”

Portfolio management, determining which projects to fund and when, is management work. The best managers actively manage the portfolio, saying yes, no, and when to projects.

When project managers try to do portfolio management, many of them feel torn when they try to balance when to start each project. They can see the reasons for each project, and may not have enough information to be able to actually determine the strategy behind what the portfolio should be.

If you’re a project manager, it’s possible you have to define the portfolio of projects, just to keep your sanity. (That’s why there’s a chapter about portfolio management in Manage It!) But it’s not project management. Your managers need to make those strategic decisions about what to do and when.

Labels: Manage It, portfolio management, project management

Drum roll please…

Manage It! Your Guide to Modern Pragmatic Project Management is available. (I don’t know when it will be available from Amazon. Soon, I suspect.)

See the press release. I’m sooo excited.

Labels: Manage It, project management

In his recent IEEE Software column, “Ship Effortlessly” J.B. Rainsberger has a gem:

I start each project with two rules: all source files must be in a version control repository, and the build must be fully automated at all times.

Does your project follow these rules? If not, what would you have to do?

It’s worth the time to invest to make sure you know which sources are which. And if you automate the build and it still takes “too long,” you can measure what’s too long and you can determine which actions to take.

Labels: build, project management

There are several questioning comments on my post Testing is Not a Service: What do I mean by testing and how do I reconcile my statement with the context-driven school of testing?

Let me clarify what I mean by service first. The way the participants were discussing testing as a service, they meant a common service to the organization, not the project. In the same way that accounting is a service to the organization, or the HR is a service to the organization, their organizations thought that testing was something that could be applied to projects (frequently long after development “finished”), in the same way that other organizational services could be applied to the organization.

But if you think of testing as a service, it’s applied to a project, not an organization. In a waterfall lifecycle, where the bulk of testing occurs at the end, it’s barely possible to have effective testing after development. It costs more in time, risk, and money. The testers take much more time to find problems because they’re not integrated into the project. It’s likely the testers will not find the problems the customers will. The cost to fix a defect is much higher. But the kinds of testing these people were talking about, “Spend a couple of weeks testing this app,” or my favorite, “Go over it lightly” is not effective for the product or the people. Those aren’t services to the project; they are a service to the organization–an ineffective service to the organization.

To me, testing is a part of development. When I talk about development, I mean code and test and documentation development, because I mean product development. Whatever it takes for the whole product is part of development. In that sense, testing is a service to the project, but definitely not a service to the organization. Product development is the service to the organization. Cost effective, reduced-risk product development requires integrated testing.

So how do I reconcile my view of testing (a component of product development) with the context-driven school of testing? Look at the The Seven Basic Principles of the Context-Driven School. My statements are congruent. Especially see: Testing groups exist to provide testing-related services. They do not run the development project; they serve the project. (They don’t serve the organization; they serve the project.

Product development is the goal, not code development or test development. Effective product development requires an integrated team, who all provide services to the project, not the organization.

Labels: organization, product development, project management

I taught a one-day workshop at StarEast yesterday with Esther. I was astonished at the number of test managers who think testing is a service.

Effective testing is not a service. Effective testing is an integral part of development. When people–especially senior management–consider testing a service, there are inevitable consequences:

• Testers multitask between several projects, learning none of them in detail and only cursorily testing any of them. It’s hard to see the value in that kind of testing.
• Few managers make the decision about what project is most important, so ordering projects by value or risk doesn’t happen until the project is in test.
• Testers don’t work with developers, so defect reports look more like blaming the developers rather than feedback to the developers.
• Because testing is a service, project managers and developers tend to throw the product over the wall to test. Instead of collaboration, the project is in an us vs. them dynamic. Too few developers make the extra effort to find all their issues before the testers do. Why should they? There’s nothing in it for them.

This perception of testing as a service is a misunderstanding of the dynamics of software development.

When you contrast testing as a part of the development team, developers are much more likely to form partnerships with testers, to clean up their code as much as possible, and to exhibit professional pride in their work. They take defect reports as feedback.

If you’re a project manager don’t treat testing as a service. Make it an integral part of development.

Labels: project management, testing

I am happy to report that Manage It! is at the printer, both the book and the cover. We’re looking sometime in June as a ship date. Just thought you’d want to know

Labels: Manage It, project management

I taught a workshop about transitioning to Agile earlier this week. One of the things that’s difficult for many project managers to recognize is that milestones must be deliverables–otherwise, it’s too hard to know when something is done.

One of the participants had a slightly puzzled look on his face when I said that, so I’m not now thinking that another way to think about milestones is to call them handoffs. If everyone has the idea that their milestone is really a handoff to someone else in the project, you’re more likely to get to “done” for a milestone.

Updated later Friday, changed a “not” to a “now.” Thanks Jason, for letting me know I made not enough sense

Labels: project management