As a group, we developers have a project tracking problem: the problem is that we constantly, almost obsessively want to track our projects, and it’s made worse by the fact that it’s so easy to abuse otherwise great tools like JIRA and Bugzilla. Unfortunately, while tracking projects may feel useful and productive, for most teams it’s just busywork – and it can lead to a self-imposed exercise in needless bureaucracy that just wastes our time. But with a few ground rules, you can escape the project tracking trap and use a tracking tool effectively.

Who needs Big Brother?

About five years ago, a small company brought me in for a few months to help them do better project management. For about a year before I got there, they’d put a couple of their best developers on the problem, and they came up with an ingenious solution for tracking projects. The team built a database to keep track of all the projects they were working on, typically about a dozen and a half simultaneous projects running at any time. This tool gave them the ability to figure out exactly what tasks had been done, who did them, and how long they took. If you wanted to know what any specific programmer was working on eight weeks ago on Tuesday afternoon, their tool would be able to tell you that.

And it all worked perfectly.

Except that their projects were still late and full of bugs, and the users were losing their last shred of patience. This team had promised their users that things would get better with their fantastic new project tracking system. But even though the system was working exactly as advertised, the software still had serious problems, and everyone was unhappy.

I’ve been thinking a lot about that company lately because I’ve been doing a lot of work with JIRA. And while JIRA is a really good tool – one that can have a very positive effect on how you manage a project – it seems to really tempt a lot of good developers down the same project tracking trap that the small company fell into.

Programmers normally hate it when their time is tracked, which is obvious to anyone who makes the mistake of suggesting to a programming team that they should start filling out timecards that list out exactly what each person did that day. That happened at my first programming job after college: the boss, a newly minted MBA, told the programmers to fill out timecards that listed what project they were working on hour by hour, and there was nearly a rebellion. But for some reason, JIRA, Bugzilla, and other issue tracking systems cause programmers to step up and volunteer for exactly that treatment. It’s an odd phenomenon, and I think it has an interesting explanation.

Let’s get something straight, here: I really like JIRA a lot. It’s a great issue tracking tool, and a very good workflow tool when it’s used right. I’ve spent some time building JIRA plugins, and the plugin API is intuitive and easy to use. Sure, I’ve got a couple of nitpicks here and there (I’m not so happy with the user interface or the filters in version 3.x, although it’s definitely improved in JIRA 4). But for the most part, JIRA is one of the best issue management and workflow tools I’ve ever used.

When it’s used right.

But when you take a perfectly good tool and abuse it, you’re bound to get bad results. And that’s especially true when it comes to project tracking tools.

Tracking projects is not a useful goal

JIRA suffers from a problem that a lot of really good issue tracking tools suffer from. It’s really good at tracking things. And for a lot of developers, that causes a “when you’re holding a hammer, everything looks like a nail” problem. Actually, scratch that. It causes a “you’re holding a screwdriver, but for some reason you want to pound nails with it” problem. It’s odd when you step back from it, but it really seems to make sense at the time.

What happens is that some developers – and I admit that I’ve been guilty of this at least once or twice myself – see a tool that gathers information about what happened on a project, and this causes something to click for us. We  start tracking everything, from requirements to goals to user requests to every little ten-minute task that needs to be done. We become our own “big brother,” doing what amounts to voluntarily filling out the most detailed timecards possible.

The “big brother” style of project tracking is especially bad when the “pointy haired boss” type of managers pick up on it. Suddenly, the team is being nagged to start entering more and more granular estimates and updating dates in tickets. For a boss who’s nervous about delivering something, it seems like the right thing to do is to start nagging programmers about every little task that’s entered into the system, or chasing down anyone who’s got a task assigned without a due date.

Which is especially bad, because that’s not really what those tools are for. There’s a big difference between tracking a task or a bug so it doesn’t slip between the cracks and tracking every little thing that a the programmers do for posterity. I think it’s especially ironic that developers often volunteer for this themselves. I think it’s because we see a tool that can track something and it causes us to want to use it. “It tracks tasks? Then it should track all the tasks!”

Better living through project tracking

A while back the New York Times ran a story on people who use everyday tools like Foursquare and Twitter, blogs, spreadsheets, and datebooks to obsessively track data about themselves. I think this excerpt is telling, especially the bit at the very end (emphasis mine):

At the center of this personal laboratory is the mobile phone. During the years that personal-data systems were making their rapid technical progress, many people started entering small reports about their lives into a phone. Sharing became the term for the quick post to a social network: a status update to Facebook, a reading list on Goodreads, a location on Dopplr, Web tags to Delicious, songs toLast.fm, your breakfast menu on Twitter. “People got used to sharing,” says David Lammers-Meis, who leads the design work on the fitness-tracking products at Garmin. “The more they want to share, the more they want to have something to share.” Personal data are ideally suited to a social life of sharing. You might not always have something to say, but you always have a number to report.

I think that the sort of person who becomes a developer is especially susceptible to whatever it is that causes some people to obsessively track things about their lives. My personal theory is that this is caused by the same itch causes us to want to obsessively collect every last episode of MST3K (or whatever it is we happen to want to obsessively collect). And like that giant collection of, say, legos or video game cartridges or Start Wars figures memorabilia or dice, at some point we can’t actually play with most of it. That’s fine for collections (assuming you have it in a cool display case, and not strewn all around your home in piles so high that they cause a fire hazard). But for tracking data from projects, it’s worse than useless, because it takes effort to keep up, and it can demoralize the software team because they start to feel like they’re creating more tickets than new lines of code.

Luckily, if you follow a few ground rules, you can break the obsessive cycle and start using project tracking the way it should be used. Here’s what I’ve recommended to people in the past, and it seems to get good results:

• Figure out in advance what you want to track. Most teams use an issue tracker for bugs. A lot of teams use it to figure out what work the developers are going to do. Some use it for new feature requests. I’ve seen people try to use an issue tracker for managing requirements (although personally, I really dislike that use of it). All of that could be fine, but any of it can potentially become obsessive. Before you start your project or the next iteration, sit down with the team for a few minutes and write down what you’ll be tracking. Stick it on a Wiki page, and add a sentence or two explaining how each one of those things needs to be used. I’m always amazed at how just a little bit of planning like this keeps the way we use a tool from creeping into “big brother” territory.

• Use post-mortem reports to track your lessons learned. One reason that “big brother” style project tracking makes intuitive sense is that we want to keep track of the lessons we learned on this project in order to make the next one run better. But there’s very little you can learn from an overwhelming pile of tracking tickets. Instead, try running a project post-mortem at the end of the project. And don’t just do it for projects that ran badly. Post-mortems are really good for making sure you take a good project and turn it into great habits for the team by writing down the lessons you learned.

• Focus on trends and simple metrics, not complete history. A good project tracking system can spit out a lot of reports. So many reports, in fact, that it’s hard to make any real sense of them. That’s why I like to try to simplify the kind of data I get out of the system. I’m a big fan of simple metrics like (% of engineering effort per project phase) that let you compare projects or iterations against each other. Also, burn-down charts or other earned value metrics can be really valuable in figuring out how your current project is going.

The bottom line is that there’s a difference between project tracking and actually managing your project. If you really want to use JIRA for project management, use a tool like Greenhopper that was built for it. (I’ve been using Greenhopper lately, and I like it a lot. But if someone has a pointer to an open source tool they really like that ties a task board or agile project management into their issue tracker, I’d love to hear about it.) The most important thing to remember is that tracking your project is a means to an end, and not a goal by itself.

Jenny and I are really proud to announce that the second edition of our bestselling C# learning book, Head First C#, went to press! We worked really hard on it, and we’re very happy with how it came out.

Are you looking for the easiest way to become a great C# programmer? If want to get productive fast with C#, .NET and Visual Studio 2010, then this is the book you’re looking for. We show you how to learn C# by building over 100 different projects—including lots of games!—and solving dozens of puzzles.

Head First C# is a complete learning experience for programming with C#, the .NET Framework, and the Visual Studio IDE. Built for your brain, this book covers C# and .NET 4.0 and Visual Studio 2010, and teaches everything from inheritance to serialization.

But don’t take our word for it! Download the free Head First C# eBook [PDF], which includes the first three chapters, complete. Or have a look at this typing game project [PDF] from chapter 4 to get a preview of the kinds of projects you’ll build throughout the book.

So check out Head First C# today, and see what the buzz is all about! Available now from O’Reilly, and wherever fine books are sold.

Non-functional requirements: Planning out how well your software will work

A couple of months ago I wrote a post called Using nonfunctional requirements to build better software. It’s basically a step-by-step guide for creating an easy, practical technique to use nonfunctional requirements on a real software project, treating them in a way that’s similar to how a lot of Agile teams treat user stories, scenarios and other functional requirements: by sticking them on index cards and using them to do some lightweight planning.

