“Grand principles that generate no action are mere vapor. Conversely, specific practices in the absence of guiding principles are often inappropriately used.”

- Jim Highsmith, Agile Project Management: Creating Innovative Products (2nd ed.)

The board game Othello has the slogan, “A minute to learn, a lifetime to master.” This applies really well to a team that’s learning Scrum. The basic practices and mechanics of Scrum are straightforward, and not difficult to adopt. This is why many teams use Scrum as a starting point for going agile.

The basic pattern for a Scrum project is simple, which makes it very attractive for teams who want to go agile. And if that were all it took to adopt Scum effectively, we’d all be running great agile teams! But many teams find that they run into trouble with their Scrum adoption, and usually end up with what feels like an “empty” implementation. We explore this in our new talk, Scrum and Self-Organizing Teams: Openness, Courage, Pigs, and Chickens [pdf].

For a Scrum team to become effective, they need to do more than just follow the basic Scrum pattern. Effective Scrum teams are self-organizing, as Ken Schwaber explains (note the phrase that we emphasized):

For Scrum to work, the team has to deeply and viscerally understand collective commitment and self-organization. Scrum’s theory, practices, and rules are easy to grasp intellectually. But until a group of individuals has made a collective commitment to deliver something tangible in a fixed amount of time, those individuals probably don’t get Scrum. When the team members stop acting as many and adopt and commit to a common purpose, the team becomes capable of self-organization and can quickly cut through complexity and produce actionable plans.

- Ken Schwaber, Agile Project Management with Scrum

The goal of this talk is to help teams “get Scrum” by building on the practices and patterns of Scrum, and through those practices show the ideas behind the principles of collective commitment and self-organization.

In Agile Project Management with Scrum, Ken Schwaber introduced five Scrum values: courage, commitment, respect, focus, and openness. Understanding these values is an important key to understanding self-organizing teams.

• Each person is committed to the project’s goals. That level of commitment can be achieved when the team has the authority to make decisions in order to meet those goals, and everyone has a say in how the project is planned and executed. For example, sometimes a requirements document isn’t perfect. To make the project successful, a team might have to ignore a documented requirement in order to deliver a product that’s much more valuable. This is only possible once they’re given the authority to make that decision.
• Team members respect each other. When team members have mutual respect, they’re able to trust each other to do a good job with the work they’ve taken on. But that respect doesn’t always come easily to programmers and other technical people. Many programmers, especially highly skilled ones, often base their respect purely on technical ability. This can be a barrier to effective Scrum adoption. If a programmer doesn’t respect the product owner, he won’t listen to that product owner when they talk about the goals of the project.
• Everyone is focused on the work. When a Scrum team member is working on a sprint, that’s his only job for the duration of the sprint. He is free to do whatever work is needed to complete the iteration backlog, and handle any changes that are made to that backlog during the sprint. When every team member is focused on the sprint goals and given the freedom to do whatever work is needed to meet those goals, the whole team is able to organize itself and easily redirect whenever a change is needed.
• Openness. When you’re working on a Scrum team, everyone else on the team should always be aware of what you’re working on and how it moves the project towards its current goals. Many of the Scrum practices are aimed at encouraging openness among the team members. Task boards, for example, allow everyone to see all of the work being done by each team member, and how much work is left to do. Burn-down charts let each person gauge for themselves how quickly the sprint is meeting its iteration goals. The Daily Scrum, when done effectively, is a almost pure exercise in openness, because each person lays bare their tasks, challenges, and progress for the whole team to see. All of these things can help the team to create an atmosphere of mutual support and encouragement.
• Team members have the courage to stand up for the project. When you choose openness over opaqueness, you make the team stronger rather than making yourself stronger at the expense of the team. It takes courage to do that, but when you do you end up with a better product and a better work environment. Scrum teams have the courage to live by values and principles that benefit the project. It takes courage to ward off the constant pushback from a company whose values clash with the Scrum and agile values. This requires vigilance on the part of every team member, especially the Scrum Master. But it also requires each person to be willing to trust that delivering valuable software will help them overcome resistance to these values. This requires courage too, especially when it comes time to sit down for a review with the boss. It takes courage to say to yourself, “Helping this team produce valuable software is more important to me that how the company sees my own personal contribution.”

Methodologies have built-in values

Every company has its own culture that includes specific values. For example, some companies value separation of duties, where each person has their specific role to play, and is protected from having to be accountable for things that they can’t easily influence or control. Other companies value transparency, where information is shared freely and even low-level employees can influence management decisions. Neither of these is the “right” way to run a company. Every individual company has a culture that evolves over time, based on the way it’s managed and the decisions that are made.

