"Poor management can increase software costs more rapidly than any other factor." (Barry Boehm)

Yesterday I came across an article by Stever Robbins on the HBS site that talks about handling strong emotions at work. Progress!

I wrote a little piece for stickyminds a while ago, First Things First. My premise was (and is) that believing emotions have no place at work doesn’t make them go away… ignoring emotions cause them to slurp out in odd and unexpected ways. Our brains are wired for emotion… so what part of our brain would we leave at home if we checked our emotions at the workplace door? My piece looks at acknowledging emotions so that people can actually focus on the work.

Stever’s article looks at a more volatile situation. The situation he describes is this: There are 3 VPs and one is promoted. The other two aren't. What happens next isn't pretty: This has led to resentment among the other team members. The fallout has been demotivation horizontally and vertically.

Emotional fallout - anger, jealousy, resentment - aren't reserved for overlooked VPs.

These emotions can bubble up at any level. I see this a lot when one person is promoted from within a group. At best, these feelings are transitory. People deal with it and move on. At worst, one person holds on to his resentment and turns his anger towards the person who was promoted:

Sarah was promoted to manage the group of developers she'd worked with as peers for three years. John, one of the developers, believes that he deserved the promotion that Sarah received. He starts looking critically at everything Sarah does. When Sarah tries work collaboratively with the team on setting priorities, John interprets her actions as trying to get other people to do her job. He speculates on how he would do things and judges Sarah harshly when she does things differently than he would. Pretty soon John is tearing Sarah down to other team members and snipping at her in meetings.