Since then, I’ve gotten a lot of questions about nonfunctional requirements (or, as some people call them, non functional requirements, behavioral requirements, quality attributes, and probably half a dozen other names). Based on the questions I’ve been getting, a lot of people really seem to want a solid overview of exactly what they are:

• What are nonfunctional requirements?
• What goes into a good nonfunctional requirement?
• Is there a nonfunctional requirements checklist that I can use?
• How do I write down a nonfunctional requirement? Is there a nonfunctional requirements template I can use?

Luckily, Jenny and I addressed exactly those questions in our first book, Applied Software Project Management, and I’ve gotten feedback over the years from people who read it (and other writing I’ve done about requirements), and tell me it helped them get a handle on the concepts behind nonfunctional requirements. So I’ll do a little requirements Q&A and address those questions one by one, drawing from the book where possible. And I’ve posted an O’Reilly Community blog post called Understanding nonfunctional requirements with some additional information, which should also help get to the bottom of the issue.

Q: What are non-functional requirements?

Non-functional requirements — or behavioral requirements, or quality attributes — describe how well a system performs its function. This is fundamentally different than the typical functional requirements that most of us are used to, which describe what that system does.

Here’s a quick example. Whenever I’m talking about requirements, I like to use a “search and replace” feature in a word processor or text editor as an example, because we’re all familiar with how it works. So while a functional requirement for “search and replace” might describe how the case-sensitive matching works: “If the original text was all uppercase, then the replacement text must be inserted in all uppercase.” A nonfunctional requirement, on the other hand, might describe the performance (“it must be able to replace 1000 search terms in a 3MB document in under 250ms on one of our standard test VMs running at 50% load”).

Q: What goes into a good nonfunctional requirement?

A good nonfunctional requirement is one that makes it clear to everyone on the project — including the user (or someone who really understands what the user needs) — exactly how the software has to perform. Remember, a good requirement (functional or nonfunctional) is about understanding and addressing the needs of a user.

Here’s what Jenny and I wrote about nonfunctional requirements in our first book:

Users have implicit expectations about how well the software will work. These characteristics include how easy the software is to use, how quickly it executes, how reliable it is, and how well it behaves when unexpected conditions arise. The nonfunctional requirements define these aspects about the system. — Applied Software Project Management, p113 (O’Reilly 2005)

It’s really easy for non functional requirements to be unclear or ambiguous. The best way to make sure a nonfunctional requirement is clear and easy to use is to quantify it. So instead of saying that a task must be done quickly, write down the maximum number of seconds it must take to perform a task. The maximum size of a database on disk, the number of hours per day a system must be available, and the number of concurrent users supported are examples of requirements that the software must implement but do not change its behavior.

Q: Is there a nonfunctional requirements checklist that I can use?

We put together a nonfunctional requirements checklist that I’ve used many times on real projects. It’s based on a list of nonfunctional requirements we included in Applied Software Project Management.

Here’s one thing to keep in mind about this (or any other) non functional requirements checklist: as you’re reading it, you’ll probably find yourself thinking, “Wait a minute, all my software needs to be flexible (or efficient, or robust, etc.).” Yes, that’s true, of course. But are there specific non-functional requirements that affect your project in particular, above and beyond what you do on every project? That’s what this checklist is for, and that’s what you should be thinking about when you write down nonfunctional requirements.

• Availability: Are their constraints on the system’s availability or uptime?
• Efficiency: Are there resources the system needs to be careful about monopolizing?
• Flexibility: Will the system need to be altered after deployment?
• Portability: How easy it is to move to another platform?
• Integrity: How sensitive is the project to data security, access, and privacy?
• Robustness: Do error conditions need to be handled gracefully?
• Scalability: Will the system need to handle a wide range of configuration sizes?
• Usability: Are there specific constraints on how the users will understand, learn and use the software?

If you’re interested in using this on a real project , you can read more about it in that O’Reilly Broadcast post about non-functional requirements: I post a relevant excerpt from Applied Software Project Management that goes into more detail about each of these.

Q: How do I write down a nonfunctional requirement? Is there a nonfunctional requirements template I can use?

Yes. We put together a software requirements specification template, and I’ve helped a lot of teams adopt it for their own projects over the years. When we put together our requirements templates, we put a lot of effort into streamlining them as much as possible. So this is a sort of “bare minimum” template for writing down use cases, functional requirements, and nonfunctional requirements.

Here’s an example of how we’d specify a functional requirement:

And that gets back to the blog post I mentioned earlier, Using nonfunctional requirements to build better software. If you’re working on a team that uses an agile process to build software, there’s a good chance that you already write down a lot of your requirements on index cards. In that post, I outline a method that I’ve had a lot of success with in my own projects.

I went into a lot more detail in that post, but here’s a quick recap. First, I write the requirement itself on the front of an index card:

and on the back I’ll write a specific test to make sure the requirement is implemented:

Then I use it for planning the project to make sure it actually gets included — you can see more about it in the post. As far as documenting nonfunctional requirements goes, that’s actually a really efficient way of doing it, and I’ve seen it work well on agile projects.

I hope that answers some of your questions about using nonfunctional requirements in software projects. Obviously, I’d be thrilled if you took a look at the requirements chapter in Applied Software Project Management — Jenny and I gave a lot of practical advice about how to use requirements on a software project. And I’ve got other requirements posts on Building Better Software as well. But if they don’t answer your questions, feel free to ask (or send them to us).

Not too long ago, I was doing our Beautiful Teams talk at a brown bag lunch for a big financial company here in New York. At the end of the talk, I got a really good question:

What do you do when you’re on a team with people who don’t get along?

We don’t get to choose our teams, and while I’ve been on plenty of teams that gelled really well, I’ve definitely had to work with people who just rubbed me the wrong way or, worse, where the feeling was mutual. It’s a tough problem, but one that should be really familiar to anyone who’s been working with teams for a long time.

I have to admit that while I’ve had success working on teams with people who didn’t get along, there have definitely been a few times when I didn’t handle that situation as well as I could have. Luckily, those are the situations where we learn the most.

That’s actually one of the main reasons Jenny and I wanted to talk to Andy Lester when we were talking to contributors for Beautiful Teams. Andy runs a great website called The Working Geek, where he talks about working life for programmers, sysadmins and other geek types. And he had some really interesting things to say about how people interact with each other — especially geeky types (like me), since we seem to be especially prone to interpersonal problems. (Imagine that!)

I really liked this quote from Andy, because I think it cuts to the heart of the matter:

I was on a team once where I said, “At the very least, can we just have minimal respect for everyone here?” And I was asked quite seriously by someone else, “Well, what if not everybody on this team is worthy of respect?” And that’s baffling to me as a human, but it’s also not uncommon. And that minimal amount of respect is something that many just don’t get.

— Andy Lester, Beautiful Teams (chapter 5)

He’s right. When I look back over my own career, I find that many of my own conflicts with people on my team stemmed from a basic lack of respect. Since I was the top programmer on the team, I thought I knew better than everyone else about everything. Once someone got something wrong technically, I’d write that person off entirely because they didn’t have my respect.

Andy offers some really good personal advice for getting past those problems, both in his Beautiful Teams chapter and on his blog.

But I wanted to go a little further than that, because sometimes interpersonal problems aren’t going to be repaired. The person who asked me the question was in this situation: when I asked him about it, it sounded like some of his teammates were simply never going to get along with each other. So what do you do about that?

As it turns out, the answer I gave him comes from another part of Beautiful Teams. When Jenny and I were putting it together, we put a lot of thought into how to divide it into sections. And so many people talked explicitly about setting goals for projects that we ended up including an entire section called Goals.

So my answer to anyone who’s got insurmountable (at least, in the short run) conflicts between team members is to make sure that you’ve established what many of our contributors referred to as an “elevating goal.”

One of those contributors was Steve McConnell, who also happens to be one of my favorite authors. We asked another one of our favorite authors (and an old friend of mine), Scott Berkun, to interview him for the book, and out of that interview came this great quote:

If you’re out digging ditches, that’s not very elevating or inspiring. But if you’re digging ditches to protect your town that’s about to be attacked by an enemy, well, that’s more inspiring, even though it’s the same activity. And so the leader’s job, really, is to try to determine or frame the activity in such a way that people can understand what the value is.

— Steve McConnell, Beautiful Teams (chapter 16)

I think that really cuts to the heart of what it means to establish an elevating vision, and it should help show why that can help get past serious team problems. I have to admit that before working on this book, I hadn’t really given that much thought to establishing a vision. Yes, establishing a goal for a project is important, but I always thought about it in terms of the work that had to be done. I’d generally dismiss anything like an “elevating vision or goal” as a business-speak buzzword. A really valuable lesson for me was just how important it is to get everyone on the team on board with that one singular vision — and I mean actually understanding and embracing the vision for the project, and not just agreeing to some sort of lame mission statement.

