Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Managing Product Development - Johanna Rothman
Syndicate content
Management, especially good management, is hard to do. This blog is for people who want to think about how they manage people, projects, and risk.
Updated: 9 hours 47 min ago

Manage Your Job Search is Out; You Get the Presents

Wed, 04/09/2014 - 12:28

I am happy to announce that Manage Your Job Search is available on all platforms: electronic and print. And, you get the presents!

For one week, I am running a series of special conference calls to promote the book. Take a look at my celebration page.

I also have special pricing on Hiring Geeks That Fit as a bundle at the Pragmatic Bookshelf, leanpub, and on Amazon. Why? Because you might want to know how great managers hire.

Please do join me on the conference calls. They’ll be short, sweet, and a ton of fun.

Categories: Project Management

Who Solves Which Problems?

Thu, 04/03/2014 - 16:37

Many years ago, I was part of a task force to “standardize” project management at an organization. I suggested we gather some data to see what kinds of projects the client had.

They had short projects, where it was clear what they had to do: 1-3 week projects where 2-4 people could run with the requirements and finish them. They had some of what they called “medium-risk, medium return” projects, where a team or two of people needed anywhere from 3-9 months to work on features that were pretty well defined. But they still needed product managers to keep working with the teams. And, they had the “oh-my-goodness, bet the company” projects and programs. Sometimes, they started with a small team of 2-5 people to do a proof-of-concept for these projects/programs. Then, they staffed those projects or programs with almost everyone. (BTW, this is one of the reasons I wrote Manage It! Your Guide to Modern, Pragmatic Project Management. Because one size approach to each project does not fit all!)

The management team wanted us, the task force, to standardize on one project management approach.

In the face of the data, they relented and agreed it didn’t make sense to standardize.

It made a little sense to have some guidelines for some project governance, although I didn’t buy that. I’ve always preferred deliverable-based milestones and iterative planning. When you do that, when you see project progress in the form of demos and deliverables, you don’t need as much governance.

There are some things that might make sense for a team to standardize on—those are often called team norms. I’m all in favor of team norms. They include what “done” means. I bet you’re in favor of them, too!

But, when someone else tells you what a standard for your work has to be? How does that feel to you?

I don’t mind constraints. Many of us live with schedule constraints. We live with budget constraints. We live with release criteria. In regulated industries, we have a whole set of regulatory constraints. No problem. But how to do the work? I’m in favor of the teams deciding how to do their own work.

That’s the topic of this month’s management myth, Management Myth 28: I Can Standardize How Other People Work.

If you think you should tell other people how to do their work, ask yourself why. What problem are you trying to solve? Is there another way you could solve that problem? What outcome do you desire?

In general, it’s a really good idea for the people who have the problem to solve the problem. As long as they know it’s a problem.

How about you tell the team the outcome you desire, and you let them decide how to do their work?

Categories: Project Management

I’m a Management Expert on Twitter

Wed, 03/19/2014 - 19:20

I’ve just been named to one of the 100 top management experts on Twitter. See Keeping Up with #Management:100 Experts on Twitter. You have to page down under “Executive Coaching” to see me.

I’ll return to editing my “Design Your Agile Project” series now. It needs serious editing. That’s why you haven’t seen the next post yet.

Categories: Project Management

Design Your Agile Project, Part 3

Sat, 03/15/2014 - 19:52

What do you do  for geographically distributed teams, if you want to move to agile?

First question: does the team want to move to agile? Or, does the management want to move to agile? I am serious.

I might take the same actions, but for different different reasons. In either case, the team needs to learn about what agile and lean means, and how to do agile. In both cases, the team needs help and protection from management.

Why Does a Geographically Distributed Team Need Help and Protection from Management? Types of Teams

Types of Teams

Managers create geographically distributed teams for many reasons. Some reasons are that there are smart people all over the world. In that case, managers create feature teams.

When managers create dispersed teams, teams with one and two people in disparate locations in far-flung locations (more than 60 meters away), managers are under the impression that “experts” can perform jobs better than teams can.

When managers think that “experts” can perform jobs better, they create bottlenecks in the work. Bottlenecks prevent flow. Bottlenecks prevent agile or lean from working. It does not matter if you want agile or lean. You won’t get either with a bottleneck. You have to overcome the bottleneck.

Can you make a geographically distributed team work in an agile way? Yes. Let’s go back to the principles.

Our principles of agile or lean:
  1. You need to see all the work in progress.
  2. You want to flow work through the entire team.
  3. You want to see working software, sooner, rather than later.

If you, like me, don’t care how we get there, we have options.

How Could a Team Take These Principles and Create Their Own Agile Approach?

Let’s take one thing at a time.

Let’s assume the team is not accustomed to working on small items of value. If you are like many of my clients, this is the case. What would it take for the team to start working on small features that deliver value?

Let’s think about the product again:

Potential Release Frequency

Potential for Release Frequency

What kind of potential for release frequency does the team have? That colors the team’s thinking. The more potential for continuous deployment, the easier it is to work on small items of value.

This is where I like to introduce the notion of spikes and timeboxes. I ask the team to take their smallest feature, and work together on it. They don’t always have any notion of “together,” either. They say things such as, “We need …” and list the impediments to their ability to work together.

Now we see the need for management support.

Project Management is Not a Dirty Word; Neither is Management

I know that some of you dislike the idea of agile project managers. I know some of you positively hate the idea of management in agile organizations. Let me suggest that for teams transitioning to agile, there is a place for management. That place is creating an environment in which the team learns how to self-manage.

There is no place for command-and-control project managers—never has been, never will be. Unless it’s time for lunch. Sometimes, teams need people to say, “Lunch-time!” But even that isn’t command-and-control. That’s someone saying, “I’m taking care of my need to eat. Want to come along?”

It’s the same thing for a team with a lot of risk and a lot of unknowns. A team where the normal, out-of-the-box agile solutions don’t work. Why would you let a team like that flounder?

That team needs everyone to lead. And, it often, but not always, needs someone to represent that team to management. Why? Because management doesn’t understand agile yet. That part might come now, and it might come later. But in an agile transition with many unknowns, it almost never happens at the beginning, even if management is saying, “Please go agile.”

A geographically distributed team needs management support. It does not need command-and-control. That team does need support.

That’s when I ask the person working as the project manager to start removing impediments. The team creates their own visual board. (Yes, a distributed team almost always needs a tool. I like to start with cards on a wall first, take pictures of it. Once a team knows how they like to work, then they choose a tool.) The team decides what the length of their timebox is for this feature, if they want to use iterations. They decide how to spike it. They start making decisions.

That team especially needs to understand the problem of bottlenecks, experts, and how to stop needing experts.

After they practice this a couple of times, they have the confidence they need to do this more times on their project. They can call this agile, but it might not have a real name. It’s a mishmash of timeboxes and kanban, but it works for them. Does it matter what it’s called?

The Team Needs Management to Remove Obstacles

Teams might need management support. For example, I often discover geographically distributed teams don’t have enough testers. Well, you say, that team flunks the “we have all the cross-functional roles to do the work” part of agile. Yes, and what if they don’t know that? What if they want to try agile? What if they want to work through their obstacles and impediments? They need someone to represent them to their management, while they try to test as they proceed, right?

