Skip to content

When team members hate each other

Tuesday, October 27, 2009 - by Andrew Stellman

We don’t always get to choose our teammates, especially at work. So what do you do when you just don’t get along with someone on your team?

What's your point?

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.

Did you like this post? You can help us out by sharing it! These icons link to social bookmarking sites where readers can share and discover new web pages.
  • del.icio.us
  • Digg
  • Reddit
  • Slashdot
  • Technorati
Filed in Teams | Comments (1)

Using nonfunctional requirements to build better software

Saturday, October 3, 2009 - by Andrew Stellman

Understanding nonfunctional requirements — which some people call software quality attributes or nonbehavioral requirements — can make a big difference when you’re building software. But a lot of people have trouble taking a somewhat theoretical idea and applying it to a real-life project. Luckily, we’ve got an easy, practical technique to use nonfunctional requirements on a real software project.

Jeez, lady

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.”
    • Performance index card
  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.)
    • Performance index card (back)

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.

Did you like this post? You can help us out by sharing it! These icons link to social bookmarking sites where readers can share and discover new web pages.
  • del.icio.us
  • Digg
  • Reddit
  • Slashdot
  • Technorati
Filed in Architecture, Quality, Requirements | Comments (1)

What makes architecture “better”?

Tuesday, September 22, 2009 - by Andrew Stellman

I’ve got some news! Jenny and I are going to be doing our Beautiful Teams talk at the upcoming IT Architect Regional Conference. We spoke at last year’s ITARC, and I was really impressed with the quality of their speakers. There were some really good insights into software architecture. It’s a great group, and I definitely recommend it to anyone looking to do a serious deep dive into software architecture.

Better

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.

IASA Speaker 2009

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

Did you like this post? You can help us out by sharing it! These icons link to social bookmarking sites where readers can share and discover new web pages.
  • del.icio.us
  • Digg
  • Reddit
  • Slashdot
  • Technorati
Filed in Architecture | Comments (2)

Agile testing and understanding change

Sunday, August 23, 2009 - by Andrew Stellman

What the...

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:

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!)

Did you like this post? You can help us out by sharing it! These icons link to social bookmarking sites where readers can share and discover new web pages.
  • del.icio.us
  • Digg
  • Reddit
  • Slashdot
  • Technorati
Filed in Agile, News | Comments (1)

The perils of a schedule, part II

Thursday, August 20, 2009 - by Andrew Stellman

In the first part of this post, I started to answer a reader’s question about what information you need before you estimate a project and build a schedule. The reader, Wayne, said that he didn’t “get a solid sense of the relative timing of the activities (especially the requirements activity),” because it wasn’t clear how much information you need to know about the project before you get started. One thing that Jenny and I come back to again and again is that there is no single “best,” one-size-fits-all way of running a project. A schedule is a great tool for planning a project, but you have to actually take a close look at what you know about your project before you start building a schedule. And you need to come to grips with the reality that what you know today could easily change. Even if you have a perfect understanding of today’s needs (which, in reality, never actually happens), that doesn’t mean the world won’t change and your users won’t need different software tomorrow.

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.

That'll light a fire under their asses...

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.

Did you like this post? You can help us out by sharing it! These icons link to social bookmarking sites where readers can share and discover new web pages.
  • del.icio.us
  • Digg
  • Reddit
  • Slashdot
  • Technorati
Filed in Uncategorized | Comments (2)