What’s especially useful about getting everyone on the team to see the same vision is that you don’t need to be a manager or team lead to do it. All you need to do, minimally, is talk to people on your team. I’ve been brought onto projects where people on the team thought that there were serious architecture or requirements or quality problems. But once I started I talking to people, it turned out that everyone had a completely different idea of what they were building and why they were building it. I’ve found over and over again that just writing down what we’re building and who we’re building it for (using a Vision and Scope Document, for example) is enough to help the situation. It’s uncanny how often I’ve heard people say something like, “Wait, we’re building what? I thought we were doing something completely different!”

Anyone on the team can do that, and it’s a really valuable tool to help with serious teammate problems. The clearer everyone sees the real goal of the project, the easier it is to get past the disagreements and arguments and get on with the work. It’s something I’ve seen in real life many times, and it really does work: people are much more willing to settle disagreements and just get down to business if they can see that there’s a real end that they’re working towards.

When I look back at the times where I was able to successfully navigate serious team problems that were caused by people who didn’t like each other, I can see how this is exactly what I did. Even when people didn’t get along, I found that if I was able to get each person to see the bigger picture and work towards something he or she believed in, then most of the time they were able to put their problems on the back burner, at least long enough to get through, say, a meeting or a code review. And that was enough to save the project.

How well does your program do… well, whatever it does?

I’ve wanted to write a post about nonfunctional requirements for a while. But I’ve been trying to find a good angle for talking about them, because while they can be really practical and useful on a software project, it’s a little hard to get that practicality across in a useful way.

Luckily, I’ve been spending a lot of time lately talking about architecture, since Jenny and I are going to give our Beautiful Teams talk at the ITARC New York conference next week. And that’s got me thinking a lot about how architects work. I’ve been asked more than once recently about what, exactly, the term “architecture” refers to. The quick answer is the textbook definition — designing, documenting and verifying the structure, components and properties of a system. But I always want to go beyond that. Any time I come across an interesting idea (and software architecture is full of them!), I try to come up with a way that it can help a developer out today, on a project that developer is working on. In fact, I’ve got a quick technique to help you do exactly that — it’s at the end of this post. And like many great software practices, it involves index cards.

So I started thinking about some common problems that software architects run into, especially junior ones who are still building up their experience. And that leads me straight to a problem that I’ve seen over and over again. A lot of people jump into architecture and design by starting with the question, “What’s this system going to do?” We’ve got a lot of very useful tools for that (like user stories and use cases). Obviously, you can’t design a system well without understanding what it does.

But I’ve had the opportunity to work with some very talented, very experienced software architects lately, and I’ve noticed something critically different about how they approach designing a system, and it’s really pointed me to an important difference that separates a senior architect from a junior one. When one of these guys gets started on a system, they don’t just think about what it’s going to do. They also think about how it’s going to do whatever it does.

That’s a really subtle point, and it’s a very easy one to overlook. But it’s very important. Important enough, in fact, to have a name: nonfunctional requirements.

Most of us have read about nonfunctional requirements. In fact, it’s a pretty common interview question: “Name a few nonfunctional requirements.” Someone who took a class in software architecture recently might be able to rattle a few of them off (usability, reliability, performance, scalability, availability…). And lots of project managers and business analysts I talk seem to be on an eternal quest for the perfect nonfunctional requirements template.

If you’re not familiar with nonfunctional requirements, here’s how Jenny and I defined them in our first book:

Users have implicit expectations about how well the software will work. These characteristics include how easy the software is to use, how quickly it executes, how reliable it is, and how well it behaves when unexpected conditions arise. The nonfunctional requirements define these aspects about the system. (The nonfunctional requirements are sometimes referred to as “nonbehavioral requirements” or “software quality attributes.”)

– Andrew Stellman & Jennifer Greene, Applied Software Project Management, chapter 6 (O’Reilly 2005)

And that’s a good starting point. But there’s an art to actually using nonfunctional requirements to make your software better. So how do we do that?

Thinking “how well” from the start

One of those senior architects I mentioned gave me a really good tip recently, one that really rings true. He told me, “Always think about performance from day one of your project, and test for it until you deliver.” Now, this particular person works on software tools used to design high-availability, high-performance server systems, so he thinks about performance a lot. But his point was that to design systems well, you need to think about performance — and other nonfunctional requirements — from the start.

Take a minute and think about that, because I think it’s an important point. I like it a lot for two reasons.

I like the fact that he’s thinking about how well the software works from the beginning of the project. I’m a firm believer in the old QA saying that “you can’t test quality in.” Yes, I know that saying rubs some people the wrong way because they think it sometimes lets people off the hook for testing at the end of the project. But there’s definitely a lot of truth in the idea that developers who think about quality from the beginning of the project build better software. If you design for performance, and if you then code for performance, then it’s pretty likely that you’ll end up with a more performant design than if only start thinking about performance at the very end of the project.

The other thing I like is that he didn’t say, “Think about performance, scalability, usability, robustness, etc., from the beginning of the project.” He narrowed it down to the single quality attribute that was most important to his particular project. I’ve talked to a lot of developers, project managers, designers, testers and business analysts over the years about nunfunctional requirements, and what I often find is that people seem overwhelmed. There are so many facets to quality beyond what the software does, and if you’re just trying to get started thinking about these things, it’s hard to know where to start.

Which leads me to my advice for developers. If you’re a programmer working on a project, here’s something that you can do today to improve the final product. Start with just three areas: availability, performance and reliability. I like these three because they’re easy to understand, it’s not hard to brainstorm examples of how they can go wrong.

Start with some definitions. Here are ones that Jenny and I gave in Applied Software Project Management:

Performance: The performance constraints specify the timing characteristics of the software. Certain tasks or features are more time-sensitive than others; the nonfunctional requirements should identify those software functions that have constraints on their performance.

Flexibility: If the organization intends to increase or extend the functionality of the software after it is deployed, that should be planned from the beginning; it influences choices made during the design, development, testing, and deployment of the system.

Reliability: Reliability specifies the capability of the software to maintain its performance over time. Unreliable software fails frequently, and certain tasks are more sensitive to failure (for example, because they cannot be restarted, or because they must be run at a certain time).

Now, make them practical and useful to your project by doing thee simple steps. To do this, you’ll need three index cards. Here’s what to do:

1. On the front of each of the three index cards, write one a type of nonfunctional requirement at the top. So on the first card, write “Performance”. On the second one, write “Flexibility”. And on the third one, write “Reliability”. Write these words on the front and the back of the card. If bright colors grab your attention, use a bright-colored highlighter to highlight them. (Personally, they don’t really do anything for me.)
2. Take each of the cards. On each of them write down the name of one feature f your software and what this particular attribute means for that feature. I like to use Search and Replace as an example whenever I talk about this sort of thing, because we’ve all used it and understand it. So on the Performance card I might write, “Search and replace: searching through a large document needs to be fast.”
   • 
3. Here’s the hard part. On the back of each card, write down a single test that you can do to figure out how well your software meets that requirement. So on the back of the performance card I might write, “Replacing 100 occurrences of a 4-character string in a 25MB document has to take under 750 milliseconds.” (The more concrete you can make this test, the better this works.)
   • 

Now that you’ve got those three cards, tack them up on your cubicle wall (or, even better, on your task board). Make sure the feature you wrote down in step #2 is facing forward. Make sure they’re someplace you’ll see them. Take just a minute or two each day to look at them and figure out if you’re headed in the right direction. What you’ll find more often than not is that as you’re designing your system, you won’t forget about those three things. Just spending a small amount of time writing down and thinking about these things can color your whole project.

Once you’ve moved from the design phase into the programming phase, flip the cards around so the test side is showing forward. (If you’re on an agile project with a three-week iteration, this might happen during the first week, but this works equally well for projects with a longer design phase.) As you’re writing the code for each of the features you wrote down, run that test by hand. It should only take a few minutes to do, and it will give you an idea of how well you’re doing. If you do this enough, you might end up figuring out a way to automate that test. If you do, and if you have a build server, then you can add it to the build. That way you’ll know any time you check in code that causes your project to see its performance (or reliability, or flexibility) degrade.

Try doing that on your next project, and what you should find is that you spend more time thinking about these things. When opportunities to improve those three specific things come up, you’ll recognize them and take them. And that’s a great way to build better software.

And that got me thinking about one of the important areas of architecture, one that I think a lot of people tend to overlook. Actually, what really got me started thinking about it was a Slashdot post, “News Content As a Resource, Not a Final Product,” which refers to this essay on publishing by Paul Graham. At the very top of the article, Graham (unintentionally) brings up a point that I think is interesting:

Publishers of all types, from news to music, are unhappy that consumers won’t pay for content anymore. At least, that’s how they see it.

In fact consumers never really were paying for content, and publishers weren’t really selling it either. If the content was what they were selling, why has the price of books or music or movies always depended mostly on the format? Why didn’t better content cost more?

A copy of Time costs $5 for 58 pages, or 8.6 cents a page. The Economist costs $7 for 86 pages, or 8.1 cents a page. Better journalism is actually slightly cheaper.

