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

A friend and I were talking about getting fired the other day.

In my experience, most people who are fired are not unskilled or incompetent.

They may be in the wrong job, which means there's a poor fit between the skills, domain knowledge, preferences, and qualities needed to be successful and those of the individual. As likely, the person doesn't fit in -- there's a poor match between the values, beliefs, and assumptions that perdominate in the organization and those of the individual.

I'm not saying that some people shouldn't be fired. There are people who, for various reasons, won't (or can't) manage themselves well enough to make a positive contribution. When someone doesn't have the skills to be successful (or can't develop them in the time needed), that person needs to go somewhere else, either within the company if there's another place where they can contribute, or to another company. People who don't fit the culture probably need to move, too. Culture is incredibly stable in organizations, and one person swimming against the tide usually makes himself miserable and isn't particularly effective (although I think it's worth looking at what you can learn from the perspective of a cultural outsider to shake up your assumptions).

Note that none of these equate to "bad person."

But somehow that's what often comes across when people are fired. I've heard too many stories about people who were blamed, belittled, humiliated, or verbally abused when they were fired.

If the manager been doing his/her job, people know what they need to do to be successful, and know what they need to change to be successuful. And if those to things don't match up, it's the manager's job to move people on without making it a humiliating experience.

When someone doesn't have the appropriate skills or is a poor cultural fit, it's usually indiciative of a problem with the hiring process, not the individual. So why take it out on the individual? Blame and shame doesn't help either the person being fired or the person doing the firing.

posted by Esther Derby at 5:26:00 AM  

|

Diana has a couple of retrospective activities posted on her blog.

posted by Esther Derby at 1:21:00 PM  

|

I've pointed out in a few posts that the environment (system, processes, structures, culture) and management are a huge factor in performance in organizaitons. And they are. But sometimes, it is an individual problem.

Like this woman who works in a health care providers office processing insurance claims.

They have a visibility system in the office; the inbox and the out box. When the inbox is full, there's lots of claims to process. When it's empty, it either means there haven't been any patients or the claims processer is keeping up. As long as there are patients coming in, and claims are being processes, money should flow into the business.

Last month the office manager was in a panic. The inbox was empty, but the bank balance was dwindling instead of increasing. Of course an empty inbox could mean that there were no patients, but the office manager had seen a steady stream of people coming into the office for care.

The office manager suspected embezzlement or fraud and called the bank.

The bank told her there was nothing suspicious about the money going out, but that no money had been coming in.

It turned out that the claims processor wasn't doing her job, and didn't want any one to find out, so she stuffed the claims in her purse. It looked like she was keeping up. So much for the visibility system.

Clearly this is an individual problem.

But its also a management problem.

Maybe they need just a tad more in the way of accounting reports. Ya think? Not to check up on employees, to know the state of the business. I mean, you'd think a manager in a small office might notice that no money was coming in for several weeks.

When I heard this story, I asked if they'd fired the claims processor. They hadn't....because no one else knew the claims processor's job (another management problem).

I can't make this stuff up.

And one of the biggest mistakes people make is attributing individual problems to the system and system problems to individuals.

posted by Esther Derby at 7:39:00 PM  

|

This "help wanted" ad just came over one the of the Agile lists I subscribe to:

We have a PM spot open for a candidate with experience in an Agile environment! If this looks like a fit for you, please call or write me right away!!

Project Summary:

This project is focused on initiating and managing a project to prove capabilities of a vendor solution for [domain reference removed].

Position Summary:

The people in this position will plan, direct and coordinate the activities of the assigned project deliverables. They will work closely with internal IS staff and business partners to drive the implementation of the final solution. They will need to create and manage the project schedule and overall plan and will need to work closely with the Business and IS staff. The role will need to be heavily engaged with and develop strong working relationship with the business and owners throughout the project lifecycle.

I'm just not seeing much that matches Agile principles here. (The reference to "implementing the final solution" is unfortunate on a completely different level.) I guess "work closely with internal IS staff and business partners" could be be done in a way were "Business people and developers must work together daily throughout the project."

I see the purpose of an open position advertise me as attracting candidate who are a good fit for the job, and discouraging candidate who aren't a good fit. If this company (which shall remain nameless) is really looking for someone who has worked with Agile methods and understands the principles of agile software development, they may actually be discouraging qualified applicants with this language.

Now, I doubt the person who put out the position description has direct experience with agile methods. It's probably someone in HR, and he/she is probably using standard job descriptions.

If we want to improve our chances of attracting candidates who have worked in Agile environments, we need to work with the HR folks (as part of the extended project community) to source candidates who have the experience, skills, and qualities to work on an Agile project.