You could substitute “database admin” or “GUI designer” or whatever it is you need for tester in the above paragraph. Whenever you need someone to advocate on behalf of the team to management, you might want an agile project manager. Not someone to say, “When is the project going to be done?” Nope, not that kind of a PM. Someone to say, “What does the team need? I can help acquire that.”

PMs who provide servant leadership to the team, and represent what the team has accomplished to the rest of management can be invaluable. They can help the team understand its process and facilitate what the team can do if the team gets stuck. These are agile project management skills.

At this point, the team can try several approaches I suggested in these posts:

You might have an even better alternative than the ones I suggested.

Do you need a project manager? No. Do you need a servant leader? In my experience, yes. Maybe in your experience, no. I would love to hear from you, if you have a geographically distributed team that does not have a servant leader.

How Does This Team Evolve?

CynefinSome of my clients who are committed to agile have evolved their dispersed teams to be feature teams in multiple places. That has worked very well for them.

That has allowed each team to transition from the Complex to the Complicated. They now have collocated agile or lean teams. They can design their agile projects, as in Part 1. They retain the value of smart people all over the world. They don’t have the aggravation of trying to meet in different time zones for a project. They still have it for the program.

Some of my clients are still trying to make the dispersed teams work. It’s really hard. You might want to read my paper about the common problems on these teams.

Where are we now?

In Design Your Agile Project, Part 1, we discussed a straight-on approach to using whatever approach to agile, because it was obvious where you were.

In Design Your Agile Project, Part 2, we discussed looking at your system of work, and thinking about your unknowns. You need to think about your risks, and consider what you need to experiment with, to design your own agile project.

This part, part 3, is a continuation of part 2. It matters because you might need a servant leader who might be called a project manager. The title matters, because especially on a geographically distributed team, you are bridging the gap and the culture between the old way of working and the new way of working. I still think it’s Complex. Some of my clients think it’s Chaotic because they have so many impediments.

Whatever it is, you need data to take your next step.

Categories: Project Management

Design Your Agile Project, Part 2

Fri, 03/14/2014 - 14:49

The point of using agile is to get finish something valuable-to-the-business quickly, to get feedback. Why? For several reasons, but the first one is so you can change the project’s priorities. The second is so you can change the project portfolio. The third is to get feedback on what you’ve done. Okay, you can exchange one, two, and three if you like. For me, those are the top three reasons to get to done every few days to two weeks. They are right behind each other in priority. Agile is all about change.

This is why every project needs to design its own way to get to done.

If you have a single collocated team, who understands how to deliver value quickly you might be in the situation described in Design Your Agile Project, Part 1.

What happens when you have more unknowns? What if your organization is “addicted” to waterfall and long projects? When you can’t see the people on your project, because everyone isn’t in the same place? When you have a lot of technical risk, such as technical debt? How about when you’re starting a program and everyone is transitioning to agile (oh please, don’t do this). Or, you’re new to agile, and you don’t have training. I have a question: would you drive a car on the road with no training, either?

Rethinking What to do When Your Project or Organization is Full of Unknowns

CynefinLet’s discuss the principles of designing your agile project when you have more unknowns. Let’s start with a common problem: an organization “addicted” to waterfall and long projects. And, they’ve heard about this “agile” stuff, and they want to try it.

If you have heard about the many places Scrum has failed, this is classic. Scrum says, “replace your old culture with this new culture.” Wow, that’s a big shift. If you look at the Cynefin framework, you can see that for an organization addicted to waterfall, long projects and big requirements, they are not in Complicated. They are in Complex. Why? Because they have too many unknowns.

Here’s what I see when I do assessments in these organizations:

  • Much multitasking to address emergencies.
  • No project portfolio management
  • Their requirements are so large, it takes them forevvveerrr to release anything
  • Because their requirements are so large, and because their releases are so long, that increases the demand for emergencies: patches, interim releases, firefighting.

There could be more. This is enough.

In that case, you want to look at the Cynefin framework, and say, “What does the Complex side of the framework say?” It says we should consider emergent practice. We should not only consider out-of-the-box solutions. We have to probe-sense-respond.

What do we need to accomplish? Getting to working software, at the end of an iteration. Or, in flow. We want a feature, in flow, in a day or two, maybe three. We want completed features, with no leftover wasted work (unfinished features) at the end of an iteration. We want to be able to change what we do after the iteration, or after the feature. How do we accomplish that, from the team’s perspective? Let’s forget labels, and focus on the team.

What’s the First Thing the Team Could Do?

I like to ask, “How little can we do?” Too often, the team has been asking “How much can we do?” Starting with that question helps.

Thinking in inch-pebbles, timeb0xing work, spiking work, all of that helps to learn how to work small.

Sometimes, when we have stories, and we don’t know how to break them apart, we ask, “What’s the first thing that could add value?” Maybe that’s a good question here. You could ask, “What’s the first thing the team can do?” Or, “What’s the first thing we can do that would help us get to done in a one- or two-week iteration?” Or, “How do we finish a feature in flow (kanban)?”

Often, for teams who are in the Complex side of the framework, I suggest these things:

  1. Start a kanban board. You need to see what your actual process is. You need the visuals.
  2. Decide on your work in progress limits, and stick to them, at least for a week.
  3. Retrospect and reflect on those limits, the progress you’ve made and anything else that arose. Where are you, as a team? What progress did you make? What do you want to keep, add, change?

Notice how this is not out-of-the-box agile or lean. It’s a way to start a team moving from the Complex to the Complicated. Once a team has been through the first week, they iterate, keeping in mind these principles:

Let’s Review the Principles:
  1. Get to done, either in flow or iterations. Why? Because we want to develop working software.
  2. Keep the iterations short, either one or two weeks. Longer is not better. Why? It’s too long to allow for frequent change. Why? Because we need to allow for change in the project. That way, we can get feedback on the features, change the project’s priorities, and manage the project portfolio.
  3. Find a way to connect as a team, regardless of how you do so. Real-time rituals are not good if they make everybody crazy from lack of sleep. Why? We need sustainable development, even if real-time rituals are the best.
  4. Find a way to reflect as a team. Surrogate reflection is not good. Why? How can someone else substitute for what’s really going on in a team?

Where are we now?

Nobody has changed roles. Nobody has changed culture. We are looking at our process, and making things smaller for a while. We are reflecting. All of this in order to simplify, to move from the Complex to the Complicated.

Remember, I have only discussed what I have done with teams who are collocated, who have had problems with too-large features, long waterfall projects, and many emergencies. I haven’t addressed the issues of distributed teams yet. They are next.

I hope you stay with me as we move to part 3.

Categories: Project Management

Design Your Agile Project, Part 1

Thu, 03/13/2014 - 16:11

The more I see teams transition to agile, the more I am convinced that each team is unique. Each project is unique. Each organizational context is unique. Why would you take an off-the-shelf solution that does not fit your context? (I wrote Manage It! because I believe in a context-driven approach to project management in general.)

One of the nice things about Scrum is the inspect-and-adapt approach to it. Unfortunately, most people do not marry the XP engineering practices with Scrum, which means they don’t understand why their transition to agile fails. In fact, they think that Scrum alone, without the engineering practices, is agile. How many times do you hear “Scrum/Agile”? (I hear it too many times. Way too many.)

