Is everyone on your Agile team happy?

I was reading blog post on the New York Times web site today called "The Secret to Having Happy Employees, by Jay Goltz." He describes his two-part method for having happy employees. Part one: treat people well. Part two: fire the people who are still unhappy even when you treat them well.

As a manager for around 12 years, I've fired people on occasion. It's always unpleasant. But keeping an employee who is unhappy is pretty unpleasant too, and it can undermine everything else you are doing.

Over the past couple of years, I've spent time talking with people who have introduced Agile development practices into both new and existing teams. I've also brought Agile methods (Scrum initially, then engineering practices including test-driven development, common code ownership, user stories, continuous integration, etc.) into the team I've run for the past 3 years.

For what I've seen and heard, most people are neutral-to-happy about adopting Agile methods. Some people love them. And a few people are unhappy about it.

One of the basic principles of Agile development is to treat people as individuals, trust and respect them, and give them the support they need to do the job. To me, this sounds a lot like Jay Goltz's "Part one."

What do we do about Part two? If someone is really unhappy even when trusted, respected, and given the tools to do their job, what do you do about it?

Island of Agile

Last month I went to Agile Open Northwest. I co-lead a session about being Agile in an organization that is not. At one point someone asked "Why would you want to be an island of agile?"

I thought to myself, wow, that's a great title for a blog. So here is my blog on being an Island of Agile--running an agile team inside of an organization that is not.