Every methodology has values built into it. Specific agile principles are often tied to (or implemented by) individual practices, and that those practices are an effective way for a team to bring each principle to the project. A team in a company that reserves decision-making for managers only will find it difficult to truly commit to projects. The same goes for any value or principle: if they clash with the company’s values, it presents a barrier to adoption.

But in a company where the culture matches the agile values and principles, an agile team will be much more successful than a command-and-control team. (This is one of the sources of the “astonishing results” that some agile teams report.)

You might be surprised at just how well the agile values and principles match your company’s culture. A good first step in introducing agile to your company is to talk about the values, and how they might impact your company’s culture. If you find that your agile adoption runs into trouble, finding the mismatch between agile values and company culture can help you smooth out the transition (or at least help you feel better by understanding why things went wrong).

So how would you build courage on a team? How would you get a team to believe in themselves, and believe that Scrum will not only help them build more valuable software, but that they company will see the value in their new methodology?

Last week Jenny and I gave our new talk, Getting Agile Right [pdf], for the first time. We’re really excited, because it also marks our first public announcement of our current book project for  O’Reilly: a new book about agile development and project management. It’s aimed at people preparing for the PMI-ACP certification, but our goal is to help anyone who’s interested in agile really understand the ideas behind it.

We talk to a lot of teams and help  them understand what’s gone right and wrong with their projects, and look for common patterns of project problems and failure (that’s what our Why Projects Fail talk [pdf] is all about.) People starting with agile often us about something that we call “better-than-not-doing-it results.” Basically, they adopt a bunch of great agile practices, and they see a clear improvement. It was definitely worth going agile, but something feels a little hollow about it. They were expecting the “astonishing results” and “hyper-productive teams” that they’d read about in agile books and blog posts, but there’s a feeling that at its core, the team hasn’t really changed how they do things, they just made incremental improvements.

I recently read Lyssa Adkins’ excellent book, Coaching Agile Teams, and one of the really insightful things she points out is that “metaphor is a powerful thing.” Jenny and I put a lot of thought into coming up with a good metaphor to help explain what’s going on. We hit on a really good one: the story of the blind men and the elephant. I like the Jain version of the story (from Wikipedia):

A Jain version of the story says that six blind men were asked to determine what an elephant looked like by feeling different parts of the elephant’s body. The blind man who feels a leg says the elephant is like a pillar; the one who feels the tail says the elephant is like a rope; the one who feels the trunk says the elephant is like a tree branch; the one who feels the ear says the elephant is like a hand fan; the one who feels the belly says the elephant is like a wall; and the one who feels the tusk says the elephant is like a solid pipe.

A king explains to them: ”All of you are right. The reason every one of you is telling it differently is because each one of you touched the different part of the elephant. So, actually the elephant has all the features you mentioned.”

So what does this have to do with agile teams having trouble getting past better-than-not-doing-it results?

Teams that get better-than-not-doing-it results from agile are often the ones who were already able to get software out the door reasonably well before starting with agile, and were hoping that agile adoption would help them get a real improvement. The problem is that before the team started adopting agile practices, they were experiencing problems—not the serious, software crisis problems that caused their projects to fail outright, but problems that caused friction and discomfort on the team. The source of these problems is something that we call a “fractured perspective”: the developers think about developer stuff, project managers think about project manager stuff, and they throw the code over the wall to a business user who thinks about business stuff. Everyone is really busy thinking about his or her own project work. There isn’t a lot of communication between people, and they’re really functioning as individuals working separately towards compatible goals, not as a team.

That’s where the Blind Men and the Elephant story comes in—it’s a good metaphor for how a team with a fractured perspective adopts agile. Each person sees the practices that impact his or her work. Developers concentrate on, say, test-driven development, refactoring, and automated builds. Project managers like task boards, project velocity, and burndown charts. Business users use release planning and user stories to get a better grasp on what the team is doing. Team leads use daily standups and retrospectives to manage and improve the team. Everybody wants something different from the project, and they each see a few practices that do something specific to help them.

And that’s definitely going to improve things, because agile practices are generally really good. The problem is that since everyone—developers, project managers, business users, and team leads—sees the project from a different perspective, they’ll concentrate on only those practices that immediately appeal to them. There’s a paradoxical effect (we call it, “See! I was right all along”) where each person now sees only the part of agile that affects his specific project work, and draws the conclusion that agile is all about getting everyone else to come around to his point of view.