I like kanban, because you can see where the work is. “We have a lot of features in process.” Or, “Our testers never get to done.” (I hate when I hear that. Hate it! That’s an example of people not working as a cross-functional team to get to done. Makes me nuts. But that’s a symptom, not a cause.) A kanban board often provides more data than a Scrum board does.

Can there be guidelines for people transitioning to agile? Or guidelines for projects in a program? There can be principles. Let’s explore them.

The first one is to start by knowing how your product releases, starting with the end in mind. I’m a fan of continuous delivery of code into the code base. Can you deliver your product that way? Maybe.

How Does Your Product Release?

I wish there were just two kinds of products: those that released continuously, as in Software as a Service, and those with hardware, that released infrequently. The infrequent releases release that way because of the cost to release. But, there’s a continuum of release frequency:

Potential Release Frequency

Potential for Release Frequency

How expensive is it to release your product? The expense of release will change your business decision about when to release your product.

You want to separate the business decision of releasing your product from making your software releaseable.

That is, the more to the left of the continuum you are, the more you can marry your releases to your iterations or your features, if you want. Your project portfolio decisions are easier to make, and they can occur as often as you want, as long as you get to done, every feature or iteration.

The more to the right of the continuum you are, the more you need to separate the business decision of releasing from finishing features or iterations. The more to the right of the continuum, the more important it is to be able to get to done on a regular basis, so you can make good project portfolio decisions. Why? Because you often have money tied up in long-lead item expenses. You have to make decisions early for committing to hardware or Non Recurring Engineering expenses.

How Complex is Your Product?

Let’s look at the Cynefin model to see if it has suggestions for how we should think about our projects:

CynefinI’ll talk more about you might want to use the Cynefin model to analyze your project or program in a later post. Sorry, it’s a system, and I can’t do it all justice in one post.

In the meantime, take a look at the Cynefin model, and see where you think you might fall in the model.

Do you have one collocated cross-functional team who wants to transition to agile? You are in the “known knowns” situation for agile. As for your product, you are likely in the “known unknowns” situation. Are you willing to use the engineering practices and work in one- or two-week iterations? Almost anything in the agile or lean community will work for you.

As soon as you have more than one or two teams, or you have geographically distributed teams, or you are on the right hand side of the “Potential for Release Frequency” chart above, do you see how you are no longer in the “Complicated” or “Obvious” side of the Cynefin model? You have too many unknowns.

Where Are We Now?

Here are my principles:

  1. Separate the business decision for product release from the software being releaseable all the time. Whatever you have for a product, you want the software to be releaseable.
  2. Understand what kind of a product you have. The closer you are to the right side of the product release frequency, the more you need a program, and the more you need a kanban to see where everything is in your organization, so you can choose to do something about them.
  3. Make sure your batch size is as small as you can make it, program or project. The smaller your features, the more you will see your throughput. The shorter your iteration, the more feedback you will obtain from your product owner and “the business.” You want the feedback so you can learn, and so your management can manage the project portfolio.
  4. Use the engineering practices. I cannot emphasize this enough. If you do not keep your stories small so that you can develop automated unit tests, automated system tests, use continuous integration, swarm around stories or pair, and use the XP practices in general, you will not have the safety net that agile provides you to practice at a sustainable pace. You will start wondering why you are always breathless, putting in overtime, never able to do what you want to do.

If you have technical debt, start to pay it down a little at a time, as you implement features. You didn’t accumulate it all at once. Pay it off a little at a time. Or, decide that you need a project to prevent the cost of delay for release. If you are a technical team, you have a choice to be professional. No one is asking you to estimate without providing your own safety net. Do not do so.

This post is for the easier transitions, the people who want to transition, the people who are collocated, the people who have more knowns than unknowns. The next post is for the people who have fewer knowns. Stay tuned.

Categories: Project Management

Overcoming Several Pitfalls of Agile Transition: Webinar, March 10, 2014

Fri, 03/07/2014 - 15:21

Join me for a webinar on March 10, 2014 at 7pm Eastern. My topic is “Overcoming 7 Common Pitfalls of Transitioning to Agile in Software Engineering.” I’m speaking as part of the Graduate Professional Studies Spring 2014 Guest Speaker Series.

Register here.

P.S. If you missed the webinar, here is the audio recording. Enjoy!

Categories: Project Management

Debugging Your Geographically Distributed Agile Team Posted

Mon, 03/03/2014 - 14:46

I have a new column up on project management.com. It’s called Debugging Your Geographically Distributed Agile Team. (You have to register to read it. Registration is free.)

You can do agile with geographically distributed teams. You might not be able to do Scrum. You have other choices of approaches.

Helping a team form is tough. This article, which is true, shows how tough it can be.

Do you have similar experiences? Different experiences? Let me know. I’d love to hear from you.

Categories: Project Management

Understanding State vs. the Micromanagement Trap

Mon, 02/24/2014 - 15:30

Back when I was a Director of many things at one company, we had an urgent patch to go to a customer. My VP wanted it “yesterday.” Well, time only goes in one direction.

I gathered my continuing engineering team, explained the pickle we were in. “Everyone wants this patch right away. However the customer is truly pissed. I want to know that we have a fix that works. And, while you are working on it, I will need to know updates every morning and every afternoon. I will run interference for you, as well as I can.”

Everyone groaned. They knew what this meant. We had a small company. The corporate management was just down the hall from our offices. Even though I said I would run interference, nothing would prevent the VP of Engineering, the CEO, or the CTO from popping their heads in “to see what’s going on.” Everyone wanted to make the customer happy, right now.

At the time, I didn’t know about kanban boards. I knew about spreadsheets and email. I had four people working on this fix. I knew what they were all doing. So did they.

They managed themselves. Their offices were close to each other. Every day, about noon or so, they gathered in my office, so I would have the most up-to-date status. It wasn’t quite a standup, because some of the work was what we would now call spikes. (At first, we had no idea what was causing the problem.)

As we identified the problem, I explained to management on behalf of the team how they narrowed down the problem and identified it. Then I explained to management on behalf of the team how they were debugging the problem. Then I explained to  management on behalf of the team how they were testing the fixes they proposed. Then I explained to management how they were packaging the fix they had decided on.

If we’d had a visual board, this might have been easier. I used email. It took close to a month. It was a very difficult fix.

Notice what I did:

  1. I explained to the team the results I wanted: as quickly as possible, but it had to be right. Right trumped shoddy.
  2. I explained that I needed information, and how often I needed it.
  3. I ran interference and kept the rest of the management team informed, daily. My goal was no surprises.
  4. I explained things on behalf of the team, so they got the credit. I was doing my management job, not technical work.

Because our management, and I could share the interim results with the customer, the customer was not happy during this month, but they were pleased to know we were working on the fix. By the time they got the patch, they were very pleased. It worked.

I did not micromanage my people. I understood their state. There is a big difference. And that is the topic of this month’s management myth, Management Myth 26: It’s Fine to Micromanage.

If I had stood over their shoulders, and asked, “Is it done yet?” I suspect I would have had different results.

My team understood that I was doing my management job. I didn’t prevent all other senior management interference. But, I prevented most of it. In return, they were free to work together to accomplish their goal: a fix that didn’t upset the rest of the system and really fixed this customer’s problem.

