The PO is part of the team, get over it!

The other day I posted about charging a fine for being late to the standup. I knew this would get some reactions, but one thing I should have been clearer about was that this wasn't a team problem, it was a PO problem. Sure enough, several of the LinkedIn forums got fired up over it and some heavy hitters had some good points to make (thanks Rachel Davies!).

I agree that this concept can backfire (fine, I'll pay the fine so I don't have to come), and there are solutions to that (double the fine for each offense). I also agree that if the majority of people need a fine to appear at the standup, then there is a much bigger problem occurring.

So, that background aside... one of the conversations appropriately focused on the issues we were having with the Product Owner. Why didn't he want to participate? Why was this an issue?

Lesson learned on that point: when this company went agile, we trained the developers, then the QA and analysts. Following the rules of Scrum & XP, we understood the metaphor of the Chicken and Pig very well. Unfortunately by following this rule, we optimized the team but de-optimized the whole value stream. It wasn't until the PO's got some agile training that they understood how to evolve for the new agile world.

This post is in response to the following comment in regards to fining the PO for being late to the standup:

Why wait for the PO for a stand up? The PO should not be in a position to cause the problem. We try and utilize the Chicken and the Pig approach.

And my response:

There are many people who feel the PO is a member of the team: http://www.danube.com/blog/dan_rawsthorne/who_is_the_project_manager_in_scrum
Thus making them a Pig.

Also, the chicken and pig concept is dead in my mind. It's a coping mechanism for bad managers: http://www.langrsoft.com/blog/2008/08/pigs-chickens-and-asses.html

As our agile team matured, we found that many of our early retrospective discussions led back to the fact that the PO wasn't accessible enough. When your PO is the voice of many customers distributed globally, the PO is very important. If you have direct access to your customers (example: internal employees), then this might not be as important.

The last thing you need is for a team to go to the sprint review and demo lots of software that fails PO acceptance. Instead of making decisions in his absence and hoping they were right, avoid this waste and just treat him as a team member. If you can't do this, then get a proxy in place (lead analyst), or get direct access to the most important users to reduce the risk (beta customer).

Snake on the wall!

We found ourselves in a retrospective and there was a general feeling that there were a lot of interruptions in our day caused by "other people" outside the team. Nobody could put their finger on it and everyone had different unique examples. We couldn't easily say if we handle this problem or group of people then it will stop.

So how do you handle this?

Invoke the Snake on the Wall!