— Paul Graham, “Post-Medium Publishing”

I think that begs a basic question: what does “better” really mean when it comes to content? Is the Economist really better than Time? Our second book, Head First PMP, outsells our first book, Applied Software Project Management. Is one better than the other?

Like most questions of “better,” you have to understand how something’s going to be used before you can judge how good it is at its job. If you’re preparing for the PMP certification exam, Head First PMP is better for that job. If you’re trying to improve the way your team runs software projects, you’ll get a lot more mileage out of Applied Software Project Management. That’s a basic idea behind quality. You can’t judge the quality of a product without understanding the requirements, and how it’s going to be used to do a job. (I’ve been making that point on this blog for quite a while now!) And when it comes to testing software, that has real-life, practical implications. For example, it means that you can make sure your testing is effective by concentrating your tests on how the software is going to be used.

But it also has an important impact on architecture. A lot of us run into a serious problem when we’re designing a complex system: how do you actually “test” your architecture? It’s not like you can write, say, JUnit or NUnit tests for it. And architecture poses some pretty daunting review challenges. While it’s certainly a good idea to do architecture reviews, a lot of the time yo’re more likely to end up doing UI design reviews, prototype walkthroughs, and deployment reviews. Or you’ll end up starting out trying to review your object model, but you’ll end up buried in implementation detail.

My goal, when I’m designing a new system, is to come up with the best architecture I can. What makes one object model or database design “better” than another? The best design is the design that does the job best. That’s why user stories are so useful, and why I try to have them done before I start in on the architecture: because they help make sure my design is grounded in the way the system’s actually going to be used.

Try this the next time you’re at that point where you’ve got an initial software architecture laid out, but you haven’t started in on the coding and you’re looking for feedback. Instead of diving straight into the review, try starting out by giving an overview of the people who are going to use the system and the job they’ll be doing. I’ve found that simply grounding people in the actual goals and purpose of the system really focuses the feedback I get.

Andrew and Jennifer will be giving their Beautiful Teams talk at the IT Architect Regional Conference on October 12.

Tomorrow at the Agile 2009 conference, Abby Fichtner and Nate Oster are doing a workshop called Where Does Developer Testing End and Tester Testing Begin?. Jenny and I hope you can make it, because they’ll be doing a giveaway of autographed copies Beautiful Teams. Check out my O’Reilly Community posts for more information:

• Agile testing and Beautiful Teams (giveaway)
• Agile testing: why good developers resist great habits

In that second post, I spend a little time talking about some of the reasons that programmers resist great practices like test-driven development. Writing that post reminded me of something that Jenny and I wrote about change in Applied Software Project Management:

Many project managers—especially ones who have a technical background—tend to ignore the fact that their organizations are made up of people who need to be convinced of the importance of a change before they will adopt it. Some of these people will have an emotional or even irrational response to any attempt at change; it could take a sea change in the organization before they agree to it.

Irrational attitudes about software development usually boil down to two basic beliefs. First, people believe that most or all software projects are delivered late and delivered with many bugs, and that this is just a fact of life. Second, they believe that their organization is unique, and that the problems they are experiencing are particular to their organization and have never been seen before in any other organization.

(This second belief may seem odd, considering the many thousands of software organizations around the world that have all used similar tools and techniques to fix very similar problems and make real, lasting improvements. It’s possible that the belief in uniqueness comes from the fact that the software being built truly is unique, in that it has never been built before; it’s not a leap to assume—incorrectly—that the software project and all of itsproblems are therefore also unique to that particular organization.)

Many times, resistance is not irrational at all. Anyone who has been through a change previously—possibly a passing management fad—that didn’t fix the problem (or failed outright) may be resistant to another change. It may seem unfair, but if people in your organization have previously gone through poorly planned changes, it will be harder for you to make changes of your own.

When you are introducing new tools, techniques, or practices in your organization, you may encounter resistance for a number of reasons. By exploring the feelings, fears, and justifications for resisting change that project managers commonly encounter, these reactions can be unraveled and understood.

— Stellman & Greene, Applied Software Project Management, p206 (O’Reilly 2005)

It’s really easy to forget about this when you’re pushing for a change, especially something that requires extra work and learning. (I had to learn that the hard way – hopefully you won’t have to!)

Don’t get me wrong: I do think schedules are great tools for planning. You can use a schedule to organize the effort and manage your project’s dependencies. And you can use it to communicate with your team. A schedule’s a great way to get a lot of difficult-to-manage information down on paper so you can to see it all in one place. There have been many times over the years when it was only after I had a schedule all sorted out that I could see the project clearly. That’s when I could realize, “Hey, we can save time by doing these two things concurrently,” or, “Uh-oh, we’ve got the riskiest stuff on our critical path. That’s not a good idea!” That’s how a schedule can be a great tool for understanding your work.

But really, while those are important aspects of a project schedule, they aren’t the main way that we use schedules.

Think about what happens when you give a schedule to someone. If that person’s on your team, they’ll probably groan – maybe not out loud to you if you’re the boss, but we all groan a little inside when someone hands us a schedule that we need to meet. Just like a contractor who doesn’t really care whether the renovation on your house takes six weeks or eight weeks, your team doesn’t really care how long their work takes, as long as they have enough time to do it and don’t have to work nights and weekends to scramble to meet an unrealistic deadline. (Obviously, teams take pride in working quickly, but let’s be realistic here.)

But if you show a schedule to someone who’s not on your team, that schedule makes them happy. They’re generally relieved to see it, because now they know more about when you’re delivering the software. But it’s not the whole schedule they care about. Most of the time, when you hand a schedule to a client, a user or a manager at your company, they see one thing: the deadline. Which you just committed to.

And that’s the real nature of the schedule. Your project’s schedule contains a list of everything that you know you have to do – and it’s your way of telling the rest of the world that you’re committed to doing every single item on that list by a certain date. A schedule isn’t really about getting technical input from your team, or about planning out the work. Those things are nice side-effects of building a schedule, but there are tools that you can use to do those things that don’t involve committing to a date.

No, a schedule, at its core, is really about making commitments to other people. Schedules aren’t just there to be followed. They’re there to represent the real-life commitments that you made to other people. If you meet every commitment you made but go entirely off plan, your project will still be successful. But if you “work the plan” in perfect, excruciating detail, but you still manage to break the commitments that you made – even if it’s because of changes you couldn’t control – your project will be a failure. And that’s the power a schedule brings to your project. Like any tool, it can be used for good or malice.

That’s the perilous aspect of building a schedule: as soon as you commit yourself to it, you’ve introduced potential negative consequences that weren’t there before you put dates down on paper. (No wonder programmers are so reluctant to give estimates!)

Project schedules… not for the commitment-phobic

Jenny and I do a lot of speaking, and when we do we often find ourselves bringing up the idea that the point of any document is to communicate. Let’s say you’re my client, and we’ve got a requirements specification for a piece of software that I’m building for you. The specification itself, the words printed on paper, that’s not important. What’s important is that what’s in my head matches what’s in your head, that the software I’m planning on building is as close as possible as the software that you’re expecting me to deliver. It just so happens that a software requirements specification is a great tool for making sure that what’s in your head matches what’s in mine.

But the document does something else, too. Once we both have the same understanding, writing it down in a specification and agreeing on it means that we both made a commitment. I made a commitment to build the software that’s described in the document. But just as importantly, you’re making a commitment to me: that if I deliver software that meets that specification, you’ll accept it as complete. If you have changes, that’s fine. We just need to update the specification so that it has those changes.

(Oh, and just in case I didn’t make it clear, that “specification” could be a stack of index cards with user stories written on them, and we could make those updates every week or even every day, if that’s what the business needs.)

A schedule works the same way. If we write down and agree on a schedule, that means I promised to give you a certain set of deliverables on certain dates, and you promised to accept them.

At this point, someone who’s studied for the PMP exam might bring up “progressive elaboration,” which reflects the idea that a team can’t know everything about the project they’re working on at the very beginning. We don’t know everything about how the software will be built and tested when we’re still working on the design, and we don’t know everything about the design when we’re working on requirements. When we get to the next checkpoint we may realize that our earlier estimates were wrong, or that our whole approach was wrong. If we’re lucky, we’ve put together a team that accepts this as a basic reality, and plans all work in iterations that deliver complete, working software at the end of each iteration. (And yes, if you’re studying for the PMP exam, you do need to know about iteration!)

But can you see how, even with all of that, it still revolves around commitments?

That’s my point. A schedule is first and foremost a tool for managing your commitments, and only after that is it a tool for actually planning the work. (For a distant third, it’s a record of how the project turned out that you can use to generate metrics.) But the big point is that the schedule doesn’t commit you. Your commitments commit you. The schedule just keeps your commitments on paper in one place.