It’s easy to fall into micromanagement. We, as technical people are terrific problem solvers. We excel at it. We want to help other people solve their problems. Micromanagement is inflicting help on other people. It’s not helpful. It’s irritating and prevents other people from doing their jobs.

Have you caught yourself micromanaging? If so, what made you stop?

Categories: Project Management

Cost of Delay: Why You Should Care, Part 6

Tue, 02/18/2014 - 16:11

I’ve outlined five potential costs of delay in the previous five posts:

The real problem is this: Why should you care? Maybe you have a “sweet spot” in the way you start your projects or release them. “It just takes that long here.” (That’s the sign of a system impediment.)

Cost of Delay, Back of the Napkin

Cost of Delay, Back of the Napkin

Let me show you two pictures. The first you’ve already seen, the back of the napkin, where you see the effect on your potential maximum revenue.

Now, let’s try to calculate that cost of delay.

The longer your delay, the more your cost of delay moves your curve to the right. The more sales you lose out of the Maximum potential sales.

The longer it takes for you to release, the more sales you lose from the maximum potential sales. You wait a month to release? You lose a month of max sales. You wait a year to release? You lose a year of max sales.

Cost of Delay, Showing Effect of Delay on Sales

Cost of Delay,
Showing Effect of Delay on Sales

That’s right. Do those numbers start to look big and scary now?

You not only have aggravation and impediments in your current project from the delays from multitasking, technical debt, indecision, slowdowns from other teams, you lose the potential revenue from maximum potential sales, every week you don’t release.

Now, I am not saying you should release horrible product. Goodness knows, we have enough of horrible product that barely works or doesn’t work at all out in the field. I want to see great products! The idea behind this picture is so people understand that it is worth their while to consider change.

You can change to shorter projects and release something useful faster. (See Manage It! Your Guide to Modern, Pragmatic Project Management)

You can change to agile or incremental lifecycles so they can see progress and release something useful faster. (See What Lifecycle? Selecting the Right Model for Your Project and Manage It! Your Guide to Modern, Pragmatic Project Management for an in-depth discussion of lifecycles. You have more options than just waterfall and agile.)

You can adopt a more reasonable approach to the project portfolio, and make decisions more frequently. (Does anyone really think project portfolio decisions last a year? Come on.) (See Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects)

You can consider paying off some technical debt. I used the build system in my example. I could have used automated tests or the thousands of defects some of you have in your defect tracking systems. It’s whatever prevents you from knowing you could release on a “moment’s” notice. I would like that moment to be under an hour. I bet for many of you, less than a day would be a huge improvement.

You can optimize for the entire project or program, not their feature or team. Too often, I hear, “My part is done.” That does not matter. It matters what the entire team, project, or program finishes.

In my talks about project portfolio management, I am fond of saying, “It doesn’t matter how many projects you start, it matters how many you finish.”

With cost of delay, it matters when you finish them. Because until you finish them, no one pays you.

I have taken a high level approach to cost of delay in these posts. I wanted to simplify it so you and I could understand it, a zeroth approach, if you will. If you want more information, start here:

Cost of delay is why you cannot take an ROI or use date or budget estimates to manage the project portfolio. This is why you must use value. I look forward to your comments.

Categories: Project Management

Cost of Delay Due to Other Teams’ Delay, Part 5

Sat, 02/15/2014 - 21:58

Imagine you have a large program, where you have several teams contributing to the success of one business deliverable. You are all trying to achieve a specific date for release.

One team is having trouble. Maybe this is their first missed deliverable. Maybe it’s their second. Maybe they have had trouble meeting their deliverables all along—they have “delivered,” but the deliverables don’t work.

Now, say you’re halfway through the desired program time. You, as a program manager, can see that this program is in trouble. That one team is not going to make it. What do you do?

This us where you start talking to people and understanding what the value of everything is.

  1. Does the program need everything on that team’s backlog?
  2. Does the program need everything on other team’s backlogs?
  3. Does the program product owner understand the cost of delay?
  4. How about the sponsors for the program? Do they know what’s going on?
Cost of Delay, Back of the Napkin

Cost of Delay, Back of the Napkin

Take out your back of the napkin calculation and show it to anyone who will listen.

Does the team understand the problem of lateness, as we discussed in part 1? They might. They might be overwhelmed by the technical difficulty of what they are doing. Maybe their stories are huge. Maybe they aren’t so hot at agile. Maybe they aren’t working in an agile way. There are 1001 reasons for this problem. If you are a manager of any stripe, program manager, development manager, whatever, you are responsible for understanding first, not yelling. (I often see senior development managers, VP Engineering encountering this, not realizing that they are the program managers in this situation.)

Does the program product owner really need everything in their backlog? It’s time to consider how little can that team do, and still deliver something of value. Or, it’s time to consider how little other teams do and still deliver something of value. Or, it’s time to rejigger who is doing what. Otherwise, you are going to lose the money in the middle of the revenue stream.

Are the teams working by layer, front end, middleware, back end, instead of through the architecture?

Something has to change in this program. You are not going to make the desired date. This problem is a larger case of the not shipping on time problem, but it’s not just one team. It involves more teams. And, with a program, it involves more money. It’s almost always a bigger stake.

This is when you want to start considering cost of delay for features. Yes, not just for releases, but for features.

Each feature has value when you deliver it at a certain time. Before a certain time, it might have more or less value. After a certain time, it has less value.

Who knows when that time is? Who can make these decisions in your organization. Sometimes that person is called a product owner, a product manager, or, gasp, a customer. Sometimes, that person is called a Marketing Manager or Director, or even a CEO. Rarely is that person called a developer or tester, or even a development manager or test manager or an Engineering manager or CIO or VP of Engineering. Sometimes the product development side knows. Almost never does the product development team know by themselves.

If you make decisions as a cross-functional team, product development and marketing, you can get the best of both worlds. You can learn about the technical risks—especially good if the team is having technical problems. You can learn about the cost of delay risks—especially good from the customer perspective. Now, you can make a decision about what to do for the good of the program.

You have to optimize for the program’s throughput, not any one team’s throughput.

In my world, you work with the team: do they want to stay together? Are they working well together, and having a tough time technically? If so, the team has many options:

  • The team can ask for technical help from another team (get an architect/designer to work with the team)
  • The team can split their backlog among several other teams, to give them a fighting chance.
  • If the team is not working well together (and they will tell you if they are still storming), offer them a chance to split. Or, you can facilitate a better working relationship so they can work well together.

If you don’t ask the team, you don’t know what’s wrong.

The problem with this cost of delay is that it’s tricky to discuss, it’s tricky to estimate, and it’s tricky to fix. It’s real. I bet you’ve seen it.

I would take out the napkin and remind the team that their delay costs the entire program. I want to help them remove that delay.

If you are using a waterfall approach to your programs, this cost of delay is invisible until the end of the program, when testing occurs. Why? Because that’s when you start to see features emerge.

If you are using an agile approach or at least an incremental lifecycle, you will start to see this much sooner, and you can do something about it.

The posts in this series so far are:

Cost of delay due to not shipping on time, part 1

Cost of delay due to multitasking, part 2

Cost of delay due to indecision, part 3

Cost of delay due to technical debt, part 4

Categories: Project Management

Cost of Delay Due to Other Teams’ Delay, Part 5

Sat, 02/15/2014 - 21:58