Every time a team member feels as though a task they are responsible for is delayed, they write it down on a post-it note. The note includes the time lost (compared to if they didn't have the delay), the thing affected, the cause, and their initials. They take the note and add it to the "end of the snake" which is a growing row of notes on the wall.

Over time the snake is monitored for repetitive patterns. The issues consuming the most productivity time are prioritized to the top of the list for the manager, scrum master, and team to focus on reducing or removing. Scrum masters look at it daily, managers look at it weekly (or when it grows suddenly), and the team reviews it right before retrospectives to trigger new topics. When an item is solved, those related stickies are removed from the snake and it is collapsed back down (you can't let it grow infinitely, otherwise you demoralize the team).

What does this accomplish?

• it validates real issues
  
• it kills false beliefs and misdirected complaints
  
• it quantifies the impact of impediments
• it creates transparency for managers who don't believe what you say
  
• it empowers the team
• it is immediate
• it self-prioritizes
• it uncovers surprises

On my last team we quantified for upper management how much time was lost EVERY DAY due to a bad source control system we were forced to use. It also provided insight into things we would never have thought were a problem. If used properly, it does a good job of quantifying the ongoing costs of certain types of technical debt.

So, I'm trying it a second time with my new group. We'll see how it goes.

5 minute retrospective...

Personally I view the retrospective as one of the most important parts of agile and one of the easiest first steps to implement. I find many of my peers agree with me. I've done personal retrospectives for self-improvement, and I've talked about retrospective accountability.

Peter Stevens wrote on the Agile Software Development blog about the challenge of working with a new team and introducing agile concepts. Knowing that "challenged" teams are so busy fighting fires that it's hard to interupt them even to make their sutuation better, Peter attempted to apply Ken Schwaber's idea of 5 minute retrospectives. Cue Bill Murray in "What about Bob" saying "baby steps" over and over again.

It's a good read and it furthers my belief that agile retrospectives are a agile practice gateway drug.

Retrospective accountability...

There is a post on InfoQ about insuring the changes proposed during retrospectives are followed through. This triggered a comment from me that focuses on the need for accountability in retrospectives.

Retrospectives are for the team to improve. The team should collectively own the meeting and not look at the scrum master or other leader to own the retrospective just because they are the facilitator. This is part of the self-empowered, self-managed team mantra.

When ideas come up in the retrospective, this same attitude should apply. Ideas aren't to be pitched over the wall for "somebody" to solve. The point of a retrospective is to uncover and improve. The team is doing something that can be improved, and unfortunately (Mr. Teammember) this means you have to be part of the solution.

Below is the comment I placed on the thread at InfoQ:

A by-product of working agile in a FDA regulated company was addressing this issue with documentation and therefore leading to a solution to this problem.

In retrospectives I ran then and still run today, each idea/topic is given an owner by the end of the conversation. Normally this is someone who volunteers, but sometimes we have to assign the closest person. The only time this wasn't true was if everyone agreed to do something, then the group was the owner.

In the next retrospective, we quickly review the prior retrospective topic list and review the outcomes. (Did we do it? Is it working?) If items are considered closed, we remove them. Sometimes items flow another iteration cycle or cause new conversations. The point is that there was an owner that should have run with it for the good of the team.

I call it the accountability cycle.

Improve yourself...

In a few weeks I transition from coaching our tech group within agile values, principles and practices, to training the "product" groups on many of the same concepts and starting to fold them into the agile culture. I realized pretty quickly that it was a good time to reflect on my past two years and think hard about how I approach this effort. Rather than easing into it, we're taking a more formal approach... and as a coach, I need to get along with people as I spend more time with them than I have in the past.

So, time for a personal retrospective.

At the end of a team retrospective I facilitate each month, I handed 3*5 cards out to each member of the tech team and asked them to honestly and brutally tell me at least one good thing and one bad thing about me. They looked at me funny, but after I explained why I needed this they asked for several more cards (funny, ha, ha).

What I got back was insightful. I'll spare you the 34 individual comments and share the most common:

• good: you don't inflict change
• good: you hear our concerns and adapt, you don't force us to do it by the book
• good: you presented the philosophies behind it instead of telling us just to do it
• bad: you talk to fast and cram in too much
• bad: you sometimes try to hard to help people and step on their toes in the process

There were many other insightful comments including the humorous remarks of my nerdiness, male pattern baldness, etc.

What's my point?

I'm proud of the fact that these people trust and respect me enough to give me honest feedback. I'm proud of myself for asking for it even if I felt like hiding in the corner as they scribbled on cards. I hope I have the guts to absorb this feedback and improve my coaching skills.

Peer reviews can be an amazing way to improve yourself if you are open to changing.

Do you have the guts to try it?

"No matter the circumstances you can always improve. You can always start improving with yourself. You can always start improving today." - Kent Beck

Is Conflict Allowed (@ sprint review)?

gaterxero ponders the question of whether a sprint review should cover negative topics. I'm not a fan of projecting a false front when there are problems.

My nugget: "The whole point is to bring your customer closer to the process and not delay the amount of time before they uncover the truth on their own. In my personal experiences, the most negative reviews/retrospectives lead to some of the best improvements and changes in the team."

Actually, I've had a few agile mentors who state that the best teams are the ones who handle conflict appropriately without shying away from it.

Additional viewpoints would help and he's asking for it, so feel free to click through and add your experiences and advice.