But agile is more than just practices. In fact, that’s one of the core ideas behind agile: principles over practices. So while the agile “elephant” is made up of many great practices, the whole thing is greater than the sum of the parts. And if you only see practices—especially if you’re only looking at the practices that directly affect your project work—then you’ll only see one small piece of agile. The “elephant” of agile is made up of the practices day to day, but it’s much bigger than just those practices.

A team whose members only see the practices and don’t think about the principles will miss out on the important interactions between people. Their perspective stays fractured, and they stay separate and don’t really function as an effective team. They’ll still get their work done, but they miss out on the great team interactions and collaboration that make agile really work.

This is built into agile. If it’s been a while since you’ve had a look at the agile manifesto, open it up again and have a look at the very first value:

Individuals and interactions over processes and tools

Processes, methodologies, and tools are still important (“…while there is value in the items on the right, we value the items on the left more.”). But even more important than specific practices are the individuals and interactions. It’s these values, and the twelve principles, that show us how the practices work together, and serve as a guide for how teams adopt those practices.

That’s one of the lessons of our “Getting Agile Right” talk [pdf]. It’s also going to be one of the big themes in our upcoming book, due out from O’Reilly next year, about agile development, project management, and the new PMI-ACP agile certification. We’ll continue to make posts to help connect these dots and learn more about agile.

It’s not always easy to recognize when your project is in trouble. Yes, if your project crashes and burns and completely fails to deliver, it’s failed. But sometimes you don’t realize that you’ve  or you’ve built the wrong software and are about to make your users very unhappy. That’s why Jenny and I put together our Why Projects Fail talk [pdf] a few years ago: to help people recognize when their projects are starting to go off the rails, and learn a few simple techniques for fixing them. If you learn to recognize the signs of project problems, it’s easier to take action quickly and turn your project around:

Software projects are a lot like cheesy horror movies. After you’ve seen a few of them, you know that the first guy to leave the group is going to get an axe in his head. Projects are the same way. People keep making the same mistakes over and over, and it keeps getting their projects killed.

– Why Projects Fail presentation, slide 6

But what happens when your problems are bigger than just one project? What happens when you’ve got a team, a department, or a whole organization that runs into trouble repeatedly on projects?

When Jenny and I were doing research for our first book, Applied Software Project Management (O’Reilly, 2005), we talked to many different people on all kinds of teams. And when we did, we started to notice something funny. We specifically reached out to people who had bad experiences with requirements, project management, Agile development—really, any way of trying to do things better. We were surprised that we kept hearing the same things over and over again, and started to suspect that they were symptoms of deep-rooted project management problems… and teams that were resistant to changing them.

Taking the first step

A list of the most common excuses—excuses that we’ve heard dozens or even hundreds of times, over and over again, from many different teams—is a surprisingly powerful tool. There have been many times when I’ve been brought in to try to help a team improve the way they build software. I’d be in the middle of an explanation of, say, why Agile has worked well for me in the past, and someone would give me an excuse that’s almost exactly word-for-word right out of our book. It’s actually pretty uncanny: how were we able to predict exactly what he would say in advance? But there it is, written down and printed in black and white.

That was the inspiration for the chapter in our book called Understanding Change. In it, we outline the most common excuses for sticking with a poor way of building software and not adopting something better. If you’ve ever tried to help your software team adopt a new tool, technique, or practice, you’ll see some very familiar arguments there.

Here are the top excuses that we’ve heard from teams that can’t admit that they have a problem. They’re all straight out of Applied Software Project Management. Treat each of these excuses as a big red flag, and you can use this to your advantage. If you’ve ever watched an episode of Intervention, you probably know that the first step to fixing a serious issue is admitting that you have a problem. Do they sound familiar to you? Have you ever heard any of them before? If so, it’s time to take the first step.

But if you do take the step and admit that you have project problems, that’s good news! It means that there are plenty of time-tested, tried-and-true ways to help your team. (Of course, if you’re a regular reader of Building Better Software, you already know that!)

Each of the following excuses is excerpted from pages 206 through 213 of Applied Software Project Management (Stellman A and Greene J, O’Reilly 2005). You can read a lot more about each one (and what you can do when you hear them from your team) in that chapter.

We Already Build Software Well