Imagine you have a large program, where you have several teams contributing to the success of one business deliverable. You are all trying to achieve a specific date for release.

One team is having trouble. Maybe this is their first missed deliverable. Maybe it’s their second. Maybe they have had trouble meeting their deliverables all along—they have “delivered,” but the deliverables don’t work.

Now, say you’re halfway through the desired program time. You, as a program manager, can see that this program is in trouble. That one team is not going to make it. What do you do?

This us where you start talking to people and understanding what the value of everything is.

  1. Does the program need everything on that team’s backlog?
  2. Does the program need everything on other team’s backlogs?
  3. Does the program product owner understand the cost of delay?
  4. How about the sponsors for the program? Do they know what’s going on?
Cost of Delay, Back of the Napkin

Cost of Delay, Back of the Napkin

Take out your back of the napkin calculation and show it to anyone who will listen.

Does the team understand the problem of lateness, as we discussed in part 1? They might. They might be overwhelmed by the technical difficulty of what they are doing. Maybe their stories are huge. Maybe they aren’t so hot at agile. Maybe they aren’t working in an agile way. There are 1001 reasons for this problem. If you are a manager of any stripe, program manager, development manager, whatever, you are responsible for understanding first, not yelling. (I often see senior development managers, VP Engineering encountering this, not realizing that they are the program managers in this situation.)

Does the program product owner really need everything in their backlog? It’s time to consider how little can that team do, and still deliver something of value. Or, it’s time to consider how little other teams do and still deliver something of value. Or, it’s time to rejigger who is doing what. Otherwise, you are going to lose the money in the middle of the revenue stream.

Are the teams working by layer, front end, middleware, back end, instead of through the architecture?

Something has to change in this program. You are not going to make the desired date. This problem is a larger case of the not shipping on time problem, but it’s not just one team. It involves more teams. And, with a program, it involves more money. It’s almost always a bigger stake.

This is when you want to start considering cost of delay for features. Yes, not just for releases, but for features.

Each feature has value when you deliver it at a certain time. Before a certain time, it might have more or less value. After a certain time, it has less value.

Who knows when that time is? Who can make these decisions in your organization. Sometimes that person is called a product owner, a product manager, or, gasp, a customer. Sometimes, that person is called a Marketing Manager or Director, or even a CEO. Rarely is that person called a developer or tester, or even a development manager or test manager or an Engineering manager or CIO or VP of Engineering. Sometimes the product development side knows. Almost never does the product development team know by themselves.

If you make decisions as a cross-functional team, product development and marketing, you can get the best of both worlds. You can learn about the technical risks—especially good if the team is having technical problems. You can learn about the cost of delay risks—especially good from the customer perspective. Now, you can make a decision about what to do for the good of the program.

You have to optimize for the program’s throughput, not any one team’s throughput.

In my world, you work with the team: do they want to stay together? Are they working well together, and having a tough time technically? If so, the team has many options:

  • The team can ask for technical help from another team (get an architect/designer to work with the team)
  • The team can split their backlog among several other teams, to give them a fighting chance.
  • If the team is not working well together (and they will tell you if they are still storming), offer them a chance to split. Or, you can facilitate a better working relationship so they can work well together.

If you don’t ask the team, you don’t know what’s wrong.

The problem with this cost of delay is that it’s tricky to discuss, it’s tricky to estimate, and it’s tricky to fix. It’s real. I bet you’ve seen it.

I would take out the napkin and remind the team that their delay costs the entire program. I want to help them remove that delay.

If you are using a waterfall approach to your programs, this cost of delay is invisible until the end of the program, when testing occurs. Why? Because that’s when you start to see features emerge.

If you are using an agile approach or at least an incremental lifecycle, you will start to see this much sooner, and you can do something about it.

The posts in this series so far are:

Cost of delay due to not shipping on time, part 1

Cost of delay due to multitasking, part 2

Cost of delay due to indecision, part 3

Cost of delay due to technical debt, part 4

Categories: Project Management

Cost of Delay Due to Technical Debt, Part 4

Thu, 02/13/2014 - 13:36

Cost of delay part 1 was about not shipping on time. Cost of delay part 2 was due to multitasking. Cost of delay part 3 was due to indecision. This part is the cost of delay due to technical debt.

One of the big problems in backlog management is ranking technical debt stories. It’s even more of a problem when it’s time to rank technical debt projects. You think product owners have feature-itis problems? Try having them rank technical debt projects. Almost impossible.

But if you really want the value from your project portfolio, you will look at your impediments. And, if you are like many of my clients, you have technical debt: a build system that isn’t sufficiently automated, insufficient automated system tests, too many system-level defects, who knows what else.

If you addressed the build system, and maybe some of the system tests, if you created a timeboxed technical debt project, you could save time on all of the other projects in this code base. All of them.

Imagine this scenario: you have a 2000-person Engineering organization. It takes you 3 weeks (yes, 21 calendar days) to create a real build that you know works. You currently can release every 12-18 months. You want to release every 3-6 months, because you have to respond to market competitors. In order to do that, you have to fix the build system. But you have a list of possible features, an arm and a leg long. What do you do?

This client first tried to do more features. They tried to do features in iterations. Oh, they tried.

By the time they called me, they were desperate. I did an assessment. I asked them if they knew how much the build system cost them. They had a group of  12 people who “supported” the build system. It took at least 10 days, but closer and closer to 20-25 days to get a working build. They tried to estimate the cost of the build in just this group of people: 12 people time 21 days. They did not account for the cost of delay in their projects.

I showed them the back of the napkin calculation in part 1, and asked, “How many releases have you postponed for at least a month, due to the build system?” They had an answer, which was in the double digits. They had sales in the millions for the maximum revenue. But they still had a sticking point.

If they funded this project, they would have no builds for four weeks. None. Nada. Zilch. And, their best people (whatever that means) would be on the build project for four weeks.

So, no architecture development, no design, no working on anything by the best people on anything other than the build system. This company was convinced that stopping Engineering for a month was a radical step.

Does it matter how long your iterations are, if you can’t build during the iterations and get feedback?

They finally did fund this project, after about six months of hobbling along.

After four weeks of intense work by 16 of their smartest people, they had an automated build system that anyone in Engineering could use. It still took 2 days to build. But that was heaven for everyone. They continued the build system work for another month, in parallel with regular Engineering work to reduce build system time.

After all the build system work, Engineering was able to change. They were able to transition to agile. Now, Engineering could make progress on their feature list, and release when it made sense for their business.

What was the payback for the build system work? Almost immediate, Engineering staff said. When I asked one of the VPs, he estimated, off the record, that they had lost more than the “millions” of dollars of revenue because they did not have the features needed at the time the market demanded. All because of the build system.

People didn’t plan for things to get this way. They got that way a little at a time, and because no one wanted to fund work on the build system.

This is a dramatic story due to technical debt. I bet you have a story just like this one.

The cost of delay due to technical debt is real. If you never look at your technical debt and see where it impedes you, you are not looking at the value of your entire project portfolio.

If you eliminated a technical debt impediment, would that change one of your costs of delay?

Categories: Project Management

Cost of Delay Due to Indecision, Part 3

Fri, 02/07/2014 - 00:12

In Part 1, we discussed the cost of delay of not shipping on time. In Part 2, we discussed the cost of delay of multitasking. In this part, we’ll discuss a cost of delay due to management indecision.

