Johanna Rothman

Overloaded operators exist when an operator or operation has different meanings in different contexts. This usually applies to variables and sets, but it can be true for people, too. These people try to do the work of many different roles—and usually fail. If you have an overloaded people operator, analyze the work and try to divide it up.

The #NoEstimates movement isn't really about no estimates. It’s about working in a sufficiently agile way that you don’t need estimates. When you break down your work into smaller chunks, you provide more value by delivering working product than you do by estimating. What would it take for you to work that way?

If you are agile, you might spend some time estimating. If you’re using Scrum, you estimate what you can do in an iteration so you can meet your “commitment.” But estimation is a problem for many agile projects. The larger the effort, the more difficult it is to estimate. You can’t depend on ideal days. Do your estimates provide value? To whom?

When it comes to transitioning to agile, if a team only goes off what it's heard from other teams and doesn't take a class or read any books about the process, misconceptions can abound. And that leads to problems. Read on to have three common agile myths debunked and to learn why agile is a cultural change, not just a project management framework.

Many teams think they're agile. They might work in iterations and have a ranked backlog, but they don’t see the value they could be seeing. Usually that means they have a number of false impressions about agile. Read on to have three common misconceptions debunked and to learn what you need to do to make your agile transition successful.

An employee may become indispensable through arrogance or happenstance. These employees can cause bottlenecks and often prevent others, as well as themselves, from learning and growing professionally. "Firing" these indispensable employees sets your team free to work even when the expert is not available.

Competition between teams does not improve performance. In fact, the added stress may shift team members' focus from creating a quality product to self-preservation due to fear of failure. Johanna suggests managers emphasize collaboration between teams over competition.

Do your managers truly own their decision making or are they only "empowered" to come to you for approval of every idea and dollar spent? If you don't trust your team leaders to make decisions, how can you expect stakeholders to? Setting boundaries and defining expectations are two ways to empower managers and encourage initiative, giving them the opportunity to gain your trust.

A new approach to projects or a new tool is not a quick fix or a silver bullet. Too often, you have ingrained, systemic problems that require a cultural change. That doesn’t mean a new approach or a new tool won’t help. It can. But you also need to adjust the environment that caused the problems in the first place.

It is unfortunate that the department attending to employees is called “Human Resources.” That language colors what managers call people in the organization. But the more you call people “resources,” the more they become interchangeable—and more like desks, or infrastructure, or something that is easily negotiable. Resources are not people. People are not resources.

"Don't bring me problems; bring me solutions." Sound familiar? Sounds like a management cop out to Johanna Rothman. A primary purpose of managers is to help their teams perform to the best of their abilities, and that includes stepping up and making tough decisions to help solve problems.

Just because you have a fancy job title doesn't mean you can manage your team members by bossing them around. Servant leadership is an important skill for managers, as the best managers are those who serve the people who work for them.

How do you estimate work you've never done before? One proven method is to spike it: Timebox a little work, do some research—just enough to know how long it will take to finish the rest of the work—and then you can estimate the rest of the work. You don’t waste time, you can explore different avenues of how best to complete the task, and your team learns together.

Busy managers get used to making decisions on the fly. But, some decisions require more thought and consideration than others. Johanna offers some tips for knowing when you need to slow down, take a seat, and give a problem your undivided attention.

Johanna Rothman writes that organization-wide standards don’t help if management imposes them. If people ask for help with standards, then you can provide local help to each team. And if the teams are part of a program where you have one business objective common to multiple projects, make sure the program understands the problem.

Hiring is difficult to do well, Johanna Rothman writes in her latest management myth piece. Because everyone who is looking to hire has a job, they think they know how to hire. But it’s not easy. You want to hire the best people you can who fit the team and the organization.

Johanna Rothman explains the challenges and pitfalls of micromanagement. Sometimes, managers micromanage when they need information. In that case, it’s easier to create an information radiator rather than have the manager come running to you every thirty minutes.