Denial is a common response to change. You may have identified a glaring problem, but people around you fail to even recognize it (or simply refuse to acknowledge it). Many professional software engineers and managers have never experienced a project that did not have enormous delays and serious problems; it’s often assumed that this is just part of how software is built. After all, they usually delivered something—most projects were eventually completed, and the software they built is now being used. Sure, some projects seem to always be eternally 90% done (with 90% left to go), but most of them seem to get something onto the users’ desktops (although many patches and bug fixes needed to be rolled out afterward). Isn’t that good enough?

“Not Invented Here” Syndrome

“Not Invented Here” syndrome (NIH syndrome) is a name given to a common type of organizational culture where people intentionally avoid research or innovations that were not developed within the organization. When faced with a problem, the people in the organization will typically reject a solution that is known to have worked elsewhere in the industry, solely on the grounds that it did not originate from inside the organization. They opt instead to build their own solution, often at far greater cost.

It’s “Too Theoretical”

When an idea does not make intuitive sense, many people will dismiss it as a result of “academic research,” which could not possibly apply to the world they live in. For example, to someone without a project management or software  engineering background, it may not be immediately obvious that reviews reduce defects, or that it’s important to write a specification before building software. To him, these procedures are time-consuming, with no obvious benefit. They sound good in a book, but would never work in the organization. In other words, they are “too theoretical.”

It Just Adds More Bureaucracy

An especially damaging attitude in some organizations holds that programming is the only important activity in a software project. Project management tools and techniques are seen as distractions that drain energy and effort away from the programmers’ “real job” of writing code. Any project activity that takes place before the programmers begin writing code simply amounts to “spinning our wheels,” and the goal of all early project activities should be to get the programmers doing the “real work” as quickly as possible.

You Can’t Give Me More Work!

Most of the changes that a project manager makes will increase the workload of other people. Software engineers, managers, and stakeholders who were not directly involved in building software will suddenly find themselves expected to attend status and review meetings, participate in planning and estimation activities, work with someone creating a vision and scope document or eliciting requirements, or perform other tasks that were never expected of them before. If you are making these changes, then you are the person piling additional work onto someone’s already overflowing plate. Not surprisingly, there are people who will not be happy with this arrangement.

It’s Too Risky

The economist John Maynard Keynes once wrote, “Worldly wisdom teaches that it is better for the reputation to fail conventionally than to succeed unconventionally.“ Legendary investor Warren Buffett put it this way: “Lemmings as a class may be derided but never does an individual lemming get criticized.” In other words, any manager who backs a change puts his reputation on the line; if that manager does nothing, he will not be criticized for maintaining the status quo.

The other day I made this short, shameful confession in response to a Slashdot story about a Forbes blog post called When Smart People are Bad Employees. The post outlines three distinct types of bad employees. The third one was called “The Jerk,” and it sounded eerily familiar:

If a member of your staff is a raging jerk, it may be impossible. Some people are so belligerent in their communication style that people just stop talking when they are in the room. If every time anyone brings up an issue with the marketing organization, the VP of marketing jumps down their throat, then guess what topic will never come up? This behavior can become so bad that nobody brings up any topic when the jerk is in the room.

Here’s my confession: I’ve been that jerk in the past.

I was that really smart programmer that everyone listened to because I made really good software really quickly. But people hated dealing with me because I was obnoxious to deal with—and worse, I knew it and was openly arrogant about it. If snarky geek t-shirts had been around at the time (this was back in the mid-90s) I would definitely have worn them. When someone was wrong, I definitely let them know. If I didn’t respect someone, I would make myself unpleasant to deal with, enough so that it was easiest to just shut up anytime I was in the room.

I was a kid in my early 20s, and it was only my second job out of college, so I was really eager to prove myself. I came up with some pretty ingenious solutions to a couple of vexing problems. It was a small company, and one of the systems I built produced an entirely new product for their salespeople to sell to clients. They had some serious problems managing client information for their help desk, serious problems where their programming team wasn’t able to track bugs properly (these were the days well before tools like JIRA and Bugzilla were cheap or free), and managing large amounts of data. I built some pretty good tools, and they made a big difference. So people put up with my attitude, because it was a net win for everyone. But it made their jobs more difficult, just so I could engage in some personal ego gratification.

Actually, here’s something from that time that I find really funny. The company I was working for had all prospective employees take a Caliper Assessment test as part of the interview process. At the time, it was basically a combination of an IQ  (abstract reasoning) test and a personality profile, and the results were compiled into a report with a page of scores and a two-page writeup. My boss gave me a copy of my results when I came on board. My abstract reasoning score was 100%, and scores on the “extroverted” and “ego-driven” scales were both over 90%. The writeup said that I would be “a loose cannon,” but if I was “aimed properly, I would knock down any barrier in front of me.” It also warned that I would not play nice with people who I did not respect.