Here’s a problem I encounter often. A middle manager calls me, and asks for an estimation workshop. I ask about the environment. The manager tells me these things:

  • The developers meet their dates and the testers never do (this is not an estimation problem)
  • The project starts on time, and the project staff comes in close, but not quite on time (this might be an estimation problem)
  • The project starts off late (this is not an estimation problem)

When the developers meet their dates but the testers never do, it’s almost always a couple of things: Schedule Chicken, or technical debt masquerading as done in a waterfall project.

If the project starts on time and it’s close, it might be an estimation problem, assuming no one is multitasking.

But if the project starts late, this is not an estimation problem. This is a cost of delay due to management indecision.

Wouldn’t it be nice if you could say,

A lack of planning on your part does not constitute an emergency on my part

to your managers? Well, just call me the Queen of the Career Limiting Conversation. This is why managers are supposed to manage the project portfolio.

When I hear the plea for the estimation workshop, it’s for these reasons:

  • The managers have received estimations for the work, and they don’t like the estimates they have received.
  • Someone other than the project team did the estimation two years ago. They know the estimate is out of date, and they need a new estimate.
  • The managers still can’t make a decision, because they are trying to decide based on ROI, date, or cost or some sort of hard to predict quantitative measure, rather than on value.

The managers are, ahem, all tied up in their shorts. The can’t decide, which is a decision. They don’t fund the potentially transformative projects or programs. They go with the safe bets. They do the same projects over and over again.

If they get lucky, they choose a project which is small and has a chance of success.

How do you discuss this cost of delay? You ask this question:

When did you first start discussing this project as a potential project? or When did this project first go on our backlog?

That provides you the first date you need. This is your next question:

When did we actually start working on this project?

You want to see how long it takes you to consider projects. It’s okay to consider some projects for a while. The difference between the time you first start discussing a project and the time you start working on it is your management cost of delay. I just made that up. I bet there’s a real name for it.

What is the difference in those two dates?

Project lead time is the time you started discussing a potential project and the time you finished it. Project cycle time is the time you started a project and the time you finished it. Yes, we normally discuss lead time and cycle time for features. But sometimes, it makes sense for projects, too.

If you release projects, not features, and you have managers who have decision problems, they need to know about this cost of delay. Because the project lead time will take time out of your maximum revenue. The longer that lead time is, the more it will take.

The worst part is this: how much value does the project have, if the project lead time is “too long?”

What can you do?

  1. Track your project lead times. Decide how much time a project can spend on the backlog in the project portfolio before you decide to transform or kill it. Yes, I am serious.
  2. Shorten all your projects, so you release something at least every six months, or more often. That provides you more capability in assessing your project portfolio and frees teams for more work.
  3. Move to an incremental lifecycle or an agile approach.

I didn’t say it was easy. It’s healthier for your organization.

Who do you think can measure this cost of delay in your organization? What do you think might have to change to make this cost of delay visible?

Categories: Project Management

Cost of Delay Due to Multitasking, Part 2

Thu, 02/06/2014 - 23:00

In Cost of Delay: Not Shipping on Time, Part 1, I introduced you to the notion of cost of delay. I said you could reduce the cost of delay by managing your projects: have shorter projects, using release criteria, or selecting a lifecycle that manages the risk.

Sometimes, you don’t have short projects, so projects get backed up, and your managers ask you to work on several things at once. Or, the managers can’t decide which project is #1. Somehow, you end up doing several things “at once.” This is the multitasking problem, and this is the cost of delay in this part.

You know me, I hate multitasking. The costs are significant. But those are just the costs of multitasking on the work you are doing now. That has nothing to do with the cost of delay to your projects.

In Manage It!, I have this nice picture of what happens when you try to multitask between two projects.

Two Tasks or Projects

Two Tasks or Projects

Imagine you have two projects. Each of them should take a week. Hey, they’re short projects. I’m trying to illustrate a point.

You can deliver one of them at the end of the first week. You can deliver the second one at the end of the second week.

But, imagine you have to multitask between them. Instead of being able to deliver anything at the end of the first week, you can’t deliver anything at all until the second week. And, depending on how much context switching you do, you might not be able to deliver anything until sometime during the third week. The blue boxes show the time lost due to context switching.

Effect of Multitasking Delay to Delivery

Effect of Multitasking
Delay to Delivery

This is a huge cost of delay due to multitasking.

How do you calculate this?

“Big” is not quantitative enough for some people. This is where using some of the tools from the people who do this for a living might be good.

I’ve always drawn a picture like this and explained, “I don’t know how to estimate the time in the blue boxes. The blue boxes are the delay times. I can’t estimate them, because everyone else is delayed by multitasking on their projects, too. Sometimes, it takes me an entire day to get an answer to a question that should only take me an hour to get an answer. All I know is that “ideal” time is irrelevant to actual time. And even calculating using relative estimation is hopeless. That’s because we are multitasking. All of our estimations are out the window because we are multitasking.

“The amount of time we spend working on a project might be accurate. It’s the wait time that’s killing us. I don’t know how to estimate that.”

What I’ve done before is take a two- or four-week window, and ask people to write down their predictions of what they thought some task would take. Then, I ask them to write down, as they spend their time on each task, how much time they actually spend on each task. Now you can compare the prediction to reality.

Remember that all of the context switching and wait time is the time you need to remove from the maximum sales revenue, had you released the product.

This is very difficult to do. It saps the morale of the people doing the work. They quickly realize how often they go back to the same thing, over and over and over again, making zero progress, trying to realize where they are. Do not do this for more than a four-week window. If you must do this, label this an experiment to obtain data. Explain you are trying to obtain actual work time, context switching time,  and wait time. Let people label the time as they will.

The managers will be astonished by how little time the technical staff spend on real work. They will be amazed by how much time the technical staff spend on context switching and wait time. This is why managers think technical staff are bad at estimation. Who can be good at estimation when they are multitasking?

The problem is this: the cost of delay due to multitasking is real. It’s invisible to most people, especially management. It’s not just the cost of the blue boxes in the picture above. It’s the fact that nothing gets out of your organization until the end of Week 2 or later. Remember the back of the napkin in Part 1? Even if you use that calculation, you can see you are losing revenue left and right due to multitasking.

Remind the managers: Remember that all of the context switching and wait time is the time you need to remove from the maximum sales revenue, had you released any of the products.

Can you use this as an argument for your managers to end the multitasking and manage the project portfolio?

Cost of delay due to multitasking is real. What would you need to know to calculate it in your organization?

Categories: Project Management

Cost of Delay: Not Shipping on Time, Part 1

Wed, 02/05/2014 - 16:59

Do you know about the Cost of Delay? It’s the way to think about the revenue you can lose plus the cost of continued development.

One of my managers many years ago had a back of the napkin approach to cost of delay.

Cost of Delay, Back of the Napkin

Cost of Delay,
Back of the Napkin

“Johanna, we want to ship this product in the second quarter this year. We estimate it will take us a quarter to ramp up sales. We think there is a lifetime sales of about five years for this product. Any delays in our shipment will not push our sales figures to the right. They will remove our max sales from the middle. Got it? We have to make our ship date.”

I got it.

