In Integrity is the Most Important Requirement in a Manager, I talked about integrity as a requirement for a manager. With the current Patriots scandal, I'm wondering what Belichick was thinking.

I don't claim to know everything about football. I enjoy watching the games. I enjoy seeing a team come together, which is what the Patriots have done over the last few years. I am surprised that videotaping the other coaches is against NFL policy. (Oh, come on, when cameras can be hidden in glasses--which will happen in a few years--how is the NFL going to catch people taping the other team?) But it is against NFL policy, at least for now.

I asked Mark, who Knows All Things Football, at least in our house, about the taping. He said, "Everyone's doing it." The idealistic part of me says, "Maybe." The cynical part of me says, "Figures."

But even if everyone else is doing it, it's not right. Not according to the current rules.

I'm trying to remember a time when I thought that going against the rules in a cheating way was appropriate. Then I remembered something I do all the time. I encourage my clients and colleagues to do work in an iterative/incremental way even on a supposed serial lifecycle. I tell people they don't have to explain everything about their work to their management--that all they have to do is deliver results. (Which they can't do in a serial lifecycle, but can in an iterative/incremental lifecycle.)

I'd like to think I'm doing something different from Belichick. I'm not telling people to spy on another group without their knowledge, and use the new-found information against them. I am telling people to "lie" by omission. (I'd never thought that was lying until now.)

Up until today, I thought that the ends--a successful project--justified the means. Now I'm not so sure. Part of me says that the project team are the experts and they should be in charge of their work process. That same part is sure the management team who insists on a serial lifecycle either doesn't understand what they want, or doesn't realize that artifacts are no guarantee of a working product. But the other part of me is wondering if I shouldn't insist that project teams--who work in a way their managers don't understand and deliberately keep that information from management--should tell their management what they're doing.

I'm curious what you think. Are there times when the project ends justify the means? Where do you draw the line?

I had the pleasure of speaking with two different colleagues today, both with the same dilemma. They are near the end of their projects. They don't quite have enough time for one round of final testing--but if they're lucky and the stars align, and they don't find too many problems, they can still (maybe) test what they need to test before the desired release date.

But no, the stars don't align. First week into testing, they find a nuisance of a defect. It only occurs once--in installation, and they can work around this with release notes--but they're under pressure to make the change. They each asked me what I would do.

After asking a few questions to make sure the problem only occurs when installing, and they can make big red stickers to explain to the customers what to do, I agreed with the PMs: don't make the change.

The risk is just too high. The reason the projects don't quite have enough time for testing is that they've encountered trouble all the way through the projects. The builds take too long. The developers didn't integrate testing as they developed. They implemented by architecture, and couldn't manage the changes in requirements, so the architecture doesn't quite fit what the customers want--but they shoehorned the features in anyway. The project team hasn't met one deadline yet.

If you're in this position with your project team, ask yourself and the team this question: What did you see or hear that leads you to believe this would work?

If the someone has data, "Oh, we fixed the build and we can tell in 10 minutes if the build is any good," maybe you can agree with the decision to make the change.

But if all you hear is gut feelings, say no. Murphy is one of your team members. Finish this project. Hold a retrospective. Work differently on the next one. But don't make that one small change. It won't be small. It probably won't work, and you won't know until the customers receive the product. The risk is too great.

Greg Wilson posted a lovely review, Managing, Reviewing, and RESTing. I particularly like this part:

Her new book is her best yet: personal without being chatty, and informative without being dry, it covers everything a technical manager needs to know about running a development project.

Thanks Greg, and I'll make sure my editor sees that quote. We worked hard to make it readable.

I just finished updating all my email newsletter (Pragmatic Manager) pages. I hadn't announced my most recent newsletter, Making Waterfall (a Serial Lifecycle) Work For You, Part 1 (Vol 4, #1). I've reorganized the pages, so go here to read all the previous articles.

The Projects@Work folks have posted another excerpt from Manage It!. See Roll With It to read a bit about rolling wave scheduling.

Several months ago, Hal Macomber sent me a brief email,

Great book cover. Do a redesign of your website.

I've started. I've updated this blog design and added more links to my blogroll. More to come (slowly).