In other words, the Caliper report certified me as an extremely smart, highly capable, grade-A jerk.

So, first of all, kudos to the folks at Caliper. They definitely had my number, which was pretty impressive considering that it was based on a 100-or-so-question fill-in-the-bubble timed test. And they got that profile exactly right.

This all presented a really frustrating problem for the people at the company. Here I was, this kid who kept hitting projects out of the park. But I was truly impossible to deal with. I would barely let people finish sentences before cutting them off (“Okay, I know exactly what you want. You go away now.”) I perfected all of the programmer stonewalling tricks to get people to stop asking me questions: interrupting people with pedantic questions before they’d barely started getting to the point, sending people back with half-answers so I didn’t have to think through the question I was being asked, answering questions in a way that was obviously far too technical for whoever I was talking to so. And heaven help anyone who said something to me that was technically inaccurate.

I was belligerent to people around me. I was definitely immature and naïve. But people respected me and knew that I was worth dealing with, because I did really good work.

Eventually, though, a funny thing happened.

I slowly discovered that if I stopped acting like a jerk, life got a lot easier. I mean, obviously, it got easier for the people around me. But it got easier for me, too.

Unthinkingly, I felt that I needed to be a jerk to make people respect me. I think, on an intuitive level, that it was a kind of litmus test. People had to respect me, because if they didn’t respect me they never would have put up with my attitude. But what I found was that when I stopped acting like a jerk, people still respected me. Not only did they stop fighting me, but they actually went out of their way to help me.

Once I stopped being a jerk, it was a lot easier to do my job, and I’m convinced that I was actually able to produce better code because of the reduced number of bureaucratic headaches.

I wish I’d figured it out earlier.

(Hmm, on the other hand, I was asked to do more stuff because people were less afraid of me. So I guess… be careful what you wish for?)

Apparently I’ve earned the dubious distinction of having become an expert in project failure. I’ve always had an interest in project failure—Jenny and I have been doing our “Why Projects Fail” talk for years now, and we’ve talked to many people in many different industries (like in our fourth book, Beautiful Teams) about what’s gone wrong on their projects. We’ve looked at failures on projects through the years, from small misfires on our own projects to dramatic failures like the Tacoma Narrows Bridge disaster, to try to figure out what software developers can learn from them.

One of my favorite ways that projects can fail is death by micromanagement. It’s a nasty, insidious problem for a couple of reasons. It’s easy for a boss to fall into the micromanagement trap, especially for a project that’s starting to spiral out of control, because when you feel like your project is slipping away from you, it’s hard to resist the urge to tighten your grip on every part of it that you can.

And the people on the team have trouble recognizing it because a lot of them have never worked any other way. I’ve said it before, and I’m sure I’ll say it again: I’m willing to bet that if someone was able to conduct an accurate survey, they would find that a surprisingly large number of managers are micromanagers.

On the other hand, if you’re a boss or a project manager looking for a great way to demoralize your team and cause your projects to fail, micromanagement is a great way to do it. Here are some handy tips to make sure your team hates you and your project runs into serious trouble:

• Make sure you don’t give your team enough time to do the work, and then blame them for not getting it done on time.
• Routinely ask people to stop working on whatever they’re doing right now to take care of urgent emergency work.
• Then utterly fail to follow up on that urgent emergency work.
• Never let anyone on your team release anything or even talk to a user without giving it to you to look over first.
• When they give you that work, make sure you send it back with a whole lot of vague and poorly thought-out changes – but make sure you don’t give any extra time to make them.
• In fact, try to constantly find many small changes that your team should make, just to keep them on their toes.
• Your team needs constant attention! If it’s been more than two hours since you’ve talked to someone on your team, drop by and tap one of them on the shoulder and ask for an update.
• All organizations run on status. If the status updates stop flowing, a company can crumble and perish! Also, developers feel lonely if they haven’t given a status update in the last few hours. So make sure everyone has to fill out elaborate status reports, and make sure you hold at least three two-hour-long status meetings every week.
• Did someone on your team do something differently than how you would do it? Reprimand them! They might tell you that it works just fine, and that their way is just as good. But it’s not your way, so it’s not right.
• Remember: reading your mind is part of every team member’s job. That’s how they stay proactive!

Most of all, though, remember rule #1: Nobody is ever allowed to make mistakes! If a developer makes a mistake, it reflects badly on you, and the whole team suffers. Never admit that you were wrong about anything. If you said it once, it’s now the law and should never be questioned.