There weren’t too many of us developers in that organization. We all knew what our job was: to release on time, and make sure the product was usable. The product didn’t have to be perfect. The product had to be usable, because we could release fixes if we needed to, but we had to climb that sales ramp to get to that max sales point.

We worked on one project at at a time, until it was done. Then we went to the next project. We worked on that project. None of our projects was very long. Why? Because we needed to realize revenue. You can’t realize revenue with a product-in-a-box if you don’t ship it.

We didn’t ship too many fixes. Oh, not because we were perfect the first time. We asked each other for review, and we found problems, so we fixed them inside the building. Before we shipped. Because the cost of not shipping on time was too great.

When you delay your release and don’t ship on time, you miss the revenue from the maximum sales times. Take your delay in weeks, and remove the revenue weeks. That’s your cost of delay, back of the napkin approach.

You can go through more serious calculations. Troy Magennis of Focused Objective talks about a “compounding impact” on other projects. I am sure he’s correct.

But even if you said, “Every week we slip, we lose at least a week of revenue from our maximum sales week of revenue,” do you think people would notice?

How do you release on time? You fix scope (ha!). You have release criteria. You have shorter projects, because they are easier to estimate and deliver. You use an incremental or an agile lifecycle, so you have more predictability about your release.

This post is the simple idea of not shipping on time. But what about when you have competing projects and not enough people? Look for Part 2, next.

P.S. After I wrote this post, I realized I was not living this post. (Why do you think I write? It’s not just for you. It’s for me too.) I published the incomplete Essays on Estimation. I have another essay or two to release. But if I don’t release it, you can’t read it and get any value from it, can you? The point: if you don’t release your products, your customers can’t get any value. Hat Tip to @jlottsen who said in a tweet, “you have to release it, or no one can use it, and you can’t realize any revenue at all”. Very true.

Categories: Project Management

If Managers Don’t Give Performance Reviews, What Happens?

Wed, 01/29/2014 - 13:49

There’s a great comment to my recent Management Myth: Performance Reviews Are Useful. The writer has these questions, which I have paraphrased:

1. How do bonuses work?

Here’s the problem with bonuses in a team-based organization (agile or not). How can you tell who has done which work? Who actually knows who has contributed what?

The team does. This is true whether the team is agile or not. The team always knows who has done great work, who has pulled done whatever, or if someone is hiding. It’s easier to know if someone is hiding in agile.

The team always knows who has done what. The manager can try to know, by asking for status. The manager can try to know by asking for accomplishments. But the team knows.

That’s the first problem.

The second problem is why is any knowledge worker’s pay based on a bonus? This smacks of management by objectives. You know the kind, “We’ll increase our sales by x% over this year.” All other objectives flow from that. By the time they get to you, your bonus is supposed to be based on you completing a specific project your managers were supposed to fund at the beginning of the year.

Did you read all of those “supposed to” in the previous paragraph? That’s what happens with traditional project portfolio management and big-bang funding. That’s part of the reason you end up with multitasking which makes everyone crazy. People are trying like crazy to fulfill their personal bonuses (optimizing at the lower levels) instead of doing what the organization needs. This is one of the reasons I wrote Manage Your Project Portfolio.

How many of you missed out on a bonus because some salesperson screwed up? (My hand is up.) We completed our technical projects. Sales sold stuff we didn’t have. Sales didn’t sell stuff we did have. Management didn’t decide on a reasonable strategy, even though we completed our projects. Somehow this was our fault as technical people? Come on. We did our parts. No bonus for us. This is fair? Nope.

When you provide individual bonuses, you do not guarantee better results. We have data that proves this. Read Dan Pink’s Drive: The Surprising Truth About What Motivates Us, Pfeffer & Sutton’s Hard Facts, Dangerous Half-Truths, and Total Nonsense: Profiting from Evidence-based Management, and Hope’s Beyond Budgeting: How Managers Can Break Free from the Annual Performance Trap.

If your company is basing your compensation partly on bonus, it’s because they are cheap. They are trying to tie part of your compensation to something you have no control over: revenue. Revenue sharing is fine for retirement funding. Not so fine for regular compensation.

2. How can a company know who is contributing and who isn’t?

Ask the team. They know. Who else needs to know and why?

This is why you want to push the responsibility for feedback and coaching into the team. This is why you want the manager to be a servant leader.

When the manager is a command-and-control leader, no one knows nothing.

Why would anyone step forward and take responsibility? It is no one’s interest to do so.

3. Without paperwork we introduce possibilities of lawsuits, particularly for big companies?  If a man is paid less than a woman and it is found out, using your logic, discrimination lawsuits are reasonable since there is no ranking.  HR likes this paperwork to try to protect the corp.  Granted Netflix has a solution of 6 months severance, but do you have any other alternatives?

Let me separate this one. You don’t need paperwork to know if people are paid comparably.

You can have salary ranges for each level. You can group each level and see what you get. I did this at one of my jobs. I discovered that when I was the only female manager, I was the  one paid $10k less than the men. I brought that to my manager’s attention. He hemmed and hawed. I persisted. I said the word “discrimination.” They gave me a raise to bring me parity.

I wasn’t ranked. I grouped people by salary range, that’s all. I didn’t need ranking to see this. I needed a spreadsheet.

I hadn’t done this to look at my salary by the way. I had done this to look at all of Engineering, at the request of my boss. The question is this: What problem are you trying to solve?

HR doesn’t need ranking. They need common sense, which I admit, isn’t all that common.

Paperwork doesn’t solve problems. Paperwork protects HR from lawsuits, maybe. My paperwork proved that the company was discriminating against me. I didn’t intend it that way. But that’s what it proved.

4. You are arguing that management doesn’t need to exist in the traditional sense (since paperwork has been a big part of the job).  If agile has killed the ability of the manager to know what is going on and can’t review the employees, why have a manager at all?  Why not replace people-oriented managers with project-oriented managers?

Managers exist to create an environment that helps people do their best job. Managers exist to create and refine the strategy and to organize with purpose. Managers provide coaching and meta feedback. Managers initiate communities of practice. Managers manage the project portfolio. Managers provide servant leadership.

Even if managers did performance reviews, they didn’t do reviews every day of the year. They didn’t rank every day of the year. They certainly didn’t keep their eyes on “their” employees every day of the year. (Okay, the micromanagers did. But most traditional managers were not micromanagers. They were poor lost souls who didn’t know what else they should be doing.)

Project managers help a project get to done. People managers should not interfere with that. In a matrix organization, that is precisely what happens. I’m not sure what happens where you are.

I have a coaching client where the people managers are the project managers. They are also doing a form of agile. It’s their form of agile. You wouldn’t recognize it as by-the-book anything. But, because the VP is in charge of all of Engineering, he can see when the system is working and when it isn’t.

We had a conversation last year, and I suggested their stories were too big. It was too difficult for the managers to make project portfolio decisions. It looked as if some people were slacking off and some were working very hard. I suggested my coachee might not have enough data.

“If you make the stories smaller and the work flows through all the teams more evenly, you won’t need as many experts. The teams will be able to complete their work, and be able to finish their work more reliably. You will have more data on the teams. They will have more data on each other. You won’t have to pluck people and move them from project to project, which makes things worse. Before you decide some people are better or worse, why not try improving the system, first?”