Unless we provide some sort of job analysis--the functional and collaboration skills needed, plus qualities preferences needed to be successful in the job--HR will fall back on their traditional descriptions.

HR owns many of the policies and procedures that can help or hinder Agile adoption. It's time we start working with them to create structures and systems that will help them help us.

posted by Esther Derby at 12:58:00 PM  

|

Mike Kelly has a nice post on diluting the power of appreciation.

My experience is that genuine appreciations can transform many situations. A couple of years ago I led a year-long project with a distributed team--no two members were in the same timezone. We had a weekly teleconference. I started every telecon with appreciations (and ended with hopes and wishes, which I'll talk about some other time). After appreciations--which took about 3 minutes--we got down to business. And everyone knew he/she was valued and that someone had notice his/her contribution in the previous week. And even when we had conflicts, we had that grounding to come back to.

This year, we get right down to reviewing action items (I'm not lead this year). To me, it feels brusque, and people seem grumpier and less inclined to give the benefit of the doubt. Same group of people. One small change in meeting protocol.

It's easy to dilute the appreciation by making it more removed, more abstract, and more general, because giving a direct appreciation requires making contact with another person. And making contact can mean vulnerability.

Here's the sorry path to dilution, starting with a direct person-to-person appreciation...

Harry, I appreciate you....

I appreciate Harry....

I want to appreciate Harry...

I want to thank Harry....

I want to thank Harry and all of you...

I want to thank all of you...

....and ending with meaningless sort of group thank you.

posted by Esther Derby at 8:13:00 PM  

|

Johanna has been blogging about finding candidates who have experience with agile methods.

So I've been thinking about the "typical" resume sifting process and how that might work/not work when you're looking for candidates who have worked on an agile team.

Typical resumes focus on specific technical skills, languages, tools or on functional experience. These are important, but might not be most interesting to me in looking for candidates if I'm using Agile development methods. Also, typical resumes rely on keywords. Keywords make for efficient searching, but not necessarily effective hiring when you are looking to integrate people into existing team or start adapting and adopting agile methods.

What I suggested to Johanna was to focus on agile principles rather than looking for specific "agile" keywords...which got me thinking: So why not write a resume around the principles behind the Agile Manifesto?

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity--he art of maximizing the amount
of work not done--is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

For each of the principles, the candidate describes what he or she's done--what practices and behaviors show that he/she understands and can apply the principles to developing software.

Even when you (as a person hiring) don't have resumes that focuses on principles of agile software development, ask questions that get a candidate talking about how they've applied the agile principles, rather than focusing on languages or specific practices.

Here are some of the question areas I suggested in my comment on Johanna's hiring blog:

Can she describe how her team adapted to changing requirements and delivered business value?

Can he describe how he and the team inspected and adapted both the product and their methods?

Can she give examples of how the team self-organized and worked collaboratively?

Can he describe how the customer worked with the team?

Just thinkin'

posted by Esther Derby at 10:38:00 AM  

|

Why do people fail to do what they are supposed to do? We're quick to pin the blame on individuals, when it may be a system problem or a management problem.

So to list just a few of the reasons some one might not be doing his/her job (or some aspect of it):

They think they are doing it. That's a mismatch between expectations or a mis-communication.

They don't know why they should do it. When people don't see a reason to do something, or the impact of not doing something, it may drop to the bottom of the priority list.

They think the what they are supposed to do won't work, or will make things worse. Let's face it some of the stuff that comes down from management is a crock. Like when I was told not to give feedback to any of the contractors on a project I was managing. So I'm supposed to let them continue doing something wrong that will jeopardize the project? I think not.

They think something else is more important. People do what they think is most important. And when priorities aren't clear, they do what they find most interesting or enjoyable.

There is some negative consequence (maybe not obvious) for doing some aspect of their job. Like following a new standard (like "all errors will be handled without terminating the program"), I'll have to sift through 1/2M lines of code in a legacy system, find all the instances that violate the standard, fix them, and test the fixes. Oh, and not miss the deadline on some other project.

There are obstacles outside of their control. Dependencies outside the team, lead-times on ordering equipment, facilities rules, policies, procedures....

Problems off the job. I worked with a guy who was dropping the ball with some parts of his job. When I talked to him, I found out that he was going through a messy divorce, and was spending a lot of time with lawyers and mediators. I got him hooked up with employee assistance for support and arranged time off for appointments. And that was enough to solve the work problem.

No one could do the job. Like trying to fit 10 pounds of rocks in a 5 pound bucket. Or completing a project or task in a time period that no one could.

System problems are management problems, not individual problems.

Incomplete communication about a task or job is a management problem.

Not setting context is a management problem.

Unrealistic expectations are a management problem.

That said, I've seen managers spend huge amounts--several hours a week for a period of months--of time helping one person reach minimum acceptable performance, and that's a mis-allocation of a scarce resource (management time).

So look at how the system may be contributing to the problem. And look at how you as a manager, might be contributing to the problem. Then fix the problem rather than affixing blame, and do it quickly.

posted by Esther Derby at 8:03:00 AM  

|

In reponse to yesterday's post, Ken Flowers commented:

...I've wondered if there are times when the retrospective should call out blame. That is, on some projects the real problem is that someone didn't do their job. I believe that this kind of feedback should be one-on-one, but that doesn't change the point that it is a personal problem not a process problem: "Joe messed up."

Maybe.

Maybe it is a process problem.

If this is an agile team--or any self-organizing team--where team members make performance commitments to each other not to a manager, Joe's not doing his job is a team problem, and it might be problem with their process.

I'd look at questions like these:

Why wasn't obvious (if it wasn't) that Joe was not finishing his work? Are the chunks of work too big, so that we don't know until it's too late that some one is stuck? Are we updating our "work remaining" estimates so that we can spot tasks that are taking longer? How can the team make status more visible so that problems don't hide?

What kept Joe from asking for help (if he didn't)? Is it part of our team culture to reward individual persistence and punish asking for help? What can we do to make it acceptable--even business as usual--that people ask for help quickly when they are stuck?

If everyone was aware that Joe wasn't doing his work, What is it about the way the team interacts that kept Joe's non-performance from being addressed during the iteration? Is the team avoiding giving feedback or shying away from conflict? How can the team improve their ability to address issues like this?

If Joe's done his job it the past, What obstacles (at work our outside of work) might have prevented Joe from doing his work this time? Can the team or coach remove the work-related obstacles? If the obstacle is outside work, can Joe get some support to remove it (maybe through an Employee Assistance Program)? If it's a temporary problem (e.g., a problem with day care or an illness) can the team accomodate lower productivity for a short time?

Is this work Joe likes to do? If it's scut work, is Joe always stuck with it? Is there a better way to distribute the scut work?

Does Joe have the skills to do the work? What does that mean for the team? Can the skills he does have be used more effectively? Can he reasonably develop the skills?

On the other hand, if this is a traditionally managed project where people report status to a manager, I'd wonder about how the manager was doing his or her job relative to the questions above. But then it's a management problem, not a team problem, and I wouldn't put the focus on Joe in the retrospective.

And I agree, on a team where people report status to a manager, feedback to Joe needs to be private. It might come from the manager, or it might come from a peer. (And I'd want to give feedback to the manager on the impacts to the team of not managing.)

AND even in a case where Joe plain old didn't do his job, it would be more helpful to give Joe information about his behavior/work results and the impact on the team.

Then Joe has choices:

He can choose to start doing his work, if he's been choosing (up until now) not to do his work.

He can make the courageous choice of saying he doesn't have all the skills he needs and ask to pair with someone to improve his skills or seek training.

Or Joe can move to another part of the company where he does have the skills to be successful.

And if Joe chooses not to do any of those (or can't gain the skills in the timeframe needed to meet organizational goals), the team coach or the manager can take the courageous choice to move him off the team. It's hard enough to build software with out carrying someone who can't or won't do the work. Some times no body is better than a person who is just a warm body.

(I know of self-organizing teams who move non-performers off the team without the coach or manager getting involved.)

posted by Esther Derby at 12:23:00 PM  

|

Recently someone asked how to avoid the blame game in retrospectives.

Here are three things you can do.

1) Establish working agreements (sometimes called "ground rules") at the beginning of the retrospective. These are contracts the group members make with each other about how they'll interact and work together during the retrospective. Some examples of Working agreements that I've seen groups use to stay out of blame are:

Use "I" language rather than "you" language when describing issues (e.g., "I was upset when the build broke" rather than "You broke the build!")

No personal attacks

Focus on the problem, not on personalities

Everyone in the group has responsibility to monitor working agreements, not just the retrospective leader.

2) Call behavior that violates working agreements. There's no sense having working agreements if the group ignores them. So if someone violates a working agreement, call them on it. Don't blame them, just call attention to the behavior. So when John says "If Henry hadn't been such a big baby we wouldn't be in this mess," say something like, "Hey, John, that sounded like a personal attack." 90% of the time, John will rephrase with out further prompting.

3) Don't leave an opening for blame. Use activities that give people a structured and constructive way to discuss issues and problems. Free-for-all discussions are much more likely to devolve into blame (or otherwise get off track), and that doesn't help anyone.

Blame erodes trust and groups need to have some level of professional trust to really face and solve problems. There's lots of other things you can do, and these are a good start.

posted by Esther Derby at 11:17:00 AM  

|