If you follow this simple advice, then your team will be demoralized in no time. Also, they’ll hate you. Oddly, though, there’s a good chance that they won’t get their resumes together and start looking for new jobs. I have a theory about this: when you micromanage a team, it drains their will to such an extent that they no longer care. Psychologists call this state “learned helplessness.”  The Wikipedia article on learned helplessness has a good description of a classic experiment by Martin Seligman and Steve Maier:

In part one of Seligman and Steve Maier‘s experiment, three groups of dogs were placed in harnesses. Group One dogs were simply put in the harnesses for a period of time and later released. Groups Two and Three consisted of “yoked pairs.” A dog in Group 2 would be intentionally subjected to pain by being given electric shocks, which the dog could end by pressing a lever. A Group 3 dog was wired in parallel with a Group 2 dog, receiving shocks of identical intensity and duration, but his lever didn’t stop the electric shocks. To a dog in Group 3, it seemed that the shock ended at random, because it was his paired dog in Group 2 that was causing it to stop. For Group 3 dogs, the shock was apparently “inescapable.” Group 1 and Group 2 dogs quickly recovered from the experience, but Group 3 dogs learned to be helpless, and exhibited symptoms similar to chronic clinical depression.

In part two of the Seligman and Maier experiment, these three groups of dogs were tested in a shuttle-box apparatus, in which the dogs could escape electric shocks by jumping over a low partition. For the most part, the Group 3 dogs, who had previously “learned” that nothing they did had any effect on the shocks, simply lay down passively and whined. Even though they could have easily escaped the shocks, the dogs didn’t try.

If reading about the Group 3 dogs reminds you of work, then there’s a very good chance that you’re being micromanaged.

About a year ago at a conference, a programmer came up to me for some advice about an unfortunate user interface he’d built. It was a pretty miserable affair: a combination of displaying too much information and offering too many choices, while at the same time burying the one thing that the user actually wanted to work with. It was full of classic UX – user experience – mistakes and usability problem, and I suggested the usual suspects: go back to user stories, develop some use cases, try to figure out what the users actually need.

That did not go over well. I’d assumed that the programmer was still working on gathering feedback, since he was asking me to look over his design. So I was surprised when he mentioned that it would be difficult to make changes to it, because it had already been rolled out and his users were using it.

That’s when I decided that this was a devious supervillian who secretly hated his users. Or, possibly, just a thoughtless jerk—I couldn’t really decide for certain without seeing his secret lair. (Hint: If he has a secret lair, it’s probably the former.)

My point is that if he did hate his users, then inflicting bad UX on them was a perfect way to make them really miserable.

You can’t just add usability at the end of the project

You’d be surprised at how often programmers are completely unaware that they have serious UX and usability problems. Just a few days ago, someone told me, “Our users are using our software, so we don’t have any usability issues!”

One of my favorite sayings is that there are only a few ways to do something right, but a million ways to do it wrong. Usability is no exception. And one problem with user experience and usability is that it’s not always easy to diagnose UX problems in software that you wrote. Good UX is designed in from the beginning; bad UX can show up at any point along your project.

That’s why an approach that I like for fixing usability problems is to concentrate on the team, not just the software. Here are a few quick questions to ask yourself. If any of these situations sound familiar, you might have usability problems:

• A user is explaining what he needs you to build. Halfway through a sentence, you stop him and say, “That’s great! I know exactly what you need.”
• The first thing you did on your new project was start up the form or page designer in an IDE and drag controls onto a window—before talking to any of the users.
• You’ve gotten halfway thorough a project without knowing the name of anyone outside of the programming team who’s going to use the software.
• When you deliver the first version of the software for users to test, it’s the first time they’ve seen the GUI.
• You find out that there’s an entire feature that your users aren’t using… or a feature they don’t even know about.

If any of that sounds familiar—or, even worse, if you’re now pissed off at me because you don’t see what’s wrong with any of those scenarios—then you should definitely consider getting some UX help right now. (I’d offer to help you myself, but I’ve got my hands full with my own projects!)

One of these days I’m going to start an organization called PeTU: Programmers for the Ethical Treatment of Users. We’ll set up a protest outside the office of any development team that inflicts bad usability on their unsuspecting users. For the sake of all our sanity, please stop inflicting bad UI on unsuspecting users! If you don’t, I’ll have to stage an outlandish, somewhat juvenile protest outside your office.

Why you should care about project management

I’ve had a lot of developers over the years tell me outright that they think project management is stupid.

