Friday, January 20, 2012

White Elephant Planning

In a previous post, I discussed an agile estimation method called the White Elephant method. In that post I discussed some concerns that I had on it, but also noted that these concerns were not founded by any actual experiences with the method itself. Now that I've actually been a part of one, I wanted to share some things about it that I noticed.

In my environment, we have 5 teams of approximately 7 people. Our product owner wants to have a single backlog for all teams. In order to fill out the backlog for the next release, we held a story estimation workshop that consisted of a representative from each team, plus the product owner. The product owner (along with some help) prepared by creating around 40 stories with descriptions and acceptance criteria. We time boxed the meeting at 3 hours and had lunch catered so we wouldn't have to stop. We usually went for about 45 minutes at a time with a 15 minute break in between.

The Game
Out of the 3 hours, we probably spent a little over 2 hours actually estimating (we started late, had some issues with lunch, etc). The product owner was hoping to get at least half of the 40 stories estimated. As it turned out, we got them all done! Just based on that alone, I would consider the exercise a complete success.

I have to say right off that in order for this to work well, you must have a good moderator. Fortunately, we had someone that had done this before and he did an excellent job. He had a stop watch running on his phone and reset the timer each time a new story was selected. Once the timer reached about 4 minutes, he would let us know and try to push the current player to park his story in the 'Parked' column for later discussion so we could move on. Without this type of moderation, we could have talked on and on and the whole exercise might not have been as successful as it was.

Less Discussion
There were several occasions where a player muttered under his breath when it was his turn that he didn't agree with the placing of a previous story but decided not to use his turn to move it because he didn't want to re-open the discussion again. This only happened when there a one point difference between what the story was currently estimated as, and where the player thought it should be. This was interesting to me because not only did we cut down on more discussion, but the player immediately recognized the cost of such discussions and decided that it wasn't worth it over a one story point difference. I struggle with my own team on this sometimes. I don't like having to remind team members during planning that while the discussion they're having about the story is important, it's not going to make any significant difference in the planned estimate and should be taken offline. I really like seeing the player come to this conclusion on their own with the White Elephant method.

Tuning Out
I'll be the first to admit, that it was easy to tune out. When it wasn't my turn, I caught myself several times paying less attention to the current discussion of a particular story. Once the story was placed on the board, I really didn't know much about the story and therefore wasn't able to contribute to its estimate. It was too easy to just say, "I'll be happy with whatever he thinks it is." Since this was the first workshop for us, it consisted of all team leads, so most of us had strong opinions about the stories. I see the tuning out problem being more wide spread on teams with members that just go with the flow more. Planning Poker requires the team member to decide on a number, and then possibly defend it if it doesn't match the rest of the team.

I was surprised to find that some of the things I thought were going to be issues were not at all. Anchoring wasn't a problem for us. Players regularly took a turn to move an estimate and would confidently say, "No way this is a 3 because...". Then again, that might be due to the combination of personalities in the room. I also didn't find changing the discussion from story to story to be a problem. I never once felt that it impeded my ability to estimate.

Once of the biggest things I took away from this is that most of the positives I saw could be easily applied to Planning Poker. Timing story discussions, parking stories that take too long, visually seeing the stories and where they're placed in relation to each other. I'm definitely going to apply some of those things in my next planning meeting with the team.

Wednesday, January 18, 2012

Code Presentations or Code Reviews

When I sit down and participate in a code review, I get annoyed when the person who's code I'm reviewing just sits back and says "Here you go, have at it." That communicates to me that they are not a participant in the review and they're not taking pride in their work. When someone sits down to review my code, I actually prepare for the review and I think a moment about the best way to present it to them. I almost feel like I'm trying to sell my code to them, although I recognize that it's not about "selling" anything, but sharing knowledge and finding alternative solutions. I am more in the driver seat when someone is reviewing my code because I'm interested in their input and want to know if they see any problems. Part of the problem with poorly executed code reviews may be because they're one sided, and thus the concept of what a code review is and why we have them is not in line.