Everyone needs feedback about their work. If you’ve done something great, you need to know—sooner rather than later. And if you’ve done something that wasn’t great, you need to know that, too. But people don’t need to be stack-ranked against each other. That doesn’t provide people any information about how they perform their jobs.

When you’re the manager, always make sure you know who performed the work, and make sure other people know, too. People want to know you appreciate them. They want to know you are willing to carry that appreciation up the corporate ladder. More importantly, they want to know you are not a jerk who will take credit for the work they perform.

In her latest management myth piece, Johanna Rothman writes that your management position, first-line or not, is about building trusting relationships. If you start managing more than nine people, you are in danger of not being able to build those relationships.

Johanna Rothman gives the rundown on what exactly is agile. Remember, agile is not just an approach. It is a system and a cultural change to your organization. Agile creates high visibility and transparency in the projects, which permeates the entire organization.

Some managers who have not been technical in a while have forgotten—or may never have known—that software product development is about learning. They may have spent all of their learning time at a keyboard. Especially if they learned alone rather than in teams, they would not know how to assess a team member’s need for alone time after intense team time.

Johanna Rothman bucks conventional wisdom and writes that it's not always cheaper to hire workers from places where the wages are less expensive. When you have fractions of teams in remote places, you could have communication problems and other issues that will increase the cost for every feature.

Johanna Rothman explains that you cannot measure what people do and expect that measure to be useful. Why? Because software is a team sport, and everything we do depends on other people.

Johanna Rothman explains that management work is work, even if it appears that what managers mostly do is run from meeting to meeting. Management work is all about facilitating the work of other people, and when you perform great management, your team can create great products.

It’s impossible to please everyone in an organization. If someone comes to you with a reasonable-sounding request, such as to move a tester or a developer to a project, you need to examine whether the request is actually so reasonable. Management is not about being nice to everyone all the time. Much of management is about saying no when you have to. Johanna Rothman gives you some advice.

Everyone wants to be helpful, and that includes managers, middle managers, and senior managers. But the more managers interfere with a team’s growth, the less a team learns how to perform. Managers do not have to solve a team’s problems.

The longer a manager has been away from technical work, the less the manager still knows the technical details. And—as we all know—for software, the details matter. If you have a manager who insinuates himself into your work, ask that manager what he wants. As long as managers trust in their project teams, and as long as those project teams work to earn trust, both sides can work together.

When you force people to timebox their work to just the workday, they start making choices about the work they do and don’t do. They stop doing time-wasting work. They start doing useful work, and they start collaborating. But, only if you stop interfering.

Some managers have rules about problems. Some managers think they should be able to have an answer to every problem. While you don't have to know the answers, being an effective and competent manager means that you can facilitate a way to get to the answers.

Managers are people, too. They have bad-manager days. And, even on good-manager days, they can show doubt, weakness, and uncertainty. They can be vulnerable. Managers are not omnipotent. That’s why it’s critical for a manager to admit a mistake immediately.

Johanna Rothman shares some of her highlights of the past year, which has been her first full year as the technical editor for the Agile Journal, now called Agile Connection.

Managing requires a different skill set from technical work, yet many companies promote their best technical workers to management positions. Here are some things to consider when it's time to promote your technical workers.

If you have a cheerleading manager (or, worse, if you are a cheerleading manager) in a troubled organization, then your team is likely missing its purpose. Replace those cheers with transparency, and you might be surprised by the solutions your team will come up with.

Increasing the amount of time someone spends on work does not directly result in better work. In fact, depending on the person, the opposite may be the case—spending less time at the office may improve the results. Johanna tackles myths of measuring work by time.

It’s never easy to schedule training, but you must if you want the people you manage to learn a new language, tool, or skill. Johanna offers some tips for making time and capitalizing on curiosity.

The temptation can be incredibly strong for managers—especially new ones—to step in when a technical problem arises. But, that isn’t a very good show of faith in one’s team members. Johanna Rothman writes that as a manager, you have to delegate a problem and leave it delegated.