Some of the best developers I’ve worked with had pretty negative opinions of project management. At best, they’d say something like, “Well, that sounds good for another team, especially a really big team, but our projects run just fine without the extra overhead.” At worst, they think it’s malignant bureaucracy imposed on them by pointy-haired bosses. One bad experience can sour a good developer on project management. And that’s pretty unfortunate, because good project management can make a developer’s life a lot easier.

So why should a developer care about project management? I think the answer is in the Why Projects Fail talk that Jenny and I have done many times over the years, where we outline many different ways that projects fail. We got the idea from that presentation because we’ve spent years talking to many different people about the different kinds of project problems. We had to figure out exactly what it means for a project to fail. Obviously, if your project completely crashes and burns, it’s a failure. But the funny thing about a software project is that you can almost always deliver something – even on a project that everyone agrees is a failure, you’ll have code that compiles and runs.

So we came up with this definition of project failure:

• The project costs a lot more than it should
• It takes a lot longer than anyone expected
• The product doesn’t do what it’s supposed to do
• Nobody is happy about it

When we go through these things, we always get a lot of head-nodding, especially from developers. More importantly, we’ve never met a single professional software engineer with more than a few years of experience who hasn’t been on at least one failed project. We always ask for a show of hands to see if there’s anyone who’s never had a failed project. And we’ve yet to meet anyone who has. (We did get someone who raised his hand once, but I talked to him afterwards, and he was just messing with us.)

What does this have to do with project management? Well, everything! Have a look at a typical project management textbook, and you’ll learn about the “triple constraint” (which some people call the “iron triangle”) of scope, time, and cost.

Project management really boils down to managing that triple constraint: balancing the scope of the work to be done, the cost of doing the work, and the time it takes to get the work done, all in order to get the best quality that you can. If you do that right, your project runs well, and your team is happy. If you do it badly, your project stinks, and you end up with a failure. And that’s why you, as a developer, should care.

I’ll go into a little depth about each of those things – scope, time, cost, and quality – just to give you an idea of why you should care about each of them. But the one that developers care about most is scope, so I’ll spend a little more time on that first.

Scope: the work and features that go into the project

Every project can be broken down into a small number (say, ten to twenty) features. For big projects, those features are big (“solid rocket boosters,” “reuse and reentry”); for small projects, those features are small (“holds 12 fluid ounces of liquid,” “screw-top cap”). And similarly, every project can be broken down into a small number of tasks that are needed to build those features. Project managers call the list of features the product scope, and they call the tasks the project scope – and a lot of people just talk about all of it as scope.

I’m consistently amazed by how much work a project team can put into a project without before they realize they’ve got a scope problem. Jenny and I talked about this in our book Applied Software Project Management in the section on scope problems:

A change in the project priorities partway through the project is one of the most frustrating ways that a software project can break down. After the software design and architecture is finalized, the code is under development, the testers have begun their preparation, and the rest of the organization is gearing up to use and support the software, a stakeholder “discovers” that an important feature is not being developed. This, in turn, wreaks havoc on the project schedules, causing the team to miss important deadlines as they frantically try to go back and hammer the new feature in.

Applied Software Project Management, p31

Does that sound familiar? If so, talking about the scope earlier in the project can really help. One way to help fix this is to put together a Vision and Scope document. It’s a really simple document, usually only a page or two, but it can really help prevent scope problems. It’s also a staple of project management. Once in a while, I’m pulled into a project that’s been running into trouble. I’ll spend a few hours talking to each of the team members, managers, and anyone else I can find who knows something about the project or needs it done. I’ll throw together a quick vision and scope document, and what I’ll often find is everyone had very different ideas of what would actually get built. And it’s usually a big relief, because everyone – especially the lead developers! – realizes that they were going down a path that would have had them waste a lot of time building the wrong software.

(source: Head First PMP, 1st ed., O’Reilly 2007)

Faster, better, cheaper—choose two… right?

There’s a whole lot more that I’m tempted to write about managing time, cost, and scope in order to get to the right quality level, but I really want to pare this down to the basics. There’s an old (and somewhat cynical) project management saying: “faster, cheaper, better: pick two.” What it means is that there’s no way to reduce cost, shorten the schedule, and increase quality all at the same time. At least one of those things absolutely has to give.

But there’s a reason that’s a saying and not a law! All three of those constraints are related to each other, and there’s almost never an easy, obvious trade-off where you can sacrifice one to improve the other two. If there were, project management would be a lot easier. It’s really easy to fall into a trap of trying to do the impossible, but the first step in avoiding a trap is knowing that it’s there. In this case, just knowing that every project is a balancing act between scope, time, and cost is a really good first step in making sure your project ends up running well.