Now, while all of this may sound negative, it’s not. A good software team that can meet their commitments gains trust from their users, clients and stakeholders. If you’ve got a reputation for making commitments and sticking to them, you’ve got something really powerful. You’ve got the trust of the people you depend on to drive your project forward. And that’s where the schedule can be a really positive thing. To your users, it represents stable software they can depend on. To your team, it represents normal days without crazy pressure, without working late nights or weekends. When you take your commitments seriously, your schedule represents the truth about your project at any given point, and people come to depend on it.

I want to finish off by excerpting a section from “Applied Software Project Management,” because I think it cuts to the core of the point I’m trying to make about schedules and commitments, and how you can use them effectively.

Use the Schedule to Manage Commitments

A project schedule represents a commitment by the team to perform a set of tasks. When the project manager adds a task to the schedule and it’s agreed upon by the team, the person who is assigned to that task now has a commitment to complete it by the task’s due date. Senior managers feel that they can depend on the schedule as an accurate forecast of how the project is going to go—when the schedule slips, it’s treated as an exception, and an explanation is required. For this reason, the schedule is a powerful tool for commitment management .

One common complaint among project managers attempting to improve the way their organizations build software is that the changes they make don’t take root. Typically, the project manager will call a meeting to announce a new tool or technique—he may ask the team to start performing code reviews, for example—only to find that the team does not actually perform the reviews when building the software. Things that seem like a good idea in a meeting often fail to “stick” in practice.

This is where the schedule is a very valuable tool. By adding tasks to the schedule that represent the actual improvements that need to be made—for example, by scheduling all of the review meetings—the project manager has a much better chance of gaining a real commitment from the team.

If the team does not feel comfortable making a commitment to the new practice, the disagreement will come up during the schedule review. Typically, when a project team member disagrees with implementing a new tool or technique, he does not bring it up during the meeting where it’s introduced. Instead, he will simply fail to use it, and build the software as he has on past projects. This is usually justified with an explanation that there isn’t enough time, and that implementing the change will make the task late.

By explicitly adding a task to the schedule, the project manager ensures that enough time is built in to account for the change. This cements the change into the project plan, and makes it clear up front that the team is expected to adopt the practice. More importantly, it is a good consensus-building tool because it allows team members to bring up the new practice when they review the project plan. By putting the change out in the open, the project manager encourages real discussion of it, and is given a chance to explain the reason for the practice during the review meetings. If the practice makes it past the review, then the project manager ends up with a real commitment from the team to adopt the new practice.

– Stellman & Greene, Applied Software Project Management, chapter 4 (O’Reilly, 2005)

I hope that this helps explain how we think you can use a schedule can be used to help you and your team manage your projects more effectively to build better software.

We got this e-mail a few days ago from one of our readers:

Hello,

I bought your book, “Applied Software Project Management.” It seems very good overall, but I can’t get past the fact that your book seems to imply that software requirements come after the project plan/WBS/scheduling. Am I missing something?

On page 40, the script for estimating states that the input is documentation that defines the scope of the work being performed. Does this include the SRS? If so, why is this not made more explicit in your book (since requirements plays such a big role)? If not, how can a good estimate and schedule be generator before the requirements analysis has been performed?

I don’t get a solid sense of the relative timing of the activities (especially the requirements activity). Can you comment on this?

Thanks!!

– Wayne M.

That’s an excellent question. I’ve got a straightforward answer, and I’ve got a more involved answer.

The straightforward answer is yes. If you’re using Wideband Delphi (or, really, almost any estimation practice) to come up with estimates that you’ll turn into a schedule, then you need to get a handle on exactly what you’re estimating. So yes, when we say in our book that the input to the process is the “Vision and Scope document, or other documentation that defines the scope of the work product being estimated,” the “other documentation” we’re referring to definitely includes any software requirements you have. (For any readers who haven’t read our book, you can download a PDF of the estimation chapter that this reader’s referring to.)

Let me be clear about something here. You’re absolutely right that requirements analysis leads to more accurate schedules. If you’re lucky enough to have a really detailed specification at the beginning of the project that describes, in detail, all of the software that you’re going to build, then that will give you a much more accurate schedule than if you had a three-page Vision and Scope document that simply lets you know who the users and stakeholders are, explains their needs, and gives you the broad strokes about what features the team will build to meet those needs.

But when’s the last time you actually had the luxury of a complete specification before you had to deliver a schedule? And I’m stressing the word “complete” for a reason: it’s very rare that you’re done with the requirements before you’ve started building the software. So rare, in fact, that neither Jenny nor I have ever seen it in our entire careers, and I suspect very few (if any) of our readers have, either.

A good Agile developer might point out that this is the reasoning behind one of the core Agile principles: “Welcome changing requirements, even late in development.” And, in fact, that’s exactly why we dedicated so much of the chapter on software requirements in Applied Software Project Management to change control, because it’s important to not only accept that change happens, but to recognize it as a good thing. It’s better to change course partway through the project rather than to trundle on to an end goal that you know won’t actually meet your users’ needs or make your customers happy.

So with that in mind, go back to the process you mentioned. Specifically, take a look at the end of the script, because this is where it ties directly into the question you asked:

There’s an important idea there in those first six words: the project plan has been updated. That means that any time your world changes, you need to go back and update the scope, the WBS, the schedule, all the actual stuff you plan to deliverable (which might be written down in a statement of work), the list of people doing the work, a risk plan (if you built one)… all the stuff you used to plan your project.

…because there’s no single one Best Way™ to build software

And that’s why we didn’t give an explicit order to the activities. Sometimes you’ll end up planning out your project and building a schedule before you do requirements analysis; sometimes you’ll build a schedule after. Our goal was to help you do it well in either case. And by not forcing our readers into a single process or methodology, we don’t have to pretend to know all the answers… because, as far as I know, there is no single one Best Way™ to build software.  That’s the main idea, by the way, behind our “diagnose and fix” approach to improving the way you build software. Trying to overhaul your whole software process by doing a major process improvement effort is hard; adopting specific practices that make incremental improvements to the areas that hurt the most is much easier and a lot less risky.

This may sound like we’re calling for a lot of documentation, but it doesn’t have to be like that. Obviously, if you’re working on a team with dozens or even hundreds of people (like the teams Jenny often leads), this can be a pretty big task. But if you’ve got a small team working on a project that will take a few weeks to do, then this may just amount to rearranging your task board, updating your user story cards, updating a couple of Wiki pages, and having a quick stand-up meeting to make sure everyone’s in sync. That’s why people often talk about how running a really big team is like steering an aircraft carrier, because changing course requires miles of water, while running a small team is a lot more like piloting a speedboat that can change course really quickly.

So that’s the straightforward answer. But I think it’s worth delving a little deeper and asking an important question: What’s the nature of a schedule? I know, that probably seems like an odd question, but it’s actually important to understand what schedules are and how they’re used. (Technically, it’s only important if you want your projects to run well.)

A naïve answer might be to simply defer to that old project management chestnut: “Plan the work and work the plan.” If you haven’t heard that saying, take a minute and do a Google search for it. It’s one of those sayings that people love to quote, and it pretty much summarizes how a lot of people use (abuse?) project schedules.

I don’t like that saying, and there’s a reason for that.  I mean, don’t get me wrong, here. “Working the plan” is fine if it that plan accounts for changes. That’s one thing I really like about the PMBOK® and PMP approach: a whole lot of project planning revolves around how to handle changes, and specifically about dealing with change control. Also, it’s a great idea to make sure that you include a reserve for your project, and you can use risk planning to try to get a handle on the unknown.

To be continued in “The perils of a schedule, part II“

Some projects just go wrong.

It’s a fact of life. Projects go over budget, blow their schedules, squander their resources. Sometimes they go off the rails so spectacularly that there’s nothing you can do except (literally) pick up the pieces and try to learn whatever lessons you can so you don’t repeat the failure in the future.

Last week I got a phone call from a developer who was looking for some advice about exactly that. He’s being brought in to repair the damage from a disastrous software project. Apparently the project completely failed to deliver. I wasn’t 100% clear on the details—neither was he, since he’s just being brought in now—but it sounded like the final product was so utterly unusable that the company was simply scrapping the whole thing and starting over. This particular developer knows a lot about project management, and even teaches a project management course for other developers in his company. He’d heard me do a talk about project failure, and wanted to know if I had any advice, and maybe a postmortem report template or a lessons learned template.

I definitely had some advice for him, and I wanted to share it with you. Postmortem reports (reports you put together at the end of the project after taking stock of what went right and wrong) are an enormously valuable tool for any software team.

But first, let’s take a minute to talk about a bridge in the Pacific Northwest.

The tragic tale of Galloping Gertie

One of my favorite failed project case studies is Galloping Gertie, which was the nickname that nearby residents gave to the Tacoma Narrows Bridge. Jenny and I talk about it in our “Why Projects Fail” talk because it’s a great project failure example—and not just because it failed so spectacularly. It’s because the root causes for this particular project failure should sound really familiar to a lot of project managers, and especially to people who build software.

The Tacoma Narrows Bridge opened to the public on July 1, 1940. This photo was taken on November 7 of the same year:

While there were no human casualties, despite heroic attempts at a rescue the bridge disaster claimed the life of a cocker spaniel named Tubby.

Jenny and I showed a video of the bridge collapsing during a presentation of our “Why Projects Fail” talk a while back in Boston. After the talk, a woman came up to us and introduced herself as a civil engineer. She gave us a detailed explanation of the structural problems in the bridge. Apparently it’s one of the classic civil engineering project failure case studies: there were aerodynamic problems, and there were structural problems due to the size of the supports, and there were other problems that combined to cause a distinctive resonance which gave the bridge its distinctive “gallop.”

But one of the most important lessons we took away from the bridge collapse isn’t technical. It has to do with the designer.

[A]ccording to Eldridge, “eastern consulting engineers” petitioned the PWA and the Reconstruction Finance Corporation (RFC) to build the bridge for less, about which Eldridge meant the renowned New York bridge engineer Leon Moisseiff, designer and consultant engineer of the Golden Gate Bridge. Moisseiff proposed shallower supports—girders 8 feet (2.4 m) deep. His approach meant a slimmer, more elegant design and reduced construction costs compared to the Highway Department design. Moisseiff’s design won out, inasmuch as the other proposal was considered to be too expensive. On June 23, 1938, the PWA approved nearly $6 million for the Tacoma Narrows Bridge. Another $1.6 million was to be collected from tolls to cover the total $8 million cost.

(Source: Wikipedia)

Think back over your own career for a minute. Have you ever seen someone making a stupid, possibly even disastrous decision? Did you warn people around you about it until you were blue in the face, only to be ignored? Did your warnings turn out to be exactly true?

Well, from what I’ve read, that’s exactly what happened to Galloping Gertie. There was plenty of warning from many people in the civil engineering community who didn’t think this design would work. But these warnings were dismissed. After all, this was designed by the guy who designed the Golden Gate Bridge! With credentials like that, how could he possibly be wrong? And who are you, without those credentials, to question him? The pointy-haired bosses and bean counters won out. Predictably, their victory was temporary.

Incidentally, some people refer to this as one kind of halo effect: a person’s past accomplishments give others undue confidence in his performance at a different job, whether or not he’s actually doing it well. It’s a nasty little problem, and it’s a really common root cause of project failure, especially on software projects. I’ve lost count of the number of times I’ve encountered really terrible source code written by a programmer who’s been referred to by his coworkers as a “superstar.” Every time it happens, I think of the Tacoma Narrows Bridge.

But there’s a bigger lesson to learn from the disaster. When you look at the various root causes—problematic design, cocky designer, improper materials—one thing is pretty clear. The Tacoma Narrows Bridge was a failure before the first yard of concrete was poured. Failure was designed into the blueprints and materials, and even the most perfect construction would fail if it used them.

Learning from project failures

This leads me back back to the original question I was asked by that developer: how do you take stock of a failed project? (Or any project, for that matter!)

If you want to gain valuable experience from investigating a project—especially a failed one—it’s really important that you write down the lessons you learned from it. That shouldn’t be a surprise. If you want to do better software project planning tomorrow, you need to document your lessons learned today. You can think of a postmortem report as a kind of “lessons learned report” that helps you document exactly what happened on the project so you can avoid making the same missteps in the future.

So how do we take stock of a project that went wrong? How do we find root causes? How do we come up with ways to prevent this kind of problem in the future?

The first step is talking to your stakeholders… all of them. As many as you can find. You need to find everyone who was affected by the project, anyone who may have an informed opinion, and figure out what they know. This can be a surprisingly difficult thing to do, especially when you’re looking back at your own project. If people were unhappy (and people often are, even when the final product was nearly perfect), they’ll give you an earful.

This makes your life more difficult, because it’s hard to be objective when someone’s leveling criticisms at you (especially if they’re right!). But if you want to get the best information, it’s really important not to get defensive. You never know who will give you really valuable feedback until you ask them, and it often comes from the most unexpected places. As developers, we have a habit of dismissing users and business people because they don’t understand all of the technical details of the work we do. But you might be surprised at how much your users actually understand about what went wrong—and even if they don’t, you’ll often find that listening to them today can help make them more friendly and willing to listen to you in the future.

Talking to people is really important, and having discussions is a great way to get people thinking about what went wrong.  But most effective postmortem project reviews involve some sort of survey or checklist that lets you get written feedback from everyone involved in or affected by the project. Jenny and I have a section on building postmortem reports in our first book, Applied Software Project Management, that has a bunch of possible postmortem survey questions:

• Were the tasks divided well among the team?
• Were the right people assigned to each task?
• Were the reviews effective?
• Was each work product useful in the later phases of the project?
• Did the software meet the needs described in the vision and scope document?
• Did the stakeholders and users have enough input into the software?
• Were there too many changes?
• How complete is each feature?
• How useful is each feature?
• Have the users received the software?
• How is the user experience with the software?
• Are there usability or performance issues?
• Are there problems installing or configuring the software?
• Were the initial deadlines set for the project reasonable?
• How well was the overall project planned?
• Were there risks that could have been foreseen but were not planned for?
• Was the software produced in a timely manner?
• Was the software of sufficient quality?
• Do you have any suggestions for how we can improve for our next project?

We definitely recommend using a survey where the questions are grouped together and each question is scored, so that you can start your postmortem report with an overview that shows the answers in a chart. (If you’re looking for a kind of “lessons learned template,” this is a really good start.)

The rest of the report delves into each individual section, pulling out specific (anonymous) answers that people wrote down or told you. Here’s an example:

Beta
Was the beta test effective in heading off problems before clients found them?
Score: 2.28 out of 5 (12 Negative [1 to 2], 13 Neutral [3], 9 Positive [4 to 5])
All of the comments we got about the beta were negative, and only 26% (9 of 34) of the survey respondents felt that the beta exceeded their expectations. The general perception was that many obvious defects were not caught in the beta. Suggestions for improvement included lengthening the beta, expanding it to more client sites, and ensuring that the software was used as if it were in production.
Individual comments:

• I feel like Versions 2.0 and 2.1 could have been in the beta field longer so that we might have discovered the accounting bugs before many of the clients did.
• We need to have a more in-depth beta test in the future. Had the duration of the beta been longer, we would have caught more problems and headed them off before they became critical situations at the client site.
• I think that a lot of problems that were encountered were found after the beta, during the actual start of the release. Shortly thereafter, things were ironed out.
• Overall, the release has gone well. I just feel that we missed something in the beta test, particularly the performance issues we are experiencing in our Denver and Chicago branches. In the future, we can expand the beta to more sites.

(Source: Applied Software Project Management, Stellman & Greene 2005)

There’s another approach to coming up with postmortem survey results that I think can be really useful. Jenny and I have spent the last few years learning a lot about the PMBOK® Guide, since that’s what the PMP exam is based on. If you’ve studied for the PMP exam, one thing you learned is that you need to document lessons learned throughout the entire project.

The exam takes this really seriously: you’ll actually see a lot of PMP exam questions about lessons learned, and understanding where lessons learned come from is really important for PMP exam preparation.

The PMBOK® Guide categorizes the activities on a project into knowledge areas. Since there are lessons learned in every area of the project, those categories (the knowledge area definitions) give you a useful way to approach them them:

• How well you executed the project and managed changes throughout (what the PMBOK® Guide calls “Integration Management”)
• The scope, both product scope (the features you built) and project scope (the work the team planned to do)
• How well you stayed within your schedule or if you had serious scheduling problems
• Whether or not budget was tight, and if that had an effect on the decisions made during the project
• What steps you took to ensure the quality of the software
• How you managed the people on the team
• Whether communication—especially with stakeholders—was effective
• How well risks were understood and managed throughout the project
• If you worked with consultants, whether the buyer-seller relationship had an impact on the project

For each of these areas, you should ask a few basic questions:

1. How well did we plan? (Did we plan for this at all?)
2. Were there any unexpected changes? How well did we handle them?
3. Did the scope (or schedule, or staff, or our understanding of risks, etc.) look the same at the end of the project as it did at the beginning? If not, why not?

If you can get that information from your stakeholders and write it down in a way that’s meaningful and that you can come back to in the future, you’ll be in really good shape to learn the lessons you need to learn from any project. Even a failed one.

I got a great question from a software developer who also happens to be a fellow CMU alum.

I have a question related to managing scope creep with respect to “on-going”/iterative development processes.

I’m currently managing a project where we’re redesigning my application’s primary workflow. Simply put, the app is currently designed to have users to signoff all items and we’re redesigning it to be exception-based (only require certain items to be signed off).

As we’ve progressed down the path of planned iterative development, a lot of good/new ideas for future enhancements/requirements spring up. I find myself regularly working with my users and “working group” to prioritize and analyze if any of these new ideas need to be considered to build sooner rather than later (and thus triggering plan adjustments or delays).