I'm going to throw myself out there and ask, what if I called it a Code Presentation? That puts more emphasis on the person who wrote the code than the person reviewing it. If someone were to say "Hey, can you come by so I can present my code to you?", they may prepare a little more and think more about how the code looks to an outsider rather than just getting the code to work.

I know, words are words. What you call something doesn't change what it is. I can call the chair you're sitting on an ice-cream cone if I wanted; it's still a chair. However, what you call something may change the perception of what it is, even though it's still the same thing. That change in perception may be enough to close the gap on the reason behind code reviews.

Dumb? Interesting? Pointless? I'd like to know your thoughts on this.

Friday, January 13, 2012

Alternative to Planning Poker

I recently came across an agile estimating method called the White Elephant method that is designed to speed up agile estimation. One of the complaints that new practitioners have when it comes to Agile is that planning takes too long. I definitely agree with this and have seen new teams plan well into 3 days for a 3 week sprint. If your team is having this problem, you might consider the White Elephant method.

Quick Overview
You can read the link above to get a good idea of how this works. In short, you do the following until all of your stories are estimated.
1. Create categories on a white board to represent each of the story point values (0,1,2,3,5,8,etc.).
2. The first person takes a story from the pile and places it on the board in the category that represents their estimate.
3. The next person can either change an existing estimate by moving a sticky on the board to another category, or select a new story from the pile and place it on the board.
4. The next person takes a turn and so on, until all stories are on the board and the team has consensus.
5. If a story is moved too many times (say 3 times), the story goes into a Discuss category.
6. At the end, any stories in the discuss category are discussed and eventually placed on the board.
The main idea is to get points on the stories that don't require much discussion first, then discuss the ones that may require clarification second.

My Thoughts
First off, I have to say that I have not yet taken part in this yet. Anything I have to say on this is really just my hypothesis. 
1. Anchoring - One of the things I like most about Planning Poker is that everything presents their estimate at the same time as to avoid any anchoring that might occur. That's why we do planning poker. I don't want my estimate to anchor the next guys one way or the other. This is especially true in teams where one or two people have stronger personalities than the rest and are more assertive in what they think. The White Elephant method allows one guys estimate to be swayed by what he sees on the board and the quieter folks on the team may be more inclined to just "go with it".

2. Go with the Flow - I have a lot of respect for people that are able to go with the flow. However, I don't like those folks during planning meetings. As a team lead, I make it a point to ask those people what they think because it's all too easy for them to just sit quiet and do what everyone else is doing. The White Elephant method makes it way too easy for quiet, go with the flow types to go along just for the ride.

3. Story Switching - It seems to me that switching back and forth between stories is going to make it more difficult for the team to really figure out what size the story is. Collective thinking on one subject matter is better than everyone thinking separately (which is why the 6 Thinking Hats retrospective is so effective). If the team keeps switching between stories, it seems like it would make it harder for team members to retain the whole picture on a particular story.
I think this type of planning will work, it just depends on what team you have and the mix of personalities on the team. I can see some benefits to this type of planning though:
1. Good Visual - I really like the way the stories are put on the board next to each other. It really reminds the team how relative this type of estimation is. It's hard sometimes to remember that you're really just trying to figure out how big a story is compared to the other stories. Seeing all of the stories together really drives this home. This is something I'm definitely going to go in my next planning poker meeting. After each story is estimated, put it on the board in a category.

2. Reduces Discussion - There's good discussion, and bad discussion. Anything that helps decide if a story is a 5 or a 3 is good discussion. Everything else is bad. I can really see how this type of planning game could reduce the bad discussion and promote the good discussion. Since only the person taking a turn can ask questions, it reduces the amount of cross talk that is prone to happen when playing planning poker.

Once I've actually experienced this approach, I'll let you know how it goes.

UPDATE: I've since experienced this particular estimating method and have written about it here.