I reported on my progress cleaning up my office previously . I hadn't let it get that bad since that round of organizing, but I did ask for help from Daughter #2 in May, to buy some bins and drawers to continue my never-ending attempts to stay organized.

The past 8 months, I've traveled about half time and finished a book. Either of those events means my surface organization goes downhill, but my office was not a disaster. (Mark disagrees with my assessment. :-) Wednesday, Daughter #2 and I attacked the part of my office I had not yet organized: my desk and a bookshelf of supplies I use frequently. (The bins and drawers for the travel and workshop material was working quite well. I'd updated and refined that over the last few months.)

I only had three bags of recycling. Once we bought some bins, I could organize the pens, stickies, and pads I use, so now everything has a place.

There is no way I could have done a BDUF to really know what I needed or how to organize. I had to evolve my organization, based on how I work. I was willing to change some of my workflow, but not all.

When you're developing a system in which people work, such as an office, or a kitchen, or--gasp--a software system, make sure you build in feedback-from-the-customer time. I had to live with my office to see what was working and what wasn't. So will your customers. The result will be worth it.

Tech Republic has the estimation chapter from Manage It!.

There's a great Manage It! review at Book Review: Manage It! Your Guide to Modern, Pragmatic Project Management.

Michael Fransen enjoyed Behind Closed Doors: Secrets of Great Management. He posted a review. The session he took at Agile 2007 was "Hiring for an Agile Team," based on Hiring the Best ....

Last week, at Agile 2007, I had a fascinating conversation about geography/directions with a colleague. I explained that I needed to visit someplace and walk or drive around until I really understood where everything was. He said, "Oh, you think in postcards."

I can read a map, and write down directions. It all makes sense until I'm faced with reality. Sometimes, I can't quite see what he directions are telling me. (I think it's because of the greater Boston area. On one one-mile stretch of highway, you can be going South on 128, South on 95, North on 93. In reality, you're going southeast to east to east-northeast. There are no real grids in the Boston area.)

But realizing that I think in postcards (or at least, not directions), helps me understand how to approach other people when I want to give directions or explanations. If I'm talking to a compass direction person, a sequence might be the right way to start. If I'm talking to a postcard person, giving them the big picture might be the right way to start.

I was discussing this with Mark, who is a compass directions person. We compared how we learned to get around in Boston. He says, "Always keep the ocean on the east." I say, "Always keep the ocean on the right." He says he's able to manage his transitions to the west coast because the ocean is then on the west, but I always have the feeling the ocean is on the "wrong" side. (He laughed so hard, I thought he was going to have to stop driving.)

Giving directions is one small piece of life. I bet this difference is reflected in how we see how we transition from one area of the product to another (the GUI or architecture), how the code works, how to create tests, and especially how we manage the project portfolio in our organizations.

It doesn't matter that I'm a postcard person or not (although it's handy to know now). It does matter that we think differently, and understanding this difference helps me communicate better.

Some lovely reviews of Manage It! were posted when I was traveling last month, and I didn't remember to blog them. Sigh.

Wagnerblog has a great review, focused the on schedule games chapter. (That chapter was a blast to write.)

My good friend an colleague, Ken Flowers, wrote this review. Here's the sentence I like the best:

Each part gives multiple suggestions about how to be successful in most common project management situations.

There is No One Right Way to manage projects. What works for me might not work for you, so keep thinking.

Kevin says in his comment:

Business analysis is how you figure out what done means. Project management is how you figure out how to get to done.

I disagree. Business analysis is the elicitation and definition of what everyone else wants to have in the product. Project management is understanding what's driving the project, and leading the team to fit as many of those "what everyone wants in the project", with the desired quality in the time frame. Business analysts don't get to define "done." They don't have enough context. (Yes, there are some business analysts who can do this, especially if their PMs don't. I bet Kevin is one of these multi-talented folks.) The PM and the project team define "done" and how they will get there, not the BAs.

The good folks at Projects@Work have posted an excerpt from Manage It!. The excerpt is Make Your Organization Work for You. There's no facility for comments there, so do leave comments here.