They decided to do that. It was quite difficult for them. It went against everything they knew how to do: architecture, estimation, planning, implementation, everything. But they decided to try. Their managers were also their project managers and guided the teams to success. My coachee, the VP, learned that the people he had thought were great were good, but there were some shining stars he had not known about. The shining stars kept their mouths shut and kept the company running. All invisible work to the VP. Not invisible to the project managers. Who happened to also be the people managers.

There is no Right Way to organize. There is no One Right Way to manage. I lean towards servant leadership, because I don’t see how to have an effective organization without it.

How can we expect people, who are responsible adults, who have mortgages, children, and enter into contracts every day of their adult lives to turn off their brains at work? Why would we want them to?

Managing knowledge workers is not trivial. You try something, you get some feedback.

But performance reviews and especially ranking? No. Give me feedback on my work on a regular basis. Not performance reviews. Not paperwork. Not ranking. Don’t compare to other people. Tell me when I’ve done something useful. Tell me when I’ve done something not as useful, and why.

What do you think about these four points, especially about the role of the manager?

Categories: Project Management

Performance Reviews Are Not Useful; Feedback Is

Wed, 01/22/2014 - 16:11

I have received some wonderful feedback from some of my managers. Back when I was a young engineer, one of my managers gave me the feedback at an annual review that I didn’t quite finish my projects.

“Oh, you mean on the project I just finished last week?” I wanted to know if it was just that one. I thought I could go back and finish it.

“No, I mean the one 9 months ago, the one 6 months ago, the one 3 months ago, and the one last week,” my boss said.

I became angry. “Okay, I understand why you saved last week’s project for my performance review. That’s okay. Why on earth did you “save” my feedback for the other three projects?? I could have fixed them!”

He shrugged. “I thought I was supposed to wait for the performance review.”

“Don’t wait that long!” I told him. I vowed that when I became a manager, I would never surprise people with feedback.

I now know about finishing projects. As I said, it was great feedback.

I’ve also received feedback about how I needed to let people on a project come to me with bad news. That was really helpful, and I didn’t receive it at a performance review, thank goodness. That would have been way too late. I was able to change my behavior.

When I became a manager, I had to write performance evaluations for my staff. I didn’t like it, but I did it. I thought it was crazy, because, even though we weren’t agile back then, the people worked in cross-functional teams where the people on the teams knew more about what “my” people did than I did. Yes, even though I had one-on-ones. Yes, even though I asked everyone for a list of accomplishments in advance. But, it was the way it was. Even I thought I couldn’t buck city hall.

But now, agile has blown the idea of performance evaluations wide open. And ranking people? Oh my.

I one worked in an organization where a new VP wanted to rank everyone in the Engineering organization, all 80 people. I thought he wasn’t serious, but he was. He wanted to rank everyone from 1 to 80. Us directors had to take an entire day to do this. What was he going to do with the ranking? Cut the bottom 10%. This was serious.

I asked him, “Who’s going to rank us?”

He answered, “I will.”

I asked, “Based on what information?” He’d been there a week.

He replied. “I have my sources.”

Yeah, I bet he did.

The results of that ranking exercise? He managed to take a team of directors who had worked together well before that day, and make us a group of individuals. We were out for ourselves, because this was a zero-sum game.

At the end, no one was happy. Everyone was unhappy with the ranking, with the process, with everything about the day. This was no way to run an organization where people have to work together.

I’ve been a consultant for almost 20 years now. I have not received a formal performance review in that time. I’ve received plenty of feedback. Even when I haven’t enjoyed the feedback, I have liked the fact that I have received it.

And, that is the topic of this month’s management myth, Management Myth 25: Performance Reviews Are Useful.

Remember, I was inside organizations for almost 20 years. I received fewer than 15 performance reviews. Somehow, my bosses never quite got around to them. They hated doing them. I know that one of my bosses wrote them with help of Scotch; he admitted it.

Feedback is useful. Performance reviews? Not so much.

P.S. I know there is a comment on that article already. I am writing a response. The comment deserves more than an off-hand reply.

Categories: Project Management

Public Workshops March 17, 18, 21, 2014 in London

Tue, 01/21/2014 - 13:57

I’m offering three public workshops this spring in London again.

Monday March 17, I’ll lead an Introduction to Agile Project Management.

If you are wondering, “Does my company think I’m an agile project manager?” or “What is this agile project stuff?” or “Why is my responsibility as a product owner to get the project to done?” or “Why does my company think a Scrum Master is supposed to drive the project to completion?” or if you have a geographically distributed project team and your company says, “let’s go agile,” and you want an introduction, this workshop is for you.

You will learn enough about agile to know what questions to ask your team:

  • Can we work in timeboxes or flow?
  • How do we start if we don’t have all the requirements?
  • How do we start delivering features, not architecture or frameworks?
  • What are our impediments to thinking about transitioning to agile?
  • What do our customers really want first: release date, feature set, low defects, and how can we tell? (This is from Manage It! Your Guide to Modern, Pragmatic Project Management)
  • How do we work with product management/product owners?
  • How do we move from silos to cross-functional teams?
  • And much more

It’s an experiential workshop. That means we work by simulation and debrief. It’s fun to work that way, and you will learn a lot. This page has the details about Introduction to Agile Project Management.

Tuesday, March 18, I’m offering my Coaching Master class.

If you have been a technical leader, a manager, an agile coach, or even worked on an agile team, you have coached people. And, have you noticed that sometimes your coaching has gone awry? Or that your coaching is not as effective as you would like it to be?  In this master class, we will explore the coaching stances available to you. We will practice coaching. And, you will discover other possibilities you can take back to your work, whether you coach inside the organization or at a distance.

You’ll learn the differences between coaching, feedback, mentoring and teaching. You’ll learn how to coach, followup and how to create an action plan. And, you’ll learn when you tend to inflict help and how to avoid doing so.

This is also an experiential workshop. That means we work by simulation, interaction, and debrief. It’s fun to work that way, and you will learn a lot. This page has the details about the Coaching Master class.

Oh, if you are the gentleman who wanted to participate last year, but didn’t leave me your country code with your phone number, please sign up now!

March 21, 2014 I’m offering my Manage Your Job Search Workshop

If you are looking for a job, you know how hard it is. I can help you learn the system of the personal kanban. If you already know that, you can learn how to mine your career timeline to learn the kind of company culture to look for. You can learn how to express your purpose, so you know what to look for. Looking forward towards a job is much more effective than looking backwards.

We’ll address how you network, so your networking is as effective as it could be. And, we’ll address the traps that are making you less effective in your search right now. You’ll leave with many tips to energize your search right now.

This workshop will have many experiential and interactive activities. Be prepared to work! It’s at a rock-bottom price, too. This page has the details about the Manage Your Job Search workshop.

Do you have questions? Email me.

Categories: Project Management

InfoQ Interviews Posted

Mon, 01/20/2014 - 15:22

While I was on vacation in early January, there were two interviews posted on InfoQ:

Ben Linders interviewed Esther Derby, Don Gray, and me about the Change Artistry book. I’m really pleased about the way the interview came out. Thanks, Ben!

Back at Agile 2013, Shane Hastie interviewed me. The interview is here. We spoke about many things: the dangers of multitasking, hiring, and agile program management. We had a great time. I only with you could have seen Shane on camera too. Oh well.

Categories: Project Management