Johanna Rothman writes on how she facilitated a project management clinic in which she overheard this statement: "We have a product owner who persists in changing the contents of the sprint during the sprint. This is difficult for us. It costs us to change the content." To Johanna, this is a huge pain and it is similar to multitasking.

There's a common myth among managers—that they are the only drivers and decision makers for their teams and, therefore, can't take time off. In reality, regardless of the team or workgroup you manage, your team makes decisions without you all the time.

Regarding project portfolios, it can be a big problem for clients to see all the work. Some clients have multiple kinds of projects, so they want to show their work in a variety of ways. Johanna Rothman describes some helpful ways to display the work being done.

I wrote the first of a three-part series about looking at culture when you hire people last month. I posted that Pragmatic Manager, Your Culture: What is Okay for You to Discuss? and forgot to tell you. If you are on my email list, you received today’s Pragmatic Manager about what the organization values and rewards. Next up is how people treat each other.

Not every employee is salvageable, and it’s almost always a case of cultural fit. If you’ve provided honest and open feedback and the employee can’t or won’t change, it’s up to the manager, or the self-managing team, to help the employee move on.

An objective ranking system is unnecessary when trying to determine an employee's value, and it can even be detrimental to collaboration on teams. Providing feedback, facilitating knowledge building, and allowing them to contribute are three key ways to help your employees excel in their roles.

My most recent post, We Cannot Choose Between Management And Leadership, has struck a chord. That’s the good news. The bad news is I have not defined enough terms. Okay, I’ll attempt that now. And, thank you, gentle readers, for hanging in there with me, waiting for my crazy travel schedule this spring.

I see these managers in the organization:

I subscribe to a number of services that look for pithy quotes from Big Names, authors, and other people who are looking for publicity. I saw one about moving from manager to leader.

I’ve had a confusing couple of weeks. First, a nice gentleman who was considering my job search book (in beta) told me he was seeing potential virus notifications on Hiring Technical People. Well, that seemed strange. But, then another colleague who’d participated in my Peer Project Portfolio Coaching also saw the notifications.

Once you have a program—a collection of interrelated projects focused on one business goal—and you have technical debt, you have a much bigger problem. Not just because the technical debt is likely bigger. Not just because you have more people. But because you also geographically distributed teams, and those teams are almost always separated by function and time zone.

One-on-ones aren’t for status reports. They aren’t just for knowing all the projects. They are for feedback and coaching, and meta-feedback and meta-coaching, and for fine-tuning the organization. If you are a manager and you aren’t using one-on-ones, you are not using the most important management tool you have.

I’ve been talking to people whose management cares about their velocity. “My management wants us to double our velocity.” Or, “My management wants us to do more in a sprint.” Or, “My management wants to know when we will be a hyper-performing team, so they want to know when we will get 12x velocity like Scrum promised.” But let’s understand what management really wants.

I have a tough time with my perfection rules. I want to be perfect. I’m not, of course. I want to be. So using leanpub and publishing early and often pushes me way out of my comfort zone. Which is why you haven’t heard anything from me about my book under development up until now. Yesterday, I announced the beta of my newest book Manage Your Job Search: Reduce Your Overwhelm, Focus Your Search, and Get Your Next Job!

I’ve had several conversations in email and with clients recently that have all been about this question: “What do we do about our infrastructure?” Either the project or the program has to create/update/upgraded their architecture or automated test infrastructure, pay down technical debt, or somehow do something that’s not part of a story.

A few weeks ago, Peter Armstrong interviewed me for Leanpub, to ask me why I enjoyed writing on Leanpub. That podcast is up now on the Leanpub Buzz page.

What’s very funny is that the interview is a few weeks old. I had no idea he was going to post it right after I wrote Dear Author. About 11 minutes in, I talk about the boring trap, the passive voice trap in my own writing. I think this is pretty funny.