I wanted to leave you with just a couple of thoughts:

• One thing that makes the “time” aspect of project management tricky is that developers really hate giving estimates – or, more specifically, they hate giving estimates because they know they’ll be misinterpreted as hard commitments. I wrote a blog post about this a while back (The Perils of a Schedule) .
• Every project needs a start, middle, and end. My old friend Scott Berkun writes about this beautifully in his book, Making Things Happen.
• Cost doesn’t have to mean dollars – it’s often more effective to measure cost in hours.
• Burndown charts really help, because they can make the cost seem real.
• Sometimes the word “quality” makes developers a little nervous, because they start to think that improving quality just means doing endless testing. Sometimes it helps to replace a phrase like “high-quality software” with “software that we can be proud of.”

Tough Programmer Interview Questions: Project Management

Programmers are often surprised when a job interview shifts from technical questions to questions about project management. I just saw a great example of this in a recent Head First C# forum post:

This is a lot more common that developers realize. I’ve seen a lot of discussion lately about how to do effective programmer job searching, especially for relatively new developers who have three years of experience or less. Did you ever ace the tech part of an interview, only to find that you didn’t get the job? I bet that a lot of the time it comes down to questions that seem peripheral or less relevant – to the a junior developer.

Not to a lot of senior developers. That’s one of the biggest differences in attitude that I’ve seen between people who are new to development and people who have been doing it for a long time. And in a lot of cases, I think it really does come down to attitude. So my goal with this post is to outline the basics of project management, the core things that really matter.

Why should you care about project management?

There’s a flip side to project management, too. A colleague of mine once asked me, “What’s the most important part of project management?” I told him that it’s managing stakeholder expectations – making sure that the people who have control of the project or are affected by it are in the loop on all the important developments as the project rolls along. If bad things happen, they know about them in advance, and are prepared. The reason for this is that some projects fail (more than you think!), often for reasons that have nothing to do with the team. If you manage everyone’s expectations, get them on the team’s side, then the developers can come out as heroes fighting a lost cause. On the other hand, a project can be a roaring success, but if everyone expects something that’s not exactly what was delivered, the developers could be blamed for something that they had no control over. Expectations matter, communication matters, and these things can have a big impact on the project and the team.

And that’s why developers should care about project management: it affects your life, even when your job is to keep your nose buried in code all day.

A lot of developers have a very poor opinion of project management and project managers. I’ve spent a lot of my career writing books and giving training to help project managers improve their skills. Over the years, I’ve met many different types of project managers. And, unfortunately, while there are plenty of great ones out there, there are a lot of really bad ones as well. In any field, there is a wide range of skill level and aptitude. If you’re a developer who’s only ever worked with poor project managers, it’s not surprising if you ended up with a dim view of the project management as a whole.

But even if you’re a developer who doesn’t have a high opinion of the field, you should at least acknowledge that learning more about it can have an impact on your own career. I’ve personally seen employers pass on good developers who didn’t know enough about project management, even ones who had the technical skills to do the job.

I’ve also conducted a lot of developer interviews, easily several hundred of them over the last decade. And one thing that I’ve noticed is that really good developers have a healthy respect for exactly the same things that really good project managers care about: the work and the features needed to create the software, the team that crafts it, the effort required to build it, and the quality of the final product. That’s why I think that learning more about project management can help make you a better developer.

In the next part of this post, I’ll outline those things, and make a case for why they should matter to you.

I’ve got an announcement about a really exciting event. From August 18 to 24, I’ll be leading a discussion in this forum for the a special O’Reilly Community event on the Head First C# forum. Please join me there! Bring any questions you’ve got about C#, becoming a better developer, running your projects, managing your career, or building better software.

Here’s more information from the event page, where you can sign up for the event:

Andrew Stellman on C#

Date: Aug 18-24, 2010

Led by: Andrew Stellman

If you’re serious about learning C#, join Andrew Stellman, author of Head First C#, as he discusses the nuances of C# 4.0, Visual Studio 2010 and .NET 4.

Andrew explores topics such as:

• Why use C# instead of any other language?
• C# Best Practices
• Becoming a better C# developer
• Dealing with objects
• Productivity Hints
• The Best of C#

What is The Inner Circle?

The Inner Circle: The O’Reilly Book Club for Geeks is an online weeklong discussion forum where passionate technologists can connect with featured O’Reilly authors.

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.