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

One of the participants in my session (the session Diana and I did together) on Agile Retrospectives at Agile2006 asked how a retrospective differs from a sprint review where the team demonstrates working software.

Demonstrating working software to the customer (in addition to demonstrating value) is an inspect and adapt cycle for the product. The customer looks at and runs the software to ascertain whether the software is doing what it’s supposed to do and offer corrections. And, the customer may see new possibilities once he interacts with the software.

Retrospectives are an inspect and adapt cycle for teamwork and methods. The team looks at their interactions and their engineering methods to determine where they need to adapt.

One of the principles behind the Agile Manifesto states: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

Retrospectives are the mechanism for the team to do that.

posted by Esther Derby at 4:39:00 PM  

|

Yippee!

You can order it from the Pragmatic Bookshelf here or from amazon.com: Agile Retrospectives: Making Good Teams Great

posted by Esther Derby at 2:12:00 PM  

|

Johanna has a post about feedback on her blog...based on a feedback practice from our recent Managing One-on-One workshop.

In her post, a feedback giver hints and talks all around the situation, rather than respectfully but directly describing the situation and the impact.

Using hints and indirection is common feedback error. Feedback givers fall into the trap of trying to "soften the blow" -- and end up confusing the feedback receiver.

What happens next is even sadder.

The hinter gets mad at the hintee for "not getting it." The hintee delivers another hint, this time with an edge. The hintee feels more confused, and wonders why the hintee is upset with him/her.

Finally, the hinter gives up hinting and delivers a blast, while blaming the other person for "forcing me to be mean."

It's kinder to be direct. Indirection only saves the hinter from the short-term discomfort of an awkward conversation.

posted by Esther Derby at 1:58:00 PM  

|

Yesterday I talked to a friend of mine who was disenchanted with work…which is a new development for her. Up until now, she’s been very positive about her work environment. “What happened?” I asked.

Turns out that the manager of her group looked at her team and decided they were "too cliquish." So he broke them up.

He moved the team lead to another group, re-configured positions and brought in a new team lead. Several of the old team members decided to move with the old team leader—and took their experience, domain knowledge, and context knowledge with them.

The new team leader brought in people he’s worked with before. The new team members are on a learning curve; they have the general knowledge for the job, but don’t know the specific domain or the workings of that part of the business. They haven’t yet established working relationships with the remaining old team members.

The old team members feel that the new team lead giving the people he brought with him preferential treatment.

Important work is falling through the cracks. Both the old team members and the new team members feel it’s more “us and them” than a true team.

In short, it’s a mess.

Sad to say, I see this fairly often. Someone looks at a tightly bonded team and decides they are “too cliquish.”

Teams that are performing well are tightly bonded. They have a sense of who they are and what they can do. And they celebrate that. It’s team identity – and it’s a normal part of being a high-performing team.

I can image a case where a team is "too cliquish"—which I’d define as not looking outward to the needs of the organization and not doing the job the team was chartered to do. But before I broke up the team, I’d work with them on what the real issue is: not getting the right work done.

It seems though, that some managers make the judgment that a team is "too cliquish" without looking at results—as if tightly bonded teams are by definition a bad thing.

posted by Esther Derby at 8:57:00 AM  

|

The last couple times I put up a post on blogger, the tool bar didn't show up in the post editor.

Very strange. Especially since the tool bar "officially" works with IE, which is the browser I was using.

After tweaking settings and uninstalling updates, I downloaded Firefox. The tool bar is back. I will allow you to draw your own conclusions.

And, now that it's easy to add links again, I added some to yesterday's post.

posted by Esther Derby at 1:34:00 PM  

|

I define feedback as information – not evaluation. Managers do need to assess results; but providing information about results (or behavior) is more effective than making a statement that evaluates the person.

That means no blaming statements like, “You’re lazy” or “We’d be on schedule if you did your job!”

While blaming/labeling may provide short term satisfaction to the blamer, blame and labels don’t help people know what to do differently to be more successful. More often, blame provokes defense.

It also means no praise. That’s right, no praise.

When I say this, I get funny looks.

We’re conditioned from an early age to seek praise from our parents and teachers. Early writers on interpersonal skills in business advised people to be “lavish with praise.”

Praise may make the praiser feel good. Praise may make the person receiving praise feel good, in the short-term. In the long term, praise (and other rewards) erode intrinsic motivation, decrease engagement in the work, and focus people on pleasing the boss rather than understanding how their work contributes to the success of the organization.

Praise and blame are two sides of the same coin: both are evaluations of another person.

Here’s what Marshall Rosenberg has to say about praise in an interview from 2005:

“…we consider praise and compliments a violent form of communication. Because they are part of the language of domination, it is one passing judgment on another. What makes it more complex is that people are trained to use praise as reward, as a manipulation to get people to do what they want.”

Praise is a form of manipulation—and most of the time people can tell. If you want to appreciate someone, do it genuinely and directly, not in the form of praise.

Later in the interview he tells a story about a woman who approached him after a talk to tell him he was brilliant. Part of his response to her effusive praise:

“…I could never recall learning anything of value from someone telling me what I am. I don't think anybody does…”

Praise doesn’t help; it doesn’t give people useful information. Further, Alfie Kohn’s research shows that it actually hurts.

The point of feedback is to improve working relationships and work results. So provide information that will help a person make choices. No praise, no blame,

posted by Esther Derby at 10:54:00 AM  

|

I'll be attending the Agile Conference next week, right here in Minneapolis.

Monday: I'll be part of the beginner track, talking about Team Dynamics.

Tuesday: I'm helping Erik Meade out with his Extreme Teams session.

Thursday: Diana Larsen and I have a tutorial on Agile Retrospectives. Pre-registration for this session was huge, so we may offer the session a second time.

So stop by and say hello.

ED

posted by Esther Derby at 11:54:00 AM  

|

When I teach about feedback, I make a distinction between change-focused feedback, reinforcing feedback, appreciation/gratitude, and encouragement.

Feedback is information that we hope will influence future behavior.

Change-focused feedback is information about a behavior or result that the feedback giver would like to see change. For example, "Jane, I notice that you've come 15 minutes late to our last three staff meetings. When you arrive late, it disrupts that meeting and we have to re-visit topics that we've already covered."

Reinforcing feedback is information about a result or behavior to that's working well--something to continue. For example, "Jane, as I read your report, I really noticedd the way you've presented the evidence. Each fact builds upon the previous data. The way you've organized this report makes it easy for me to follow and builds a compelling case."

This is different from saying "Your report was very effective," which doesn't give Jane any information about what made the report effective.

Encouragement and appreciation/gratidute aren't really feedback. None-the-less, they're important because they build relationships by letting people know you notice them and their efforts.

Encouragement is an expression of support, such as "way to go" or "keep it up." Encouragement inspires confidence and heartens.

Apprecation or gratitude is telling someone that you've noticed something they've done that's had a positive impact for you or the team. I use a specific form: "[name of person], I appreciate you for showing me how the build works."

(I started emphasizing this distinction after a fellow told me he was going to give his wife some re-inforcing feedback on cleaning the kitchen. eerrr... not a good idea. Appreciation would be a better choice. "Honey, I appreciate you for cleaning the kitchen...it's so nice to come home to a clean kitchen.")

posted by Esther Derby at 6:11:00 AM  

|