One of the biggest management myths is, “I must treat everyone the same way.” Nothing could be further from the truth. Everyone has different goals for their career, and those change over the course of a career.

As a consultant, I want the flexibility to adapt my work to take advantage of opportunities that might arise in a given week–to write an article or blog post, or to propose a project to a new client.  And, while I try to plan a week’s worth work, I need the flexibility to adapt my work on the fly. I work in small chunks, finishing work. I like seeing completed work. I have a great sense of accomplishment when I see completed work.

I’m tech-editing an article for the Agile Journal. I’m having a discussion with the author about the words “productivity” and “throughput.”

I believe that what we measure in agile teams is throughput, the number of features through the team over time. I don’t think we measure productivity, the number of features per person or per team over time.

In kanban, it’s quite clear. We measure throughput. To me, it’s clear in iterations, too. We measure throughput.

I just posted Managing Timezones in Geographically Distributed Agile Teams. I have a funny story to tell about it. I’m in Belgium, getting ready for Belgium Testing Days. This weekend, the US changes to Daylight Savings Time. But Europe doesn’t. So, when do I talk to my husband?

How many times have you seen this in your projects: You need something specific done such as a new database, or a specific user interface designed, or you need a release engineer, or a user interface designer, or a part of the system tested and the normal person who does that work is not available? What happens on your project? Does it wait until The Expert is available?

Yves Hanoulle has edited a book, called Who Is Agile? I love this book because of all the back-stories, the pictures, and the links. And, oh my goodness, the links.

I hope that by now you see that you have any number of choices for your lifecycle if you are geographically distributed team and you are transitioning to agile. I do recommend a servant leader agile project manager, for coordination and risk management. With people all over the world, it’s difficult to coordinate the project, which leads to more risk.

In this case study of a distributed agile team, the developers were in Cambridge, MA, the product owners were in San Francisco, the testers were in Bangalore, and the project manager was always flying somewhere, because the project manager was shared among several projects. The developers knew about timeboxed iterations, so they used timeboxes. Senior management had made the decision to fire all the local testers and buy cheaper tester time over the developers’ objections and move the testing to Bangalore.

A Scrum Master has only allegiance to the team. A project manager has responsibility to the team and to the organization. That means that the project manager might feel torn when the organization pressures the project manager to do something stupid. 

This is a product development organization with developers in Italy, testers in India, more developers in New York, product owners and project managers in California.

This organization first tried iterations, but the team could never get to done. The problem was that the stories were too large. Normally I suggest smaller iterations, but one of the developers suggested they move to kanban.

I posted my most recent Pragmatic Manager: Are Your “Shoulds” Driving Your Decisions?

If you missed my most recent Pragmatic Manager newsletter, Focus on One Thing at a Time, it’s posted. In it, the author ranted about the delays of multitasking and introduced a new service: Peer Project Portfolio Coaching.

Too many managers believe in the myth of 100% utilization—the belief that every single technical person must be fully utilized every single minute of every single day. The problem with this myth is that there is no time for innovation, no time for serendipitous thinking, no time for exploration, and it often leads to a less successful organization.

The nice folks at getabstract like Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects. Some of the takeaways they highlight are:

To continue our story from part 1 and part 2…

Let’s set the context (which I did not do in my most recent post–sorry).

