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

Last week I wrote about a middle manager who didn't consider renegotiating a low value project because he'd given his word to his boss.

The response to the post was consistent:

Ken Flowers said,

I have to assume that if the project doesn't make sense to the middle manager, it also wouldn't make sense to the VP. If I were the VP and found out that my manager was doing a project that he knew was ineffective, I would be really angry. I would expect him to talk to me about it first. I pay him for his judgment.

Dwayne Phillips posted:

Beware of promising things that are out of your personal control.

"I promise to look at this and get back to you"

"I promise to do what I CAN"

"I promise to investigate what this project means to you, me, my group, and our company."

On Ken's site, James Todhunter left this comment:

Concealing material information demonstrates a fundamental lack of integrity. I wouldn't want such a person on my team. I could never trust their input or judgement.

It's clear that a middle manager who continues down the wrong path because he "gave his word" is undermining how other people view his integrity.

What happens if we replace "middle manager" with "senior manager" and "boss" with "client" ?

I talked to an executive recently who promised a big client that his company would deliver a special project for them.

Unfortunately, he made a promise on the basis of incomplete information. Once he talked to his development group and ran the numbers, it turned out the work he promised will have a negative return on investment. And it's a double whammy: doing the low value work will delay doing higher value work, and cause the group to miss other targets.

But the executive refuses to consider going back to his client to explain the situation and renegotiate. He gave his word, and he feels his integrity is at stake.

How does the change in position and authority effect your response about the integrity question?

Labels: management

posted by Esther Derby at 9:40:00 AM  

|

I got a call from an acquaintance, Gloria, who is trying to convince her organization to adopt agile methods.

"I've given them every logical argument I can think of," she said. "They just don't get it. All I get is blank looks. How stupid can they be?"

"They" probably aren't stupid at all.

But they may have a different frame of reference, or a different mental model.

They may value something that isn't considered in Gloria's logical arguments.

They may agree completely with Gloria's argument, but don't see how to get to where she wants them to go.

They may be afraid that if they do what Gloria suggests, their managers will be angry.

What Gloria doesn't get is this: while logic is appealing, it isn't always the most effective tool for persuasion.

Rather than try to win through logical argumentation, Gloria might try understanding:

what other people value
what other people fear
what obstacles other people face
what problems they want to solve.

Labels: change

posted by Esther Derby at 10:13:00 AM  

|

Diana and I have one space left in the December 11-13 Secrets of Agile Teamwork in Portland, Oregon.

SAT is three days of experiential learning and practical tools to help you and your team reach the next level of collaboration and productivity.

Be the first to fax your registration and the spot is yours.

After that, its the waiting list.

Labels: agile, personal effectiveness, workshops

posted by Esther Derby at 10:06:00 AM  

|

An interesting interview with Jerry Weinberg here, at the Citerus site.

Some excerpts:

Q: You must have seen a whole bunch of ideas, about how to best do software development, grow and die over all those years. Do you see the agile movement as a pendulum swing or is it a move in a new direction?

A: How about a pendulum swing in a new direction? It's a pendulum swing because approximately every decade, there's a fresh movement to "solve the programming problem." High-level languages, structured programming, object-oriented programming, ...

But it's a new direction because it's the first movement to focus largely on social processes rather than purely intellectual ones. For that reason, I believe, it has more hope for success than the earlier movements, each of which made a little progress, then largely ran out of steam before achieving its grand promises.

Of course, agile won't achieve all its grandest promises either, given the conservative nature of human beings, but that's all right. After another dozen decades or so of incremental improvement, we'll begin to see some really fine software development. Well, I shouldn't say "we," because none of us will see them, but at least our great-great-grandchildren will be able to look back at us and laugh at our crude methods.

Q: If you're the J.K Rowling of software development, who's Harry P then?A: Well, first of all, I'm not a billionaire, so it's probably not correct to say I'm the J.K. Rowling of software development. But if I were, I suspect my Harry Potter would be a test manager, expected to do magic but discounted by software developers because "he's only a tester." As for Voldemort, I think he's any project manager who can't say "no" or hear with Harry is telling him.

Labels: agile, management

posted by Esther Derby at 12:04:00 PM  

|

I talked to an middle manager recently who promised his VP that his group would deliver a special project for the VP.

