Managing Product Development

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

I have a new column up on Stickyminds.com, What’s Your Project Vision? Please do visit and leave comments.

Labels: project management, Stickyminds columns

There’s a great quote over at The pernicious thinking behind multi-tasking.

Note the admission that required multi-tasking is an implicit means to avoid conflicts around setting priorities.

I’ve been doing a bunch of multitasking talks this year (and suggesting ways for people to say no), and have written about it in Successful Project Management. (I did rename the section that originally said, “Multitasking is the root of all evil.”) When I talk about it, and tell people it makes no sense, at least part of the time they say “Ooh.” Too many people have no idea what the cost of multitasking is.

But the conflict avoidance part is because management, especially senior management is unwilling to make the hard decisions about what’s most important to do. That’s unacceptable. Managers are the only people who can make these most strategic decisions.

Multitasking guarantees your project will be late. If managers don’t make the decisions, project staff will. And it won’t be the way the managers want it.

Labels: multitasking, project management, Successful Project Management

In the PM (it’s actually called “software methodology, but I assign a project, so students can experiment with methodologies) class I teach at TGI, I ask the students to create (and then use) a project dashboard, so they have a quantitative way to see their progress (or lack thereof). The students presented their dashboards last week.

One of the teams adapted a traffic light, with red, yellow, green, and blue (for done). The student who presented the traffic light to the class, said something like this, “We added blue, to denote done. I think it’s right there.” I said, “Can’t you see it?” He said, “No, I’m color blind.”

I did about 5 minutes of online “research” and realized that about 5-7% of men can’t distinguish red from green. Some fewer can’t distinguish between blue and green (the problem my student had).

So, if you’re going to use a traffic light (which I don’t like. See Sunny Skies or Storms? for an alternative to the traffic light), make sure your viewers can see it.

Labels: dashboard, project management

Glen Alleman in What’s Wrong With This Picture says this:

dentifying, sequencing, and assigning durations to tasks is NOT the role of the Project Scheduler, it is the role of the project team, along with the Project Scheduler. The Work Package Manager, the Customer, the entire team that is accountable for delivering the business capabilities and their associated value to the customer - did I mention the Customer is accountable for the credibility of these activities as well.

I agree. That means that the team has to define and organize the schedule. And that the Customer has to understand it and be accountable for it. That’s why schedule games are so difficult for the team to deal with.

Labels: project management, schedule

Guy in his We love Scrum at GigaSpaces, says something critical:

[...]we’ve been working in the past couple of months on upgrading our automated testing framework. I’ve been assigning five of my top engineers and architects on a project with the objective to provide the development team fast feedback and monitors on quality.
Now we are able to identify specific source commits that either affect the product performance and stability. We identify those and fix them immediately. The turn-around is less than 48 hours of the cycle[...]

Scrum is the project management framework. And, Guy realized that having early feedback to developers in the form of an automated unit testing framework was critical for the success of the project management framework.

Notice that Guy assigned five of his top engieners and architects to the automated test framework. Testing in-process is hard work. If you don’t have the ability to develop and maintain an automated test framework for your project, put your best people on it, as Guy did. You won’t regret it.

Labels: automated tests, project management, Scrum

Udi has a great post, Money?! Schedule?! But I