I like continuous integration. A lot. I started being an aficionado of continuous integration back in my senior year of university . It was my very first (and last) team project in my college career. There were three of us. The project manager waited until the night before the project was due to get us all together (argh #1). I had completed much of my code several weeks before (argh #2: who can remember what they’d written several weeks ago?). We wrote code madly for hours, and then tried to make it work, starting about 9pm. It didn’t work. We stayed up all night (argh #3).

Matthias Bohlen interviewed me as part of the preparation for the OOP conference. We spoke on a wide range of topics, not just my talk which is “Six Behaviors to Consider When Hiring for an Agile Team.” We spoke briefly about program management, which is why I’m leading my influence tutorial.

I missed one presentation in my last post. At Oredev, I had an opportunity to speak with the PMI Sweden folks (at least, the southern Sweden folks). I talked about Agile Program Management, and discussed my current thinking about agile program management.

I am writing a book about agile program management. I have some portion of the first draft written. I don’t know how much, because I have not had any review. When I write, I can’t tell how much I’ve written until I have my first review. Then I will know how much I have that is good and how much is throw-away. (When I write a book, I have to write enough so my reviewers have enough context to review, but not so much that I’ve gone too far. I find it difficult to know how much to write before review.)

In  many ways, estimating project budgets or dates for agile projects turns out to be irrelevant. If you have a ranked backlog, and you finish features, you can always stop the project if you hit a particular date or cost.

So now that you know why it’s so difficult to estimate what do you do when someone asks you for an estimate?

First, you ask a question back: “What’s most important to you? If it’s 3 weeks before the end of the project, and we haven’t finished all the features and we have ‘too many’ defects, what are you going to say?

Almost every manager I know wants to know when a project will be done. Some managers decree when a project will be done. Some managers think they can decree both the date and the feature set. There is one other tiny small subset, those managers who ask, “When can you finish this set of ranked features?”

It can be tricky for managers and technical leaders to make the transition to agile. They’re likely accustomed to doing things a particular way. What’s more, they may try to squeeze their old ways into the new, agile approach. Here, Johanna Rothman describes why that isn’t a good idea, especially regarding stories that are too big.

Some program managers whose organizations are transitioning to agile are not always clear on which program team they are managing. Sometimes, that’s because the organization doesn’t always realize they need more than one program team.

Israel Gat had a great Agile Cutter Advisor recently, the Friction of Agile (registration required). He discussed the friction of agile going up in geographically distributed teams because of the dis-economies of assimilation (the space-time continuum problem, and the issue of under-funding the infrastructure of the non US-based teams).

Johanna Rothman received a variety of responses to her recent writing on agile architecture. In this article, she attempts to clarify her case for having an architect on some—but not all—agile programs, depending on a number of factors.

Not every organization is prepared to dive into the swift, short iterations of agile, but that doesn’t mean the organization isn’t ready for a change. Johanna Rothman suggests looking to an iterative lifecycle called “release trains” as you begin your journey.

Having similar motivations and processes may help to establish a team, but you and your coworkers won’t be the best teammates you can be until you also have each other’s back. Here, Johanna Rothman and Gil Broza describe valuable approaches to whole-team support, including banking trust and building shared responsibility.

If you are anything like me, you have a to-do list a mile long. Because I work for myself, I have an integrated list of everything I need to do: projects for clients, books to write, articles to write, columns to write, presents to buy, house maintenance, clothes to organize, office cleanup. The list is long and never-ending.

When the data is before you, it's clear to see how agile can improve productivity and time to market. If you're considering a transition to agile but don't know how to make the case to upper management, Johanna Rothman provides you with the data you'll need.

When people begin to get overworked, it's common to fall back on blaming the old chestnut "time management." But the problem may have less to do with how you allocate time to projects than your inability to say no to some of those projects in the first place. In this article, Johanna Rothman takes a look at the difficulty of saying no and offers some suggestions for overcoming it.

If two projects in your organization require specific expertise that only one employee has, what do you do? Projects need to stay on track, but one person certainly can't be everywhere—or even two places—at once. In this column, Johanna Rothman shares a story of an organization stuck in the specialist mindset and offers some tips on how to escape if you're stuck there, too.

If you're working on more than one project at a time or if your managers are asking you to do so, it's time to make some decisions. Not every project should be started or finished, and certainly no one person or team should work on all projects at the same time. The organization needs to make some decisions about whether to commit to a project, kill it so it doesn't interfere with other projects, or transform it so it can succeed in a reasonable time.

Every team transitions to agile in different ways, and this column is one of those stories. But what makes this one different is that the main character, a project manager, is transitioning her team to agile in the middle of a project. From this story, Johanna Rothman details a potential survival guide for any project manager and team embarking on the same journey.

Exploratory testing—questioning and learning about the product as you design and execute tests rather than slavishly following predefined scripts—makes sense for many projects. But does it make sense for agile projects? In this column, Johanna Rothman examines how exploratory testing might work on an agile project.

What happens when project managers of cross-organizational teams don't have all the cross-functional team knowledge, such as testing, they need to manage all the teams? Johanna Rothman explains that managers in this situation might have a recipe for disaster. But with careful planning, any project manager can quickly turn it around and create an efficient team and a career development opportunity for everyone.

Clarify the fuzzy front end of project planning by focusing on the overall vision. In this column, Johanna Rothman says clear project vision helps everyone involved in the project move forward better and more smoothly than a detailed project schedule. She also explains how to write succinct project visions in three simple steps.

There's a vicious game being played daily in the lives of software developers. The rules to this game are not clear cut, and it can change its structure rapidly. If you're not careful, the game will end up controlling your work schedule for quite some time. In this column, Johanna Rothman gives a referee's point of view of this game and reveals the secrets to winning.

Recognizing candidates who are capable of performing well on agile teams doesn't require keyword searches through a stack of resumes. It requires asking candidates questions that allow them to show you they understand the principles and can apply them in their daily work—even if their resume doesn't list particular terms. In this StickyMinds.com column, Johanna gives some excellent tips for the interviewer and the interviewee.

Technical debt can shorten a product's life. But when technical debt mounts, it can be difficult to see how to pay it off. Using the practices discussed in this column, Johanna Rothman explains how you can start paying off that debt—and how to ease the product's development and maintenance for a long time.

Staged integration versus continuous integration—which does your team prefer? Can't decide if one is better than the other? In this column, Johanna Rothman explains that you can create the perfect blend of the two. Developers and testers benefit from frequent builds, but be careful with how much you build. Build too much or too little and a project could topple.

Knowing how much work your group can accomplish—and how much it takes to complete that work—is critical to your success as a manager. Johanna Rothman explains how to ascertain your team's potential and how to use that information to define and manage your project portfolio so it doesn't manage you.

Drawing up a to-do list sounds like a logical starting point when you want to prioritize your workload. But if you have an extra-long list of tasks, the list you should start with is the not-to-do list. Doing so forces you to take an extra hard look at what you're doing and if you should be doing it. Learn more about Johanna Rothman's not-to-do list, how it helps you stay focused on the most important tasks, and how it inevitably helps you maintain your value to the organization.

Testers are always facing a time crunch. As part of a recent assessment, a senior manager asked, "How long should the testing really take? It takes our testers from four, five, six, to thirty (insert your number of choice here) weeks, and we need it to take less time. Why can't it take less time, and how can we tell what's going on so we know how much testing we need?" In this column, Johanna Rothman answers with a timeline. By estimating how many testing cycles will be needed, plus how long each will take, she can map out the entire testing process. From this viewpoint, she is able to pinpoint where the process can be streamlined thus reducing the time spent testing.

Resumes only tell a portion of a candidate's story just like caller ID doesn't always reveal the caller's complete identity. Screening candidates over the phone can help extract more of the person's story if you ask the right questions. In this column, Johanna Rothman shares phone-screening techniques she uses to detect great potential testers. This process of elimination saves her valuable time and ensures only qualified candidates make it to the in-person interview.

Why wait to see your candidate work? Implement an audition into the interviewing process and add dimension to your candidate's resume. In this column, Johanna Rothman discusses how you can increase the effectiveness of an interview by implementing a well-planned audition. Whether this audition takes place over the phone or in person, you'll gather a richer perspective of the candidate's capabilities and how easily the applicant can adapt to your working environment. Put your candidate's words to the test; the results of an audition may break the tie between two superb applicants.

Your test group has an abundance of data but what does it mean to developers, project managers, or senior managers? In this column, Johanna offers a solution for delivering information to all of your customers in one place, that will be as handy as your car's dashboard.

In this corner—A harried project manager whose testing time has just been cut in half. And in this corner—A time-honored management tool to scale back project scope and make testing tasks do-able. Johanna Rothman shows us the ropes of timeboxing and explains why time constraints don't have to be a TKO.

Think working on five projects at once will make great results appear like magic? Don't be so sure. The price your team pays by switching from one project to another could make your productivity disappear. Johanna Rothman reveals the smoke and mirrors behind the illusion of multiprojecting.

Have you ever found yourself stuck in a situation where, no matter what you do, you can't seem to please your senior manager? Your manager wants you to decrease test time, but at what price? You go back and forth, but no matter how much you compress the schedule, it's never enough. Johanna Rothman explains how to avoid the bring-me-a-rock trap, when enough is not enough, and keep your team from being sucked into unreasonable time constraints.

Many managers believe that overtime, even extended overtime is a good thing, and will help a project make progress. However, most technical people who try to work more than two weeks of overtime make huge numbers of mistakes. Often, they don't realize the mistakes and have already wasted a lot of time and money.

"That which we call a rose by any other name would smell as sweet." True, sloppy naming schemes may be all right in some cases. But as Johanna Rothman explains in this column, when software professionals are looking for a job, hiring, or negotiating work assignments, it's crucial for their job titles to accurately portray the work they do. Read on to see if you agree with the definitions Johanna assigns to the more common QA-related job titles.

Project managers may be reluctant, even unwilling, to discuss problems that testers discover in a project. In this week’s column, management expert Johanna Rothman gives tips on how best to tell management that "the sky is falling," and how to respond if they don't want to hear about potential problems before they occur.

You've written the job description. You know just what you want in this employee. You have one tiny problem-you just can't find that person. Now what? Sometimes you can continue to wait for the right person to come along. Sometimes you choose to hire someone with inadequate skills. In either case, you don't have to just hope for the best. You have other proactive choices: hiring from within, hiring a candidate with some skills and training the rest, changing the way you work, and changing the job description.

There's no doubt that the current job market is tight and a little shaky for test professionals. In a climate where entire test groups are being laid off or trimmed to the bone, Johanna Rothman notices a trend in test management priorities that you might want to consider. Follow the story of how one test manager determined tester ROI and how testers might approach increasing their value.

Ms. Dekkers and Ms. Rothman discuss the differences between a test manager's job description, what you really want to do in your job, and what the company pays you to do.

Prompted by a comment from our sticky-minded audience, this week Johanna shares some ways test managers can assess their performance against specific management deliverables likely to be high on an organization's priority list.

"No Fred, we're not considering you for that promotion. You're too valuable where you are." How many of us have heard those words, or said them at least once to our staff? Sometimes, we use the "too valuable" phrase to avoid discussing problems with a staff member, problems you can bring out in the open and manage.

Many of us would like a precise answer to the question: "What's the correct staffing ratio for developers to testers in my product organization?" Usually, though, the only answer is "It depends." Your answer depends on your situation: the kind of project you're working on,
your schedule constraints, the culture you work in, and the quality expectations for the product. This paper discusses the thought process involved in deciding on your correct staffing ratios.

Many test managers came to management through the technical ranks. Although they may have had plenty of testing and/or engineering training and mentoring, they frequently learn management skills the hard way, through trial and error. This article describes some of the lessons Johanna Rothman has learned about managing testing teams.

This paper uses concrete examples to illustrate how to choose the quality priorities for a project. Once the priorities are set, it illustrates how to choose the appropriate project lifecycle.

Most project managers want to reduce risk during a project. One way to reduce overall risk is to define and focus the project goals up front, and continually verify those goals and progress toward those goals during the project.