I often feel like I’ll end up delivering a product that does deliver the initial vision, but still doesn’t make my users happy, as they’ve already shifted their expectations to wanted the “next” thing (aka phase 2).

Do you have any other tips about how to manage this process?

I’ve used things like taking a timeline-style roadmap and adjusting it by overlaying the new requirements and shifting the timeline out. Do you have an recommendations of ways to present this type of information?

Curious your thoughts. Thanks.

— Seth L.

Iterative software development can be a really useful—and highly effective—tool for software development, but it’s also one of the most abused tools I’ve seen. Even as recently as a few days ago, someone in charge of a software team that’s critical to his comapny came to me with the (incorrect) assertion that iteration just means diving into a prototype without talking to anyone or doing any investigation. Iteration done well can lead to very high quality software. But as Seth saw, iteration done poorly can lead to scope creep and serious planning issues.

Making your users “happy” means managing their expectations. They need to see exactly what you’re working on, and what’s coming next. If all people see is deadlines and they don’t have a sense of what’s going on, then they naturally start looking to the next deadline, because that’s all they see. The more visibility you can give them into the way you build software, the more understanding they’ll have – that’s just human nature.

There are a few things that work well for improving visibility into your project’s iterations. One of them is a task board, which typically involves sticking index cards with your user stories or scenarios on a whiteboard or wall. This means that you actually need to have user stories or scenarios. Scope creep is often an indication of a requirements problem, and getting consensus on at least the scenario level about exactly what’s going into the iteration. Having the index cards arrayed on a task board, with each index card showing the status (“planned”, “in development”, “completed”, “out of scope”) gives a lot more visibility into exactly what you’re building and how you’re building it. In a lot of ways, this is a sort of iterative development project plan.

Another way to prevent iteration-related scope problems is committing to delivering releasable code at the end of each iteration. Test-driven development (or, at least, developing complete unit tests) and continuous integration are effective ways to help make that happen. If your stakeholders are comfortable that you’ll deliver high-quality code at each iteration, they’ll feel less pressure to get the new features in immediately, and will be more willing to wait until the next iteration.

If this sounds like something that might help you, I definitely recommend reading the interview Jenny and I did with Mike Cohn for Beautiful Teams, who knows more about agile and iterative planning than pretty much everyone . He has a lot to say about effective iteration planning. There are pictures of task boards he’s used in the past.

That gets me back to the basic idea—one which I give Mike a whole lot of credit for helping people understand—that iterative development, especially in an Agile project, works best when we take the time to plan each iteration. It still faces the same problems: requirements need to be discovered, scope needs to be controlled, and progress needs to be communicated to everyone who cares about it… especially to anyone who can potentially make the developers’ lives more difficult. That’s why the most successful Agile development projects collect requirements and document them using user stories (or other techniques for writing down what the software needs to do). They plan their progress using task boards, forecast them using calculations and charts like project velocity and burn down rates, and constantly keep any business owners and other stakeholders up to date on their progress.

It’s a great way to develop software, and it’s been really effective for a lot of teams. And I think it shows that iterative development does not necessarily mean unplanned development.

When I sent this to the developer who sent me the question, he had an interesting follow-up, which I thought deserved a response:

So I’ve been digesting this a bit and I am curious to get your thoughts about adapting project management fundamentals into the often fluid process of app management. I manage a few virtual projects within my company and at times have struggled to keep things focused as business demands and/or interests shift over time. Similarly, the “iterative” approach has helped to clarify requirements while building out new flows/apps, but as you pointed out can be very tricky to get “right”.

It’s funny how often I hear people say, “Well, this project management stuff works in theory, but my project is fluid” (or “changing,” or “under too much pressure from the business,” or “critical,” etc.). It turns out that pretty much every project is challenging, and project management is set up specifically to deal with that kind of challenging project.

Here are two thoughts I had relating to this idea.

First, the iterative development model works very well, as long as you’re committed to delivering a high-quality product at the end of each iteration. Whether or not you develop using an iterative approach, you need to manage change: prevent unnecessary changes, and make sure you understand the impact of any change that you make. It also means that you need some sort of scope baseline, so that you know what is and is not a change. It’s faster and easier to update software on paper, before it’s written into code, so the more changes you can move to the “write it down and review it” phase of your project, the better.

And second, if your business is overly demanding, it often means that you could manage your stakeholders’ expectations better. Make sure you identify them – and write down their names and needs! – from the very beginning of the project. Talk to them… a lot. Make sure they’re in the loop. If possible, see them so often that they’re sick of seeing you. If they’re always aware of what you’re doing, there won’t be nearly as many surprises. Also, the more your stakeholders understand the details of the work that you’re doing, the more slack they’ll cut you when they ask you for changes. Often, when someone puts a lot of pressure on you to do the impossible, it’s because they don’t realize that’s what they’re asking.

“I teach Project Management for for a project management firm and its clients. Using Head First PMP exclusively as the course material, my students have an 84% first time passing rate for the PMP and CAPM. This is by far the very best and most complete book for anyone looking to improve their project management skills and pass the PMP exam.”

—Rocket Williams, PMP, MCITP, MCT
Director of Business Development and Project Management Processes
AdaQuest, Inc.

Jenny and I just put the finishing touches on the second edition of Head First PMP, and it should be out in bookstores as soon as it comes off the presses. We’ve brought it completely up to date to provide 100% coverage of the new version of the PMP exam. It was definitely a lot of work — and in case I haven’t mentioned it lately, I’m lucky to have a coauthor who’s as committed, hard-working, and quality-oriented as Jenny! You can download Head First PMP, 2nd Edition today as an O’Reilly Rough Cut PDF (see the end of this post for details).

I’m really impressed with all the changes that PMI put into the PMBOK® Guide, 4th Edition (which is what the PMP exam is based on). When we first wrote Head First PMP, there were a few concepts and ideas in the third edition that Jenny and I found a little challenging to explain in a straightforward way that’s easy to understand. When we read the new PMBOK Guide for the first time, I was happy to see that they’d improved some of the more cumbersome concepts that people had a really tough time understanding — like the difference between a scope statement and a preliminary scope statement, for example. Now that the preliminary scope statement’s gone, scope management makes a lot more sense.

And there are new additions that made me really happy. It was great to see a whole new process dedicated to collecting requirements. If you’ve read my Requirements posts, you know how important I think requirements management is to making sure your projects are successful. I’ve believed for a very long time that project managers — especially for software projects — have a responsibility, even an obligation, to make sure the whole team understands the project’s requirements. That’s why we put a whole chapter on requirements in our first book! So the Collect Requirements process is a really welcome edition to the PMBOK Guide.

There was another really interesting addition: the addition of iterative project phases. I think it’s really useful that the project management world has increasingly embraced iterative project development, especially in software. Personally, I attribute this, at least in part, to the fact that Agile development has soared in popularity over the last few years. The fact that project managers are being trained to work with teams working iteratively is a really good development, and it’s great to see that being reflected on the PMP exam.

Also, it was nice to see that the Manage Stakeholders process got a new name: it’s now the Manage Stakeholder Expectations process. I always thought it seemed a little… unrealistic? yes, that’s a good word — it always seemed a little unrealistic to think that a project manager could actually manage stakeholders on a real project. But managing their expectations is something that every project manager needs to do in order to keep a project running.

There are lots of other PMBOK® Guide changes, big and small, and we’ve put months of painstaking effort into tracking down each one and making sure the book is completely up to date. And we put together a phenomenal review team to help us ensure that Head First PMP, 2nd edition has 100% coverage of the new version of the PMP exam based on the PMBOK® Guide, 4th Edition.

Oh, one more thing. I wanted to take a minute and thank all of the people who’ve been writing to us and asking when the new edition of the book is coming out. I’m sorry I couldn’t write back to each of you individually; we’ve been working really hard to make sure the new edition is as accurate and easy to use as possible, and we just didn’t have time to answer all of your e-mails. But we definitely heard you, and want you to know that we think the second edition is even better than the first! And, as always, if you’ve got questions about project management or difficult PMP topics, definitely send them to us. We get a lot of questions and e-mails, and don’t always have time to answer each one, but we do love Q&A and if it’s a good question we’ll try to write a good answer!

You can download Head First PMP, 2nd Edition today as an O’Reilly Rough Cut. They’ve got a great deal where you can get the online rough cut PDF today when you pre-order the book! Or you can just pre-order the book and get 35% off.

James Turner‘s weekly O’Reilly Week in Review podcast this week features an interview with Jenny and me about Beautiful Teams, and what goes into making a team work well.

I’ll transcribe a quick excerpt from the interview – we’re talking about our interview in the book with NASA manager and team leader Peter Glück:

Jenny: You hear all your life about what it’s like to work at NASA. There were so many times we’d want to put in place a practice, and you’d hear, “Well, this isn’t NASA”. So to hear about how NASA actually did stuff was really exciting. It was such a revelation that they pretty much do stuff like everybody else, you know?