Unfortunately, he made a promise on the basis of incomplete information. Once he talked to his group and ran the numbers, it turned out the work he promised will have a negative return on investment. And it's a double whammy: doing the low value work will delay doing higher value work, and cause the group to miss other targets.

But the middle manager refuses to even consider going back to his boss to explain the situation and renegotiate. He gave his word, and he feels his integrity is at stake.

I think he's leaving something out. In standing on "integrity," he's considering self, but not the context or the other people involved. What about the financial integrity of the company? What about the people who have to do the work, and will work overtime to meet other commitments, or experience consequences when they miss other dates?

There's another part of integrity that involves cleaning up your own messes.

Labels: personal effectiveness

posted by Esther Derby at 11:48:00 AM  

|

I've been watching a discussion on the Agile Project Management yahoo group, which poses the question, "Does everyone in agile need to be above average?"

The question behind the question is, "Does agile need extremely competent people in order for it to work?"

When I read stuff like this, I wonder "What method of building software works without competent people?" It's a puzzle.

Which brings me to this snipped from Bob Sutton (via Jason Yip):

Great systems are more important than great people. The notion that you are doomed to mediocrity if you can’t hire the very best people has little empirical support. Yes, there are big differences between the most talented people and the next level down in most occupations. But systems are more important. Toyota beats the competition as a result of a superior system; Men’s Wearhouse and McDonald’s don’t hire people that are much different from their competitors, but their systems explain their long-term dominance more than their people. As Jeff Pfeffer says, many organizations seem to have “brain vacuums” to turn people who seem to be smart into bumbling fools. Even the most brilliant person is doomed to fail in a bad system, and seemingly mediocre people can become stars in a great system.

Agile methods are a system that can help people perform better.

One agile coach I know tells a story about the first agile pilot in her organization. Someone in senior management didn't want the pilot to succeed. So he sent her all the "poor performers" for the pilot team. But they ended up outshining expectations and did a fine job of delivering valuable working software.

Further, focus on individual talent (and focus on individual performance management) takes focus off improving the system.

(I'll say this now, because someone always asks at this point "So you're saying we should hire incompetent dodos?" No, I'm not saying, "hire dodos." Hire competent individuals who are a good fit for the organization's culture. Focus on improving the system to improve results. Focus on individual performance for career development. Give feedback to help individuals become more effective.)

Labels: agile, management

posted by Esther Derby at 2:12:00 PM  

|

Wanna know? Read it here: My article What Every Manager Needs to Know About Feedback is posted at CIO.com.

posted by Esther Derby at 7:47:00 AM  

|

If you've been holding iteration retrospectives for a while, you know that timelines get old after a while. But when team skip the data part, each person works from his own data (which other people may not know) and his own interpretations (which other people may not share). That means that the team is less likely to come up with actions that have broad support.

So here are two more fairly quick ways to gather data for an iteration retrospective.

Diana describes FRIM, an activity that looks at the frequency and impact of events, impediments and boons that affected the team during the iteration. Use this as input into analysis and to decide on experiments and changes for the next iteration.

Jean Tabaka used a sailing metaphor to gather data at the Retrospective Facilitators Gathering retrospective. She asked us to identify events, interactions, etc that put wind in our sails. Then she asked us when we were in the doldrums, becalmed or held back by tides and current. We put up the "wind in the sails" stuff behind the boat, filling the sail and the doldrums stuff in front of the boat. The metaphor helped keep us out of habitual thinking and automatic categorization. And it was kind of fun.

Labels: Retrospectives

posted by Esther Derby at 7:27:00 AM  

|

I just came across this nice review (written by Brad Appleton) of Agile Retrospectives: Making Good Teams Great on AgileJournal.com. For me, "useful" is the highest praise for a book.

Labels: Retrospectives

posted by Esther Derby at 5:04:00 PM  

|

Diana and I are offering Secrets of Agile Teamwork this June 5-7, 2007 in Portland, Oregon. This is a public workshop, open to 12 people.

We'll be focusing on the interpersonal skills that enable people to be effective team members. We'll be looking at communication, conflict, shared leadership, and forming and nurturing teams.

If you want to be the best team member, ScrumMaster, or coach you can be, join us for three days of learning and fun. Download a registration form here.

Labels: agile, self-organizing, teams

posted by Esther Derby at 8:55:00 PM  

|