If you are managing a group where you see this happening (whether it's related to a promotion or not), consider Stever's advice for working through the emotions.

But what if you recognize yourself in this story?

Shift the focus off the other person and see what’s happening for you.

Start with the facts: some other person gotten a promotion.

Look the meaning you’re making of the facts. What is the story you are telling yourself about the situation?

What feelings do you have about the situation?

How do you feel about having that feeling?

What happens if you tell yourself a different story?

posted by Esther Derby at 11:44:00 AM  

|

I came across this post on Brian Marick's blog:

In his second post, Jonathan [Kohl] quotes James Bach: "... testers are critical thinkers -- and critical thinkers are disruptive." I don't think that need always be true. One can be a critical thinker but not a critical speaker. One can post-process the thoughts and use them to guide progress in a non-disruptive way. [snip]

I agree. Actually, I'd go a further: critical thinkers are more likely to get their point across when they are not critical in their delivery.

When I train technical review leaders, managers, or facilitate retrospectives, I coach people towards "I" language. Starting with "You" as in "You did this," or "Your code is wrong," sets people up to be defensive.

It's more effective to say something like "The code [project plan, spec...fill in the blank] is confusing" or even better "I don't understand the code." No one can argue you out of that, and they're more likely to want to find out why (and then fix it).

posted by Esther Derby at 5:52:00 PM  

|

I'm at a Jerry Weinberg's writers workshop this week with bloggers Johanna Rothman, Keith Ray, Dave Liebreich, Dwayne Phillips and a bunch of other fine folks.

posted by Esther Derby at 8:33:00 AM  

|

Sorin pointed out in his comment on my earlier post that burnup charts make changes to scope explicit, while burndown charts do not.

I’d say, Yes, Sorin is correct. And No. And, I was not explicit in my use of the word scope. So I’ll try to clarify.

Burnup and burndown charts start from a different set of assumptions about change.

John Brewer describes one of the benefits of using a burnup chart with a finish line: …based on that extrapolated curve, you can graphically show managers the impact of scope changes. "See, we were going to finish around here, but because of the new requirements, we're going to have to do _this_ much more work, so we're going to finish around _here_."

And: Tracking the history of the finish line is useful for presentations to top management. "Why is the project late?" "Because you moved
the finish line."

Burnup charts assume a relatively fixed scope that says “when we finish all these stories, we are ready to release.” The finish line changes when someone (management or the customer, we assume) adds or removes stories from the scope. Developers can also change the finish line when they discover that a story was more complex or difficult and they break it up into additional stories.

I would use burnup charts on a project that was working towards a relatively fixed scope.

But, if I were working on a Scrum project, where the project is managed empirically, I’d use burndown charts.

Scrum assumes that rather than attempt plan deterministically, it’s more effective to obtain frequent feedback both on how the team is making progress and on how the product is shaping up.

The product owner sees working software at the end of every sprint. Once he has his hands on the product, he may see new things to add, or he may realize that the product has significant value as it is.

A Scrum project could have 3 burndown charts, each associated with a different backlog. Each shows the estiamated effort remaining (rather than stories completed).

The burndown for the product backlog shows estimated effort for all the remaining desired times for the product. It’s sort of the grand product wish list. I’d expect to see the product burndown go up and down as the team finishes features and the product owner adds new desired features. This shows how the product is shaping up. Reaching 0 may mean the product is fully mature, there aren’t any new ideas to go into it.

The product owner allocates features from the product backlog into probable releases. The burndown for the release shows how the team is progressing towards meeting the desired release date. If the slope of the line on this chart shows that work is progressing more slowly than anticipated and the product won’t be ready by desired release date, then the product owner and management can make choices that will help to meet the date or they can change the date.

The team has a sprint burndown that shows how they are progressing on the goals for that particular sprint. At the beginning of the sprint, the team bites off a chunk of the top requirements, as much as they believe they can accomplish during one sprint. If they find something is taking longer or is more complex, the effort remaining goes up. If the learn that something is more difficult than expected they add to the effort remaining estimates. That shows up as an up-tick in the burndown. The team uses the sprint burndown to get better at estimating. Within a sprint, there is no external person saying “add requirements to scope.”

So it comes down to different ways of thinking about and managing change within a project. Burndown and burnup can both be useful, and it depends on the context.

posted by Esther Derby at 8:25:00 AM  

|

I've talked to a bunch of people lately who tell me they are doing iterative development. When start asking questions, it sound more like they're doing something between iterative development (as I think of it) and waterfall: All the requirements are done up front, the development team works on some set of requirements for two weeks, and then turns over to test. The developers are still putting in long hours to meet iteration goals, and project managers are focused on tasks and dates. The product owner doesn't see the product until the dev team is done with all the requirements (or time runs out).

I suspect they gain some benefits from doing this, since testing is spread out through the effort.

And I think they're missing the big benefits of iterative development -- managing schedule and requirements risk.

If you want to get the most out of iterative development

Prioritize requirements. Always work on the top priority requirements. The product owner gets to reprioritize at the beginning of each iteration.

Save the detail requirements definition until you're ready to work on that chunk... things will most likely change between the time the product owner has the idea and when the team starts working. And people always learn more as they work with the ideas.

Get feedback from the product owner, customer, or customer surrogate at the end of every iteration. If the feature isn't quite right, fix it in the next iteration.

Use information from each iteration to improve estimates. Say the development team thought they could complete a chunk of functionality estimated at 400 effort hours in 2 weeks. At the end of two weeks, they find they've only finished half of that chunk. Adjust the expectations for the next iteration accordingly, and don't promise more than you were able to complete in the previous iterations. Look at what factors caused the difference and take action based on what you learn.

Use burndown charts to show progress and predict completion. Task oriented project schedules attempt to determine what will happen in the future and then attempt to force reality to meet that model. Burndown charts show how much work is left and how fast it's getting done. Burndown charts show what is actually happening and allow decisions based on what is, not what we wish would be.

posted by Esther Derby at 8:08:00 PM  

|

From Fast Company, Elizabeth Pagano offers a handful of reasons that managers avoid having conversations with employees about performance:

"Eleven Things We Tell Ourselves to Avoid Giving Bad News."

I don't think she can handle it.

I'll hurt his feelings.

She will get emotional.

He will get defensive.

I'm sure that she already knows.

He should already know.

She will think that I'm singling her out.

It's only my opinion.

He will think that I do not like him.

It will ruin our relationship.

The situation may take care of itself.

I'll add a few more I've heard

It will hurt his career. (!)

It will hurt the team spirit.

It's not my place. (!)

It doesn't happen all the time.

I don't understand the technical aspects, so I can't coach her.

I let it slide before, so I can't tell him now.

I didn't see it happen, so I can't comment on it.

That's just Fred.

What if Fred gets pissed and quits?

If I have to fire Fred, I won't be able to replace him.

I suspect that underneath these reasons is a more personal reason: "I'm not sure I can handle what will happen."

Feedback is hard, and most of us don't have useful models for how to give feedback to employees (or peers). And, in my experience, failing to give feedback carries a higher price than not giving feedback: it destroys trust and drags down morale.

posted by Esther Derby at 6:51:00 AM  

|

I'm on the road, and living with limited access, so I won't be saying much this week. But I'm sure I'll have lots to say when I'm back in my office.

posted by Esther Derby at 7:03:00 PM  

|

I came across Joyce Wycoff's site this morning. She's got a couple of riffs on phrases that shut down thinking. You've probably heard most of them...

Yes, but....
We tried it last year.
It’s not in the budget.
It won’t work.
Management won’t buy it.

the great part is that there's an antidote (that Wycoff calls a Leap Stimulator) to every crushing phrase:

Killer: Yes, but ...
Leap Stimulator: Yes, and ...

Killer: We tried it last year
Leap Stimulator: What did we learn that could make this try better?

Killer: It’s not in the budget
Leap Stimulator: How could we make it make sense financially?

Killer: It won’t work
Leap Stimulator: How could we make it work?

Killer: Management won’t buy it
Leap Stimulator: What would make management drool for it?

Full posts here and here.

posted by Esther Derby at 6:14:00 AM  

|

Back in January, I posted a bit about management behavior that drives people out the door. Managers don't have a lock on jerk behavior. Just look at this thread on Ask Joel.

There's a lot of energy there.

I am particularly struck by a couple of people explaining when and why they "act like a jerk." It sounds like they feel they must "act like a jerk" to protect their own time.

So let's take a leap and play out a scenario:

Suppose Fred comes to Joe with a problem he could easily solve if he looked at the release notes, or read the last few emails Joe sent.

1st time:
Fred: "Joe, how should I write the blah, blah class?"

Joe: "It's all in the email I sent yesterday. Basically you do...." And Joe goes on for 20 minutes explaining how to write the class.

2nd time:
Fred: "Joe, how do I recreate the error condition in the floo feature?"

Joe: "It's all in the release notes. Basically you do...blah blah blah." And Joe goes on for 20 minutes explaining how to recreate the error.

3rd time:
Fred: "Joe, how should I test this without going through the GUI?"

Joe: "Do I have to hold your hand on everything? I'm not wasting my time doing your job for you!"
Joe: [to himself] What a clueless idiot. He could at least read the background.

Now Joe is acting like a jerk.

In the first two interactions Joe placates Fred by giving more than he really wants to give, and downplaying his own needs. Joe starts feeling resentful. By the third round, Joe blames Fred when he asks for help (paying attention to what he needs, but dismissing Fred).

Fred may have no idea that Joe has an expectation that he should read the background before he asks questions. He may have no idea that Joe has other pressing work to do. Joe may expect him to know, but Fred isn't a mind reader.

Its sort of like: "He/she didn't take the hint, so I had to be mean to him/her. I'm really mad he/she made me be mean."

I think this is a pretty common escalation.

What would happen if it went like this:

Frank comes to Jim with a problem he could easily solve if he looked at the release notes, or read the last few emails Jim sent.

1st round:
Frank: "Jim, how should I write the blah, blah class?"
Jim: "Frank, I've got a ton of stuff to do before 3:00. Did you read the emails I sent? The answer is in there."

2nd round:
Frank:"Jim, how do I recreate the error condition in the floo feature?"
Joe: "Frank, did you look the release notes and my emails about this problem?"
Frank: "errr. well, no. I though it would be quicker to just ask you."
Jim: "Look at those and then if you still have questions, ask me. I have some time at ________."

If Frank has looked through the release notes, Jim can choose whether to help Frank now, or later, or not at all. (And consider that possibly, just possibly, the release notes and emails may not be clear to the people who need to use them.)

3rd round:
Frank: "Jim, how should I test this without going through the GUI?"

Jim: "Frank, did you look the testing documentation?"

Frank: "errr. well, no. I though it would be quicker to just ask you."

Jim: "Frank, this is the third time you've come to me for help without first checking the background material. When you don't do the backgound work before you come to me with questions, I feel like you don't respect my time. Please check the background material before you come to me for help."

(Maybe you say this the first time... your level of tolerance may be different than Jim's.)

In the second scenario, Jim balances his need to protect his time, Frank's need for info and the context of getting work done. And he doesn't sound like a jerk.

In any interaction there's you (the self), the other person and the context. When all three are in balance, you can protect what fits for you without blaming the other person or acting like a jerk. And if you placate, well, sooner or later, the seesaw will tip, and you'll go to blame.

posted by Esther Derby at 9:12:00 PM  

|