Andrew: I kind of had a feeling of, “They put their pants on one leg at a time, just like everyone else.” They build the same way, they test the same way, it’s just that they put a whole lot more time, money and effort into testing. And there are some things they can’t to. We talked about continuous integration. I asked him, “Do you do continuous integration?” Well, no, they don’t do continuous integration, because that involves integrating with a hardware platform that they have to take into a clean room. If your inegration process involves a clean room, it probably can’t be automated.

If you want a little background about what goes into building an O’Reilly book, working with the folks there, and some of the thought process behind Beautiful Teams, definitely have a listen. You can hear the whole interview here!

Forbes picked up our Beautiful Teams interview with Tim O’Reilly and published it as an article called The Secrets of Great Teamwork.When Jenny and I talked to Tim, he had some intriguing things to say about what makes people work together. There’s plenty of good stuff in the interview, but one bit that really sticks in my mind is this excerpt:

Andrew: Do you think it’s possible to have a great team that doesn’t have a great leader? That has more of a collective leadership?

Tim: Yes, it is possible. But here’s the thing. Take Apache, because I think Apache is a great example of that. Tim Berners-Lee laid down the blueprint. He said, “I’ve created this idea for this hypertext server, this hypertext client.” And the genius of Apache was in embracing the constraints. I still remember back in the mid-’90s, this moment where Netscape had added this, Microsoft had added that, and everyone was saying, “Apache seems to be standing still. They aren’t adding all these features. They aren’t keeping up!” And the guys at Apache said, “Yup. What we do is a hypertext server, and we have this nice extension mechanism where people who want to do something else can add it on.”

And that goes back to that architecture of participation. They didn’t build this big, conglomerate, complex application. They kept to a pure vision. The vision did actually come from a visionary leader; it just wasn’t part of Apache. Apache came from a group of people who were abandoned by the NCSA server team when they all went to found Netscape. And there were a bunch of customers, so they said, “We have to maintain this, and keep it going.” What was wonderful about that kind of team was that they accepted the constraints that were laid down by the design of the system. They didn’t try to show off their ego or their creativity.

I think a lot of the work done by the IETF (the Internet Engineering Task Force) in the early years did the same thing. There were some wonderful principles laid down, and people really honored them. If you read some of John Postel’s stuff in the TCP RFC about the robustness principle, it sounds like something out of the Bible, for Christ’s sake! “Be conservative in what you do; be liberal in what you accept from others.” Literally, that’s what it says.

The point is that if you have the system architected right, you have a better chance of success for teams. You don’t want teams that are dependent on a single vision or leader, because if you lose your leader, the whole team goes “pop.”

Something that came up over and over again throughout our many interviews and stories is the connection between teamwork and architecture.  I think Tim hit on exactly the right example with Apache, but there are a lot of other examples throughout the book. Peter Glück had some really interesting things about how the architecture restrictions of NASA projects affected the teams (and especially the practices they used). And Auke Jilderda talked about the “use-use-reuse” model for designing reusable code, and how it impacts teams. I have to be honest: before working on Beautiful Teams, I definitely didn’t make such a close connection between how great (or lousy) teamwork affects architecture.

You can read the entire interview — which, incidentally, is one of my favorites in the book! — on O’Reilly FYI.

Here’s a question that I get over and over again:

What’s the difference between user stories and use cases?

— Ron K.

Before I dive into an answer to that question, let’s rewind a little bit and talk about where user stories came from. I like them because they’re a great example of how the Agile movement changed the software world. Programmers used to just dive right into software projects and start coding. Whenever one of those pesky users started to tell us what they needed, we’d stop them and say something like, “Don’t worry, I totally get it. I know what you need.” The Agile folks figured out that “I know what you need” is a nasty little trap that programmers — especially good ones — fall into. We’d spend the whole project thinking that we understood our users’ needs, only to deliver software that they didn’t want. The Agile folks realized that if developers had to start working with users throughout the project to understand their needs if they wanted to avoid the code-and-fix trap.

And that’s why I think the user story is one of the most useful tools to come out of the Agile movement. A user story — some people call it a scenario — expresses one very specific need that a user has. It’s usually written out as a couple of sentences. Most user stories are written in the language of the users, so any user should be able to read a user story and immediately understand what it means. A lot of time, user stories are written on index cards, although I’ve put them in Word documents, Excel spreadsheets and Wiki pages (depending on how the particular project is run).

A use case is similar to a user story, because it also describes one specific interaction between the user and the software. When I’m training people to improve the way they write down their project’s requirements, I often describe the use case as a “deceptively simple tool” that helps us find and write down all of the ways users interact with the software.

Looking at those definitions, I can definitely see why there’s confusion about the difference between user stories and use cases. If you look at the last two paragraphs, it might sound like I said the same thing twice! But while user stories and use cases are definitely similar, there are important differences between them. Each serves a distinct purpose, and I think they both have their place on a well-run software project.

I think the easiest way to understand the difference between use cases and user stories is to take a look at an example. Luckily, I’ve got one that I think helps make the difference clearer.

In our first book, Applied Software Project Management, Jenny and I spend a lot of time talking about how to develop use cases and use them to build better software. And as an example, we showed a use case for a software feature that everyone should be familiar with: a search and replace feature from a word processor. Comparing a user story for search and replace with a use case for the same feature helps highlight the differences.

It’s not hard to find lots of user story examples. There are lots of different ways you’ll see a user story formatted (although if you’re looking for a user story template, a 3×5 index card should be a good starting point!). So what would a user story for search and replace look like? I took a stab at writing one:

(One thing I like to do with user stories is to use “he” or “she”, rather than try to be gender-neutral. I think this makes the user in the story easier to connect with by personifying him a bit. It it also lets me write in a more conversational tone, which makes the user story friendlier and, I think, a bit easier to read and understand.)

Now, if you’re not familiar with user stories, you might think to yourself, “Wait a minute, my word processor’s search and replace feature does a lot more than that!” And that’s okay. A typical user story will have enough information to help the user understand what it is the software needs to accomplish, but it’s not meant to be a complete description of how the software works. I’m not going to try to give a long lesson in writing effective user stories here; I highly recommend reading Mike Cohn’s excellent articles and posts aboout user stories. (Mike, incidentally, is one of the software development veterans who contributed to our latest book, Beautiful Teams [O'Reilly, 2009]. He has some really fascinating things to say about Agile planning.)

So what would a use case sample look like for search and replace? Here’s the use case example Jenny and I built to demonstrate how use cases work:

Now, if I were a developer building a word processor or text editor, I’d actually be able to write a search and replace feature that implements that particular use case. (Just to be clear: there are many different use case formats; Jenny and I use this use case template in our book because it’s stripped down to the bare minimum sections that we think an effective use case should have.)

Here’s something about use cases that I think is interesting. While you were reading through our use case example, were you thinking of something that looks like the Replace dialog in Notepad or Microsoft Word, or the Find dialog in TextEdit? If so, take another look at the sample use case. It doesn’t have any words like “window,” “button,” “click,” “field” or “checkbox”. It’s all about what actions the user takes, and how the software responds. And there are many different ways that you could build software that implements the use case. Have you ever used the search and replace feature in vi? What about the search and replace feature in Emacs? They have very different user interfaces! Who knew there were so many ways you could implement search and replace? But if you compare each of them with this use case, they all follow the same basic course of events.

So now that we’ve gone through the use case and user story examples, what’s the difference between user stories and use cases? Here’s what I think are some of the key differences:

• User stories are about needs. When you write a user story, what you’re describing is a “raw” user need. It’s something that the user needs to do in his day-to-day job. If you never build any software for him, then that need will still exist!
• Use cases are about the behavior you’ll build into the software to meet those needs. A developer who needs to build working software should be able to read a use case and get a good sense of what the software needs to do. It typically has a lot of detail, and describes everything that the developer needs to build in order to meet the user’s need. That’s why it needs to have a lot more detail, and be clear and unambiguous.
• User stories are easy for users to read. When you write a user story, what you’re concentrating on is writing something that anyone can understand, in the language of the users. We all know that developers have a lot more patience for talking about details of the software they’re building than users do, which is why user stories have to be brief. A user story needs to express a complete thought in just a couple of sentences. (That’s also why it’s good to put them on index cards: somehow, that makes it clearer that it’s self-contained and independent of the other user stories.)
• User cases describe a complete interaction between the software and users (and possibly other systems). When you’re doing use case analysis, what you’re doing is designing a functional solution that meets the users’ needs. It needs to be something that developers can implement. It’s possible that one user story could spawn several use cases. And when you combine all of your use cases into one use case document, you’ll end up with a complete description of every interaction between the user and the software that you’re planning on building. And if your software has to interact with multiple systems, you may end up treating those other systems as actors in your use case.

Once you get a sense of how user stories and use cases differ, you can start to see what purpose they can serve on your project. And if you only use user stories, or if you only use cases, then maybe on your next project you can try using them both.