Via Raven's Think you know what a project is?, there's a pointer to What is a Project? Think Again!. Garry, the author likes David Allen's definition of a project:

A project is any outcome you're committed to achieving that will take more than one action step to complete.

I don't disagree with that on a personal level. But I don't think that's enough for a project manager inside an organization. I prefer Max Wideman's version:

A novel undertaking or systematic process to create a new product or service, the delivery of which signals completion. Projects involve risk and are typically constrained by limited resources.

That leads me to my definition of a project manager:

The person whose job it is to articulate and communicate what done means and to guide the project team to done. By done, I mean a product that meets the needs of the organization developing the product and the customers who will use the product.

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.

I'm pleased that here are several nice reviews of Manage It! Your Guide to Modern, Pragmatic Project Management.

See the most recent: The Library's post.

Every two years, my good friend and colleague, Brad Goldense, gathers research about the state of product development metrics. It's that time again. Here's the information:

GGI's 2007 Biennial Product Development Metrics Survey is now available. This year's theme is "Innovation Processes, Tools, Techniques, & Metrics."

All participants will receive a complimentary 40-50 page Summary of the Survey Results at the conclusion of the study. The Summary will address each survey question, and we will provide factual observations, management analysis, and graphed answers.

The Table of Contents for the 2007 Survey is:

• Innovation Environment
• Innovation Processes
• Innovation Identity
• Innovation Tools
• Top Corporate Metrics In Industry R&D Practices

Your responses will be held 100% confidential. The survey close date is October 10, 2007. For more information please contact Brett Kratchman at GGI at 781-444-5400 x202.

Click Here to Participate in the 2007 Biennial Product Development Metrics Survey. (Note: Please only download one copy per person, as we are tracking downloads for statistical purposes)

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?

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.

My Eliminating the 90% Done Schedule Game Stickyminds column is up. Enjoy!

For those of you who remember the schedule game series from a few years ago, yes, this is one of the games. I added several more and wrote more in Manage It!.

Esther and I were teaching a Behind Closed Doors tutorial at Better Software yesterday. One of the participants was a program manager. He couldn't see the value of the standup meetings the Scrum teams used every day. "They talk to each other all the time--why do they need the standup? I can't see the value."

That's because the standup has little or no value for a program manager. The value is all for the team. The standup is where the team recommits to each other--every day. The standup is where the team can build burnup or burndown charts (with virtually no overhead). The standup provides the team, not just the Scrum Master, with early warning signs the project is stalled (e.g. if someone consistently misses deliverable dates, or if related features were mis-sized).

The standup is too granular a level for the program manager. (Especially if the program manager really is managing several interconnected projects or several releases.) I asked the program manager if he received the data he needed from the team--and he did. He wanted to save the team the less than 15 minutes a day they spent on their Scrum. I suggested he stop going to the standups altogether. Less than 15 minutes a day is a small price to pay for receiving early-early warning signs of project problems.

If you're attending standups, and you're not part of the product development team--the people developing the product-- are you receiving any information you really need? If you stopped attending, what would happen to the project? (Hint: it might go faster, because no one will be inhibited by your attendance. The team will discover problems earlier and fix them earlier.)

I work hard on my speaking skills--not just how I present myself on the platform, but also the content of what I say, and how I present that. I've almost converted to Keynote, but occasionally still use PowerPoint.

For AYE, we don't use any PowerPoint (or equivalent) at all. Here's why. If you scroll down, you'll see Dwayne's reference to Life After Death by PowerPoint by Don McMillan, an engineer turned comic. (I laughed out loud.)

At Better Software, I'm doing an hour-long thing (not quite a full workshop, but much more interactive than an hour talk) about how to be a better speaker. I was going to mention all the points Don makes, but I might just play the video.

Some of the additional points I was going to make are:

• Don't drone on about your or your company. Set the context in less than 30 seconds.
• Make eye contact with the people in your audience.
• Use a microphone.
• Understand that the people in the audience want you to succeed. You don't have to think about them as naked (icky, yucky, blech), just as people.
• Market your session all through the conference.

Do you have any pet peeves about speakers? Anything else I should make sure to include?

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.

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.

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.

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.