Estimating Defects - Using Principled Negotiation

I’ve caught myself changing my stance on pointing defects this last month as I consider different contexts and reflect on what the real situation is in my current teams.

Previously, my general rule was that if we don’t fix it a bug in the iteration in which it’s found (which would be the best thing to do), then it needs to be estimated before being scheduled into a future iteration. If we don’t fix it now, it will be more expensive to fix later. We should recognize that cost. This will help us know when we'll be done with the release. If we have a significant amount of work to do represented in defects, I want that quantified and represented in the release burn down chart. I acknowledge that defects are hard to estimate. Their accuracy will be worse than that for stories, but I don’t see this as a significant problem. The value we get from knowing when we will be done is worth the difficulty.

Mike Cohn recommends estimating defects if you have a big backlog of them and are fixing new ones as they come in. But that 'if' is important. Don't ignore the context. A similar context was underlying my rule of pointing defects. I assumed that if you were having the discussion about whether to estimate defects, then you must have defects that weren't being fixed in the iteration in which they were found. In that case, you likely have more than a few defects in the backlog and you aren't likely to have a policy defining a systematic approach for fixing issues. You'll schedule the defects into iterations just like you schedule stories. A systematic approach, by comparison, could be knocking out all the defects in the next iteration, or knocking out a fixed number each week. In those cases, I wouldn't estimate.

It was Dan Neumann's thoughtful post that made me realize I was making too big of an assumption about the context at hand. He also helped me realize that interests matter. Principled negotiation is when you consider each party's interests, not their positions. ("Getting to Yes" is an excellent book by the way.) For this topic, the positions are whether to estimate defects, and if you do, whether to include those points in velocity and in the release burn down chart.

But the interests are more varied and may include:

INTEREST: A desire to measure "forward progress". As Cohn put it, "making visible that the team is going more slowly through the work than it could if these legacy bugs had been fixed when originally found."
CONTEXT:  Most any.
POSITION: Don't point defects. Or, do point, but don't include those points in the velocity or in the release burn down chart.

INTEREST: A desire to keep anyone from thinking that scope is increasing. A desire to keep the release burn down chart from going flat, or up, due to defects. (It’s embarrassing and requires lots of effort to answer executives' questions: “Why is scope increasing?" "Why do we have so many defects?”)
CONTEXT:  Applies to any context, but in particular when defects are not being attacked in a smooth, systematic manner.
POSITION: Don't point. Or, do point, but don't include those points in the velocity or in the release burn down chart.

INTEREST: A desire to make velocity appear unstable so that quality problems become visible.
CONTEXT:  Defects in the backlog are not being attacked smoothly (a set number per iteration).
POSITION: Don't point. Let the uneven defect fixing impact velocity.

INTEREST: A desire to make velocity appear more stable. (Similar to the case above with a rising release burn down chart, an unstable velocity makes executives ask questions that can be hard to answer.)
CONTEXT:  Since the work effort applied is generally stable each iteration but the balance between defects and stories might not be, pointing defects makes velocity more stable.
POSITION: Do point and include the points in the velocity.

INTEREST: A desire to know when we are going to be done with all the stories AND defects.
CONTEXT / POSITION 1: Defects are not being attacked in a smooth, systematic manner. This interest can be served by pointing defects and including the points in the release burn down chart and in the velocity.
CONTEXT / POSITION 2: This can also be served by not pointing AS LONG AS you are addressing issues on a steady basis (so that your velocity is stable and therefore useful in computing the release end date).
CONTEXT / POSITION 3: Another approach is to address all of the issues immediately in order to get them out of the backlog. Point them or not; doesn't matter.

See how a single interest can be served with different contexts and different positions?

INTEREST: A desire to avoid overstating velocity.
CONTEXT:  Estimating and including recently introduced defects in velocity. The excellent concern is that "the team’s anticipated velocity includes an allocation to fixing defects that are yet to be introduced" and pointed. (Dan Neumann)
POSITION: Don't point, or don't include in velocity.

INTEREST: A desire for velocity to "… represent the team’s true capacity to accomplish work." (Cohn) Or, a desire to make velocity look better than it really is. (A desire to pacify upper management that wants to see a rising velocity number. A losing game, by the way.)
CONTEXT:  Most any.
POSITION: Do point.

INTEREST: A desire to get credit for work done, which is less justifiable if it’s our own rework and more justifiable if the bug was caused by another team.
CONTEXT:  Most any, but needing to get credit signifies an illness in the organization.
POSITION: Do point.

INTEREST: A desire to avoid the need to argue about a bug report actually being a story (so that we can estimate it for whatever reason makes us want to estimate it).
CONTEXT:  Applies to most any context, but this probably signals some animosity or lack of trust between the Product Owner or QA and the rest of the Technical Staff. At best, this may just be a desire to hold to the team's aggressive commitment.
POSITION: Do point.  If you point them, then it's easier to quantify how much more you did beyond the commitment.

INTEREST: A desire for the Product Owner to weigh the cost before requesting a fix.
CONTEXT:  Most any.
POSITION: Do point. Whether to include the points in the velocity is another matter.

The pie can be expanded for each of these positions once the interests are known. One party may become aware of an illness in the organization and see a way to cure it. One of you may be able and willing to educate the executives or boldly attack the quality problem. Maybe an unstable velocity and an increasing release burn down chart should be welcomed as an opportunity to talk to those executives about agile, metrics and what-not. Agile believes that visibility is good.

Bottom line – Use principled negotiation to understand stakeholder interests and the full context. Then devise a defect handling policy that specifies when defects will be handled and whether they will be pointed. The way you use iteration and release metrics needs to be in tune with all of that.

Parting shot – A tremendous amount of effort is expended on this topic for a situation we'd rather not have in the first place.

'Tis the Season for Pair Programming

There are few things that disturb a pair programing environment more than futzing with your nose. Chewing on pens or a lanyard or one's own fingers is not cool, but runs a distant second to nose fiddling.

Luckily, 'tis the season in which many offices have so called "holiday parties". What's this have to do with pairing ettiquite? Gift exchanges. That's right. Office parties often involve Secret Santas or White Elephant / Dirty Santa gift exchanges. What a great opportunity to make a few improvements to your agile environment! Few pair programming teams have the guts to directly confront issues of social graces. So, why not conspire with others to make sure that "special someone" has lots of opportunity to draw the perfect gift, and then get stuck with it?

So here are my ideas, your shopping list, for things to gift your pair to help keep his hands away from his face.
These are truly gifts for the whole team. No, really. These are gifts the whole team should go out and purchase.

• Tissues. Tissues are more than a subtle hit. Hopefully they'll be used. Disinfectant wipes are almost in this category, though they do more to counteract the behavior than to correct it.
• Decongestant. I rub my nose a lot more when it's stuffy. That may be why your pair does it.
• Allergy medicine. Itchy eyes, itchy nose; He's gonna rub 'em.
• Fingernail clippers. What better gift than a manicure kit for one who chews his fingers? Well, here's one...
• A gift certificate to The Boardroom Salon for Men. If you don't live in Texas, there's bound to be something similar in your own town. Just... not as big... or as manly.
• Hand sanitizer. Not only is it good for rubbing on your hands, it's also something that's uncomfortable when rubbed in the nose. It's kind of like using pepper to keep a toddler from sucking her thumb.
• Gum. Altoids. Mints. Jolly Ranchers. A variety is a must. These have the added bonus of attacking bad breath. This is also the one suggestion that can keep your lanyard and pen eating pair on a more healthy diet. (Surely, sugar is a more healthy diet than a piece of plastic.) These items may also give the incessant talker something else to do with their mouth.
• A nose hair trimmer.

Some Essential Items

That's right. A nose hair trimmer. This is an essential item, right up there with dental floss and a tooth brush. Every man should have one. I think men mess with their noses more than women and I'm convinced the problem is nose hair. Notice mine in the photo. (Referring to my trimmer.) The buttons are worn off. Pssst. That's a clue for anyone working on that last minute gift idea for me.

White Elephant exchanges are supposed to be unusual and humorous.These gifts would certainly be unusual. I would find them humorous, and taken in the spirit of the event, I'm sure you will too. Most importantly, the team would find this beneficial. Guaranteed to increase your velocity 10 percent. What else can promise that? If most of your team will stick with this list, some good is bound to come of it.

My Road to Agile

For those of you without the patience to read yesterday's long post, here is the abridged version. My route to agile wasn't overnight.

Fist exposure to an automated regression test suite in '89 (with the IBM 3174 Communications Controller).
Many years of coding and laboriously testing stuff by hand.
Wanted to try my hand at management in '96.
Project managed wrongly what could have been a nice agile project.
Felt ignorant.
Started studying.
Went back to programming.
Fell into an XP project in '99.
Fell in love with XP.
Studied it.
Tried to spread it.
Practiced it on a number of projects.
Wrote about it.
Spoke about it.
Disappointed people didn't flock to it.
Wanted to try my hand at managing in an agile fashion in '05.
Did much better.
Wanted to practice it on more projects, so became a coach for hire.

The moral of the story:
Consider all that led up to you buying in. Then guide and encourage those you work with, but give people space to find their own road to agile. Have patience with those you coach.

photo credit: Tomasz Wiech

How I Got Into Agile

This is long, but there is a moral to the story.

I had been programming for several years when I became tired of supporting the PPP and Frame Relay code in IBM's first router. No, that's not it. What really drove me away was the threat of having to pick up support for LU6.2. Maybe it wasn't LU6.2. Maybe it was something else, but it was definitely SNA. That's not the direction I wanted to go in. I wanted to work on IP. Any part of IP. I'd have been happy supporting basic IP, UDP, TCP. Developing any of the routing protocols would have been great. That's where the future was going to be. SNA? Yuck.

Prognostication in the early '90s -- score one for me.

I pleaded with the manager of the IP group to take me on. He had no openings. Or he no likey me. Or I had no IP knowledge. Whatever.

My manager at the time was Tom, a great manager and a real character. Tom was often railing about how many worthless meetings we had and how many people we had in them. Tom wrote a program in those days to compute the cost of meetings. All you had to know was the salary bands for the various levels and what level each of the attendees were -- stuff most people knew. Today you can get a program that does this for your iPhone. I digress. Tom was disappointed by my desire to leave his group, but was supportive in helping me find a place where I could grow and be happy. We'll come back to Tom in a bit.

A good friend, Sam, was working in the same division on some Smalltalk apps. Cool stuff, I thought, but I didn't realize how cool. Smalltalk will never make it, I thought. "What you are doing is kind of hard to buy into", I thought. C++ is where you want to be. I later said the same thing about Java.

Prognostication in the mid '90s -- Although Smalltalk didn't make it in the market, it would have been the thing to learn. Score one for me against Smalltalk's market-share; But -1 for being against Smalltalk as an important language; -1 against Java.

Sam's manager, Joe, offered me a position and made hints toward his retiring soon. I was thinking that if I couldn't work on IP I just might as well go into management. So I joined up. Sure enough, Joe very soon retired and handed the reigns over to me.

Now back to Tom. Not one month into my new role as manager, something was found to be lacking in our software. I don't recall whether it was a bug or an enhancement request. Whatever it was, Tom needed it for his product. My former manager, Tom, was now my customer. So, wanting to be a strong manager with a backbone, one who could make the tough decisions and stand by them, protect his team and his schedule, I said no. I either said simply 'no', or I gave him a delivery date way out in the future, which might as well have been 'no'. Although Tom was the man who helped me get this job, had given me a promotion along the way, and was now my customer, and although his request was quite small, I said no. When I became a manager I threw out the window all I knew about being collaborative. I stopped practicing what I believed in as a developer. I did what I thought managers were supposed to do. Tom wasn't my only customer. I had bigger customers with big projects and big demands. Tom was furious.

What I didn't know then was that this team of Smalltalkers was quite agile. Of course, we didn't have that term back then. Gosh. This was in the midst of the ISO 9000 certification heyday. I had to document our process. I never new managers had to do that kind of stuff! "What have I gotten myself into?" I thought. I really didn't know how to describe our process. I kind of knew what we did, but document it? I knew I'd need help and thought the team would be as annoyed as I with this task. I dreaded asking the question and I didn't fully understand the answer: "Iterative and Incremental" with a few other words wrapped around it. So, I wrote down Iterative and Incremental on the process document, wrapped a few other miscellaneous made up words around it, then whipped out MS Project and got my project plan in shape. And it was a doozey! Spread out, the project plan covered a very large conference room table. I was so proud. (But it was really quite disgusting.) I could demonstrate when we'd be done (well after everyone wanted it), how I carefully put the plan together (with painstaking detail), and how many more expensive Smalltalk contractors we'd need (don't ask). I knew nothing of negotiating scope. I project managed wrongly what could have been a nice agile project.

I knew I was missing something. I felt ignorant so I started studying. I went back to programming while trying to figure out what I was missing. Steve McConnell's Rapid Development and Steve Maguire's Debugging the Development Process and Fred Brook's The Mythical Man-Month stand out as books that began to point me in the right direction.

Then in '99 I discovered jUnit and very soon after got invited onto an XP team, thanks to Greg Houston. Greg would say I resisted XP. Perhaps I did. But I soon fell in love with it after I got used to pair-programming. That took some number of months. Then I began studying XP, writing about it and tried to spread it. I was there at the start of XP Atlanta, which was led at the time by Obie Fernandez and which we later renamed Agile Atlanta. I attended XP Universe in 2001. I practiced XP on a number of projects then started speaking about it within the company, at a local user group and at a nearby college. I also submitted an experience report and a research paper to XP 2003 in Genova. I knew I'd be using agile for a very long time.

I thought I could convert people, that people would readily see the light and that in just a few short years everyone would be doing XP. They would be won over by my passion if nothing else. People would flock to our XP user group. jUnit would lead people to XP and the XP books would convert everybody. And I knew this would happen throughout the industry.

Prognostication in the early '00s -- score one for industry wide fear, uncertainty and doubt with a big helping of resistance to change.

My Prognostication Score: 2 out of 5.

After some years of being an agile developer and advocate in an organization lukewarm to the concept, I decided that I wanted to get onto a team where everyone really wanted to do XP and management supported it. And I wanted to try my hand at managing again, this time in an agile fashion. I found such a team to manage and I did much better this time (though considering how bad the first time was, this might not be saying much). This project eventually brought me to my desire to practice lean/agile on more projects, so I became a coach for hire.

So that's how I came to agile and here's the moral of the story: I think it's important to remember the route you took and how long it took. For most of you I suspect it wasn't really overnight. It might seem that way on the surface. "I got the book, read it, tried it, loved it, all overnight." Not likely. There was a road that got you prepared for the switch. Those we work with, those we try to coach, are on their own road. Have patience with them.

photo credit: Tomasz Wiech

Getting Started with Kanban - Answers for Some Mechanics

Let's assume you've read David Anderson's excellent Kanban book. You've started using Kanban on a project. Everyone notices how much more transparency there is in the process now. Some welcome that visibility. Others are not so happy about aspects of that visibility.

If you are reading this blog, you are probably not after Mechanical Agile. You are smarter than that. You want to add real value to your organization. You know that Kanban can help your team focus on flow and continuous improvement if you can figure out, in practical terms, how to use these metrics.

Let's say you've started well, with an understanding of what is important to your business and you have an improvement goal. Maybe you want to start measuring cycle time, want to have a Cumulative Flow Diagram and want to create a frequency distribution diagram or process control chart. You are getting started but the book leaves many details about how to do that as an exercise for the reader. Rightly so. You certainly wouldn't want a specific tool to be prescribed just as Kanban doesn't prescribe which improvement model to use, of which there are many: Deming, Lean, Theory of Constraints, etc.

Thinking back on some questions I had when I started using Kanban I realize many of them had nothing to do with improvement models. They were more basic. In hopes that this may help you, I provide some of the answers I've come across or come up with. I give credit for the good answers to conversations I've had with Dennis Stevens and others. The stupid answers are all mine.

After counting days blocked, do you exclude those blocked days from each item's duration?
No. What you are after with cycle time is how long on average it takes to pull something through the system. Blockage happens. It's part of the cycle. You want to know how long it will take to get an average story through the system with average blockage. You use the days blocked as another, separate metric available for analysis and improvement.

When something has been on hold for a long while and gets dumped, do you include that item in your average cycle time calculations?
Sometimes things get blocked so long that that you give up. Or should give up. Toss that effort in the trash. Forget about it. Write it off. Maybe it will come back again someday, but when it does, you might as well start over. Just dump it. Don't directly include that item in your average cycle time. I say don't "directly" include it because it has had an impact on the metrics. It took up time and effort and caused other items to be delivered later than they could have been. So that item had an impact on your cycle time even though you exclude that item from the metrics. If you were to consider the item's end date the date it got blocked and include that item in the average cycle time, this would make your cycle time look shorter than it really is. Conversely, you could skew your cycle time towards having too much buffer if you held onto the item too long and consider its end date the date you dumped it. So, no, don't include the item in your average cycle time.

Do you include weekends in your lead time calculation?
Eh, do whatever you want. If your average lead time is greater than a week and if your business thinks in terms of calendar time, include them. If your average lead time is around a week or less and if your business thinks in terms of business days, then exclude weekends. Excel has a networkingdays function you can use.

=NETWORKDAYS(B34,C34,'KanBan.xlsx'!holidays) 

For quick items that start and end on the same day, should I count it as a day or as a half a day?
If your average cycle time is much greater than a day and this happens rarely, count it as a day. It's not worth the effort to do differently. If it's rare that any item takes 2 days to finish, then consider measuring at a granularity finer than a day -- measure in hours. If your average cycle time is a couple days and this happens often enough, count it as a half-day -- measure in half-day increments.

How do I graph a frequency distribution using excel?
Use a bar chart. I put the cycle time durations I care about in a column: .5, 1, 2, 3, 4, 5, 6, 7, 8, etc. These are the "bins" that feed the FREQUENCY formula. Name the binsRange and name the durationsRange. Next to those bins, is an array formula: select the range, type in the formula =FREQUENCY(durationsRange,binsRange), and press ctrl-shift-enter. Then I graph the bins and frequency as a bar chart as shown in the image at the top of this blog post.

How do I graph a Statistical Process Control Chart using excel?
I'm assuming you already have columns for completed date and duration. There must be a better way, but the quick and dirty approach is to add a column for the mean and upper and lower control limits and upper/lower spec limits. These columns will have the same value (the mean, or the mean plus/minus three standard deviations, or the spec limit) in all rows. Select those 5 or 7 columns: date, duration, mean, upper/lower control and upper/lower spec limit. Insert a X Y (scatter) chart. Select the mean series, right click, and Change Series Chart Type to a Line chart. Do the same for the other control lines. Voilà!


I hope this has been useful. If so, let me know.

What questions of this sort have you resolved or do you still have?

Looking Ahead

I like to pass along my thought process and habits to those I work with. (Which is good because, well, it's what I get paid to do.) For example, I'm always looking ahead to the next planning or the next estimating meeting. I teach this behavior to my clients whenever I'm coaching a new Scrum Master or Product Owner.

I start off by involving them in what I'm doing, showing what needs to be done and by explaining my thinking. The teaching is very experiential, yet incomplete in a way. If I explained everything in my head, everything I was looking out for, I'd be doing too much telling and not enough involving.

Tell me, and I will forget.
Show me, and I may remember.
Involve me, and I will understand.
- Confucius, 450 B.C.

Yet there comes a point where I'm about to push them out of the nest and let them fly solo when I become more explicit about teaching my thinking. This leads me to throw down a list of things to remember, to refer to later, always tailored to the local context. Experience tells you what to look for and this is somewhat different in each situation so please don't expect this to be an effective checklist for your organization. But in general I keep the following questions in mind.

I look at the stories that haven't been estimated as well as the next iteration or two.
Can the team estimate the story?
Can the team plan the story?
Are the descriptions good?
Are the acceptance criteria sufficient?
Is the story too big?
Does the team need to do a spike first?

How does the next iteration look?
Too many points? Not enough?
Are there un-estimated stories in there?
Are the stories prioritized?
Have we given the team some advance notice as to what we have in mind for the next Sprint?

If we have specialization or multiple teams for one backlog, should we think about which team should take each story?
Does the next iteration look balanced between the teams/specializations?

How does our release burn-down look?
How does the release backlog look?
Will we have stories ready and estimated in advance of the start of the next release?
How much lead time do we need to need?

If I'm using an online backlog management tool, am I overlooking some stories not in my standard filter because they haven't yet been slotted into an iteration or assigned to a team?

When using an online tool for backlog management, I set up views or queries to help us answer those questions:

• No Estimate
• No Team
• No Sprint
• This Sprint
• Next Sprint
• Release Plan

That's provided naturally by some tools, can be set up with a little work in other tools, and is downright impossible in others.

Looking more than one iteration ahead, are there holidays coming up that will fall on a regularly scheduled estimating or planning day (or a pre-planning/pre-estimating day)?

The Scrum Master can help keep an eye on things and point out what is lacking, but the bulk of the decision making of course belongs to the product owner.

I hope you find this useful.

photo credit: Tomasz Wiech

Standing Meetings: Estimating, Pre-Planning, Pre-Pointing

It's helpful to have standing meetings. Although they are indeed standing in the photo, in this case I'm not referring to the absence of chairs. I'm referring to regular and reoccurring.

I've found it useful to have regularly scheduled estimating meetings. For two-week sprints I hold estimating in the middle of the sprint in the same time-slot as planning. If planning is every other Monday at 10, estimating is the other every other Monday at 10. (Planning is usually longer, though. Planning usually takes one to four hours, depending on the local situation at my client. Estimating usually takes less than one to two hours, depending on how many stories we feel the need to estimate.) Being careful to not let this become waste, we don't estimate more than necessary just because we have a regular meeting.

But why the standing meeting? Why not just estimate whenever needed? The scheduled meeting disrupts the team less than an impromptu meeting. This is because the team knows it's coming and they plan their day around it. This also affords a bit of discipline that even mature teams can benefit from. It forces the product owner to always be ready to estimate and to always have something ready for planning.

This brings me to pre-planning and pre-pointing meetings. I schedule a standing meeting to occur a couple days before each planning day and each estimating day. For newer Product Owners, this is time for the Product Owner to work with the Scrum Master or Agile Coach (me) to be sure the PO is ready. We don't want to come unprepared and waste everyone's time. Many Product Owners continue to use this time in this way even after our engagement is over. When useful, we pull other team members into our prep to help define acceptance criteria or to split stories.

Regular or Impromptu? What do you do?

Approaches to Retrospectives

I had the distinct pleasure of working briefly with Tim Wingfield a few months ago. Bright guy. We were talking recently about different retrospective approaches. One of his teams was in a rut with how their retrospectives were going. They tend to only be the griping and airing of grievances style and they weren't getting actionable items. Everyone was caught up in the complaints.

The great thing about agile is that you can be agile in order keep from getting into a rut. Each new client has a different situation which gives me opportunity to focus on a one aspect of agile more heavily than at another client. I get to try different nuances each time.

The neat thing about retrospectives is how applicable they are and how easy they are to apply outside of IT. Today I was sharing some of my approaches with a cycling friend whose realty group, Dillard & Company, uses a genuine team approach. I say genuine because they are a team in the real sense of the word. They aren't just a group or loose federation that incorrectly calls themselves a team.

Anyway, I had these approaches in my head and Tim had commented that my retrospective artifact was a little different than what he had seen described in writing so I thought I'd put them down in a blog post.

I tend to use a flip chart for the retrospective when I have a dedicated space in which I can leave a big visible chart. Unfortunately, my clients often lack sufficient space. So I find that I most often end up using a white board and then transcribing the retrospective notes into some tool like VersionOne or into a wiki. I like using the whiteboard during the retrospective, but I don't like hiding the results online.

When I use a flip chart, I find it convenient to draw quadrants. When I use a whiteboard, I just do columns.

Either way, in these quadrants or columns I often write:

• what went well
• what did not go well
• do more of
• do less of

Sometimes I use:

• good
• bad
• do differently

Less often I use SaMoLo:

• Same As
• More Of
• Less Of

I may use "opportunities" instead of "bad" or "did not go well". It depends on the tone of or presence of animosity in the team and whether certain terms are emotionally charged.

There are times when I really want to dig into things and fully understand what's going on. I facilitate the whole discussion. I often start out with "so, what happened this iteration?" Or, "what went well?" Or, "how did it go?" I try to record the essence of what people say. Be a good facilitator. Elicit input from the quiet ones. Try to cover each of the areas at least a little. I may dot-vote for the one or two issues to attack in the next iteration, if consensus isn’t obvious. This approach can take a while. I use this approach the first few times with a client or when we have largish iterations. If people get impatient, I don't use this approach.

Once I'm through that stage I like to switch to this other approach. I have everyone come up to the whiteboard all at once and write whatever they want in any of the columns. I request that they briefly tell someone in the room about what they just wrote. I listen in for themes or things I want to dig into during the discussion that I have once everyone is done writing. I often don't write anything of my own, but I may if I see something important missing. This gets us through the kudos and complaints more quickly so that I can get on to the "do differently" items and find some specific action item to take away. I have gotten a lot of positive feedback on this approach. Everyone feels more engaged. It gets them out of their chairs and their blood pumping.

Another approach is to ask people to write their thoughts on sticky notes. You can then read them or have them read them. You can have the team do an affinity grouping of them. I'm not sure how to keep that approach from dragging on too long, but I can see how it can help elicit input from the quiet ones.

One other thing I like to do before I run a retrospective is skim over what we recorded in prior retros. If I find an issue that was brought up over and over but that never made it into an action item, I’ll just start the retrospective with that and figure out how to solve it.

Other than in that instance, I never exclude the opportunity for people to complain about something. It's important to have a release valve, an opportunity to blow off some steam. But we don't have to dwell on it. Some things you are just not going to solve and other times just mentioning an issue can solve it.

I mix it up because it's important to do retrospectives in different ways. Regardless of how I run it, I always look for one specific, measurable, achievable, actionable action item as an outcome of the process and I make sure it has an owner.

Of course, Esther Derby's Agile Retrospectives book is a great resource for more ideas.

Sticking With It

In the prior century I made several failed attempts to read the whole Bible. I usually quit because I found the language tedious to read and hard to understand. (That, and a lack of spiritual maturity.) I had tried the King James and the New International versions. I finally bought a study Bible, one of those with lots of footnotes, in a modern translation. Since I was having so much trouble with the wording and reading, I picked a translation that was easy to read, a dynamic equivalence translation -- NLT. It took three years to make it all the way through, but it was very rewarding.

I'm now attempting a read-the-Bible-in-a-year program in a different translation. This time I picked a balanced translation, Holman, backed up by a number of formal equivalence translations, chiefly NKJV and NASB.

There are many different approaches to reading plans. I picked a chronological plan, which I thought would be neat. And it is at least a little neat. I'm hoping that reading the whole thing in a more compressed time frame and chronologically will give me another perspective on the whole thing. Less time will have elapsed from one book to another.

This time around, though, I find the reading much less enjoyable than the 3 year deep study approach. It's a lot more reading and a lot less studying. I would recommend the reading through in a year approach to someone only after they have done it the other way.

Question

What has helped you stick with it and read the whole thing?

My Approach to Estimating

I did some research on using function point counting on an XP project many years ago. A few people remember that paper and occasionally I'll be asked what approach I recommend these days for estimating. There is a lot to like about function point counting and it can be useful on an agile project for estimating a whole project (but not an iteration for reasons explained in the paper).

Story Points and Planning Poker

The best approach for estimating user stories on an agile project is planning poker cards, small stories, estimating regularly, and keeping a small set of good (well estimated) stories visible. What I mean by keeping some standard stories visible is having a BVC (or just story cards left up on the wall somewhere) for those stories that went well, that everyone agrees it was a good 1 pointer or 3 pointer. "How does this story compare to that one?" is a common refrain.

Estimating regularly (weekly or at least every other week) keeps the approach and the "standards" fresh on everyone's mind. Have a regularly scheduled (standing) meeting on the calendar.

I don't get any more complicated than that. That's good enough. It's quick and requires little special skill. Well, estimating with points and planning poker is a skill that does need to be learned, but it doesn't necessitate a class, a thick set of rules, or a software estimating tool of any kind. Sure, a class or some reading can help, but it's not necessary.

Bootstrapping

For bootstrapping an estimating process for a new team or a new project, I like Steve Bockman’s Team Estimation Game or the less formal approach I used on a project in the early 2000's which amounts to little more than collaborative sorting of story cards into simlarly sized piles. James Grenning describes another version of a similar activity.

Question

On a related topic, tell me, do you have only the developers participate in estimating or does QA participate too?

If It's Painful, Do It More Often

I've worked with a number of teams who couldn't deliver. They could write code all day long for months on end, and they'd do just that. But then they'd spend a month or three shaking bugs out and still not be able to get the product into production. In many of these cases, the programmers just want to program. They don't want to or know how to do the messy task of deployment. Install and upgrade is not their core competency.

It's instinctive to cram more features into the release when it is just so hard to deliver. If you get few chances to deliver improvement, you want to cram as much in the release as possible. But that just makes it harder. More beautiful garbage to push over the goal line. This raises the inventory of unfinished work, the amount of work in process, which further delays deployment and hides the real problem.

I'm reminded of the Israelites when Moses instructed them to not save the manna that God provided from one day to the next. Do not keep an inventory of the stuff. But some of them didn’t listen and kept some of it until morning. But by then it was full of maggots and had a terrible smell. Software development with too much WIP is exactly like that.

Anyway, Lean software development reduces work in process in order to surface problems and reduce costs.

I like this illustration from page 7 in Mary Poppendieck's book, Implementing Lean Software Development. When you first look at it, your reaction might be "No! RAISE the water because there are rocks!" But the rocks are still there. Some day you are going to hit those rocks. Better to hit the rocks and deal with it in a dingy than in a yacht. Better to deal with the inability to deploy using a small release than a big one. It's better to lower the inventory, surface the issues and work to resolve them. Don't leave them there, lingering.

In eXtreme Programming we say that if is something is painful, do it more often. What we mean is that we should not avoiding dealing with problems. Solve them right away.

Getting Your Team to Take Short-Cuts

I was once in a software product company teetering on the edge of financial problems. And who in this business hasn't been? We had only one customer of consequence and they were unhappy with the cost of what was essentially custom development. This turned into pressure to deliver more features per dollar of cost. I.E., to develop the features faster. Right away. Pronto. How do you make a team of programmers immediately faster?

I had already looked at our process and had evaluated our use of best practices and our quality. We were following XP well, so if you subscribe to XP being a good set of best practices, we had that covered. Our development speed was average for enterprise software vendors using Java/Swing. But our quality was best in class. I am basing my evaluation mainly on the work of Capers Jones' recent books and metrics gathered from the team's history. That's about as objective as I could get. I also considered what I know of the industry and other groups, a more subjective measure. From what I've seen since, that team's velocity was actually quite good. To get the performance boost, there was only one thing left to do.

You may be able to get a short boost of speed at the expense of incurring technical debt, or, more technical debt than normal as your case may be. But to do that, to get a short boost in the rate of delivered features, you’ve got to paint a good picture of the situation to development. Why? Because you’ve got to get them to understand the seriousness of the situation and give them a vision of how long or how much or how many of what is needed so that they can buy-in to changing their habits and their preferred, ingrained and natural method of working. Saying "preferred way of working" makes this sound like a choice. A team's preferred way of working is indeed a preference, but it isn't much of a choice. It's a compulsion. You must realize when you demand speed, when you ask the team to take short-cuts, you are asking them to work-differently. You are asking them to work in an unnatural manner.

To illustrate: You are most likely right handed. Pick up your pen with your left hand and write a long letter to your spouse or your mom. Get the picture? The unnatural is difficult to achieve.

In Complete Control and Not Controlling

My regular followers know I post on lean/agile IT topics as well as bicycling and faith-based views. You agile IT guys – hang with me and I’ll tie a little agile into this before the end.

One of my favorite bloggers is Joe Gibson, co-author of the Ant Developer’s handbook. I like his opinionated writing on topics of interest to me: Java, Scala, Groovy, Ruby, Lisp, Koine Greek and religion. His own translation of old Greek manuscripts and commentary on other translations are quite interesting.

Joey posted a few days ago on how those who use the Bible too often "selectively edit scripture to fit a particular message, or to fit nicely with a pithy saying." This is essentially eisegesis (to draw in) rather than proper exegesis (to draw out). That is, reading stuff into the text rather than more appropriately getting out of it what the author intended. I was passionately into his post, in complete agreement.

Now Joey and I don’t see eye to eye on a number of matters of faith. Yet even when we strongly disagree there is usually some point in his writing that I strongly support. So I was with him right up until he said this:

...the minister was going on about how we need to "stop worrying" and just know that "God is in complete control" and blah blah blah… I’ve always hated that way of thinking. I despise the Sandy Patty song, "God Is In Control," because I do not believe that is true. (Bold emphasis added.)

So I crafted a nice and timely, intelligent, thorough and sound response. Joey’s blog seems to have a multi-step click-post, preview, click-post-again are-you-sure, captcha phrase kind of process that I obviously flubbed because my response never made it to the blog. Time has passed and now I’m here rambling on, many times over what I so eloquently put in my initial response.

So back to Joey. Joey’s next statement shows a misunderstanding of "complete control" and he has made quite a leap.

...if you believe that he is in "complete control" then you have to take that to its logical conclusion. If you believe that every good thing that happens to you is because God wanted it to be that way, then you must also accept that every bad thing that happens to you is because God wanted it that way.

The error here is the assumption that to believe that God is in complete control is to believe that everything that happens to you is because God wanted it to be that way. Let me explain. My kids run wild at times. This is not what I want. "Hey kids! Run around the house, fight some, and drive your mother and I crazy." It’s not what I want, but that’s what happens. I give them some room to exercise their free will. Notice I said some room. I have boundaries and my kids test them. I’m not controlling my kids, at least not most of the time. At least I try to not be controlling. Anyway, I assure you I’m in complete control of the situation at home and am quick hand out corporal punishment when boundaries are reached. In control, but not controlling.

A good agile manager or agile architect does likewise. They aren’t controlling. Rather, they set some boundaries, and otherwise let the team self-organize. They give the team much latitude to decide how to get the work done within some boundaries. Rather than hand out tasks, they encourage the team to select their own work tasks. Yet they remain in complete control.

[Sorry – I have no analogy for you bicyclists. I control my bicycle, but am never fully in control, much to the disappointment of my Dunwoody Cycling buddies.]

Notice that God told Adam that he is free. Free to eat of any tree in the garden but one. God gave man free will. But God also set some boundaries. So Adam was hanging out in this cool garden in complete fellowship with God Himself. But Adam poked God’s boundary so Adam and all of us now suffer the consequences. God’s will is for man to love God and obey his boundaries. God sends no one to hell. God’s will is that no one perishes, but that everyone accepts his free gift of salvation by faith in Jesus Christ alone. But for love and obedience to be real, there has to be a choice. A choice to disobey. Therefore, God is not controlling our every action and decision. And we will all suffer the consequences of my sin and your sin and Adam’s sin and the sin of others. God does not wish this on any of us.

Witness Job. God allowed Satan to bring disaster on Job and his family. But God set boundaries for Satan. "Go this far and no further" in effect. So God certainly allows bad things to happen, within boundaries. I wouldn’t wish Job’s trials on anyone, but I’m sure glad it happened. There are a lot of lessons for us to learn at Job’s expense, in particular, that God is in control.

Boundaries – God is not going to allow us to interfere with his plans. We can’t blow up the earth, for example, and kill everyone. We can’t wreck the environment such that we all die. Unless, of course, that is God’s plan for how the "first earth" will pass away (Revelation 21). But in that case, there is nothing we can do to stop it from happening either. But in any case, we’ve got boundaries and God is in control. We can certainly kill many and do big-time damage. But we can’t mess up his plans. God will intervene.

God does directly intervene at times. See 1 Kings 22:23 -- "You see, the LORD has put a lying spirit into the mouth of all these prophets of yours, and the LORD has pronounced disaster against you." The Bible says that what Joseph’s brothers meant for harm, God used for good. And there are the New Testament miracles.

This is getting long and a bit rambling, and my argument is beginning (or perhaps continuing) to trail off, so rather than wrap it up and put a nice bow on it like Joey does, I’m just going to quit here.

It’s The Values That Matter. Or Maybe It’s The Culture.

Mechanical Agile^[1] is when one tries to follow the process with no understanding of the theory behind the practices, with no understanding of why it is designed as it is. Daryl Kulak wrote the most excellent post "Five Symptoms of Mechanical Agile". Any team exhibiting the conditions represented there, certainly need help. But truly, any team having those problems is pretty far along. They are trying to be agile but are misfiring on some point. Many teams don’t get that far because they just don’t get it.

As with XP, Scrum can be followed mechanically, without any understanding of why. Have some iterations, estimate in points, make a pretty burn down chart, do a demo, and maybe a retrospective every other sprint “because we just don’t see the value of doing it every sprint”.

And they totally miss the point of agile.

Ken Schwaber said that teams implementing Scrum need to "...recognize the even higher degree of control, risk management, and transparency required to use Scrum successfully. I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it." (Emphasis in original.)

I agree with Ken. More is needed than is evident to most teams. In the context of the quote, Ken is pointing out what is needed to supplement Scrum in lieu of "controls and safeguards of waterfall and predictive processes." And there is more needed beyond just that.

Same thing with Kanban: model the process, put some swim lanes on the wall, and maybe put some WIP limits in. Visualize the workflow and break a log-jam from time to time.

And totally miss the point of continuous improvement and the metrics that enable such.

In his article, Daryl wrote that if you fall into mechanical agile, "[only] addressing the attitude of thinking of people as machines will help you." Daryl touches briefly on the topic of culture in his article, suggesting that cultural issues can be a problem and the need to change the culture as a solution.

Jeff Patton says that "Agile development is more culture than process". That is, if you ain’t got the culture, your Scrum/Kanban team may not be agile. Pay close attention to agile values and mismatches between those and the organization’s values.

That’s the key ingredient: the agile values. Or maybe it’s the agile culture. Not sure if values drive the culture or whether it’s the culture that influences the values. Either way, they go together.

When I teach XP in a time-limited situation I’m always torn between focusing on the four core values versus the practices. The practices are easier for people to understand. They add some value by themselves. They are concrete and give the audience something they can grab on to. But picking up the practices don’t make one agile. It’s the XP or Scrum or agile values that give you a fighting chance of understanding what you are doing the practices for. But starting with the values leaves most people scratching their heads. They don’t resonate with the average software practitioner.

The best chance you have of changing a culture, then, is with successful agile projects, mechanical or otherwise, punctuated with judicious and timely explanations of the values.

1. Dr. Hong Li coined the term Mechanical Agile which was first used publically by his co-author in an upcoming book, Daryl Kulak.

Pair Programming, the Breaststroke

I’ve been working on my swimming for a few years. When I first started attempting the butterfly stroke, I found it very difficult. It required a lot of strength and technique that I did not have. I was lucky to make half a lap. Test Driven Design is like that. If you haven’t been shown some techniques and aren’t real strong with refactoring, with useful design patterns and with SOLID design principles, TDD is difficult to pick up.

In each case, you need a good coach. While struggling with my butterfly, I watched a few videos and read up on it in an attempt to improve my technique. But it’s just not ‘there’. And it never will be. My TDD skill is the same way. Underdeveloped. No amount of reading will get me where I would need to be with either topic if I depended on programming or swimming for a living. Hence the need for a coach. A coach will examine what you are doing and supply what you are missing or overlooking. A coach will help you build technique and strength.


Other strokes are easily done. Take the breaststroke for example. Anyone can do it. It’s not that strenuous. For years, I did the breaststroke only for fun or to cool-down or to swim to the bottom of the pool. It wasn’t for “serious exercise.” I never saw any benefit as a fitness routine. But then a swimming coach happened to stop by my house and commented on my stroke. I was doing it wrong. My strokes were too long and slow. Wow, what a difference a little technique makes. I couldn’t see my mistakes without a coach. Now, with a more effective pull, I’m quickly winded and building strength.

Pair Programming is like that. There are so many little things in this technique that can render it ineffective. What do most people do with an ineffective development practice? Typically, they drop it. At worst they keep doing it the same useless way, or they quit and then disparage it publicly. But at best, they get someone to improve their technique. Hence the need for a coach. I can watch a pair for a few minutes and usually give them half a dozen improvements right off. Chairs, posture, distance, and desk. Surface, keyboards, monitors and mice. Smells, habits, distractions and dirt. Communication, collaboration, cordiality, and care. Promiscuous, driving, navigating and alignment. A coach will examine what you are doing and supply what you are missing or overlooking. A coach will help you build technique and strength.

You break your stories down /when/ ?

http://www.flickr.com/photos/pointshoot/ / CC BY 2.0

I've had a revelation. The other day I was talking to Mike Cottmeyer about Scrum and how I don't like the idea of tasking out and estimating all stories at the start of the sprint and then signing up for tasks, all before committing to the Sprint backlog.

When I first started doing XP in early 2000 we tried that and it was painful. Painfully long. Painfully tedious. And it felt painfully like Big Design Up Front even though it was for one or two weeks worth of work.

One team I was with for a handful of years broke our stories down into small 1 to 6 hour sized tasks and we pair programmed (up to 10 of us) on a limited number of stories (preferably 2, normally 3-4, but it could get up to 6-8 near the end of the iteration if something got blocked and if we had lots of abnormally small stories in the iteration). One person with an optional pair would design a story just in time and then walk the team through the details and proposed tasks and get their input. All the tasks were written on the whiteboard and this drove all development. Tasks were small and explicit:

• extract foo.class from fred.class
• extract bar#makeGenerous from #makeMagnanimous
•  introduce strategy pattern to someOther.class
• create someNew.class
• domain/persistance/patch for someNew.class
• write the acceptance test
• etc.

That design work could take up to a day or two to do for some of our stories. There is no way it would make sense to design all of our stories at the start of each iteration before committing to the iteration. That's how we did it using XP.

Tasks in Scrum, however, seem to be around 8 to 16 hours long, according to what I'm reading. And that was the new insight I gained. Some teams do things differently. (I'm slow sometimes, but I usually catch on.) With tasks that size, you could easily identify the tasks and estimate them before committing to the sprint. Further, teams that don't pair-program or that have too much specialization or too much code ownership need to break their tasks down by specialty and assign each task to the person that can implement it. Such teams would need to do this step before committing to the sprint.

I was blinded by my experiences being so similar to one another for such a long period of time. Help me see. How big are your story's tasks and how and when do you estimate them?

Printing Story Cards from VersionOne

VersionOne doesn't provide a direct way to print your stories on index cards, but it can be done. I'm going to tell you about the browser approach and the export approach. For the browser approach, getting set up to print your stories on index cards is a matter of figuring out what URL to hit to get just the stories you want to print. Then you can bookmark that URL for later reference and print the cards directly from the browser. The disadvantage is that it's a few steps to change your browser's print setup each time and you'll want to reset your browser's print settings afterward. But you can print on standard stock index cards if your printer will allow. I'll give you the details in a moment.

The export approach involves downloading Avery's print wizard and setting up a template. Then each time you want to print your stories, go to the view in V1 that has the stories and columns you want to see on cards. You'll then do a few steps to export the stories into a spreadsheet and use the Avery tool to format the stories (into another document) and then print them on special Avery stock. The advantage to this approach is being able to select which values you want on the card and where you want them. That's all I'm going to say about this approach.

The Browser Approach

To keep this from getting too complex, I'm going to describe what you need to do if VersionOne is hosting your instance. If you are hosting it yourself you should be able to figure out what to do by reading the original post.

Generally, we are going to get all the stories formatted as cards on a web page, then we're going to print from the browser onto cards. To see all of the stories in the system, use this URL:
https://servername/v1instance/rest-1.v1/Data/Story?xsl=/s/custom/storyCards.xsl
For this and all the URLs below, you will need to replace "servername/v1instance" with your actual server and instance name. (Hint: look a the URL you use to access V1.)

Of course, you most likely will rarely want to print every story card. Thankfully, you can add some filtering. I'll provide some examples. You may have to do a little guessing, experimenting and URL manipulation, but I'll tell you how to approach that.

You can control which stories are returned by adding some query strings to your URL. For example, to see the stories for "Sprint #1", use the URL
https://servername/v1instance/rest-1.v1/Data/Story?where=Scope.Name='Sprint %231'&xsl=/s/custom/storyCards.xsl
Note the %23 in place of the hash symbol. You'll need to handle special characters in your URL appropriately.

To see the stories for "Iteration 7":
https://servername/v1instance/rest-1.v1/Data/Story?where=Timebox.Name='Iteration 7'&xsl=/s/custom/storyCards.xsl

To see the stories for "Sprint #2" that are OPEN (64):
https://servername/v1instance/rest-1.v1/Data/Story?where=Scope.Name='Sprint %232';AssetState='64'&xsl=/s/custom/storyCards.xsl

To see the stories for Iteration 6 that are OPEN (64):
https://servername/v1instance/rest-1.v1/Data/Story?where=Timebox.Name='Iteration 6';AssetState='64'&xsl=/s/custom/storyCards.xsl

To see the stories for Iteration 6 that are CLOSED (128):
https://servername/v1instance/rest-1.v1/Data/Story?where=Timebox.Name='Iteration 6';AssetState='128'&xsl=/s/custom/storyCards.xsl

You may want to do more filtering than in the examples here. To see what all the attributes and values are, leave the xslt out of the URL as follows:
https://servername/v1instance/rest-1.v1/Data/Story
There might be something useful to you in the Meta:
https://servername/v1instance/meta.v1
And you may need to refer to the Meta API and the ReST API documentation for V1's sdk as well as the article Getting Started with the API.

Now for Printing

Now that you have the stories you want to print formatted as story cards in your web browser, it's time to print them. This xslt we are using is set up to print two stories per page on letter size paper. If this is acceptable to you, you'll likely need to scale the print job to 80% or 90% when you print. Alternatively, you could go the extra mile and set up your browser to have no margins and no header or footer. But if you do that, you'll likely want to reset all of that once you are done printing.

That is certainly the easiest approach if you have a paper cutter handy, but with a little more effort we can print those directly onto stock index cards. To print those on a 3x5 card, set your browser as follows:

• page setup: landscape, no margins, no header or footer
• print, properties, paper: 3x5
• print, properties, effects: leave set to actual size
• print preview: scale 50%

Put the index cards in the printer in portrait orientation. And print.

Question of the Day

Have you found any other approaches to print story cards from VersionOne?

Pair Programming is Infectious

Those who are proficient at it say pair programming makes them faster and more thorough with their testing and refactoring. It improves their design skills and the quality of the application. Real good promiscuous pairing quickly spreads best practices, rhinoviruses, knowledge, influenza, bacteria, techniques, tips and tricks throughout the team. Not all things are good in an environment that excels at spreading things.

Thank goodness I'm seeing more and more team members actually go home at the first concern of getting sick, and managers in support of this. A cold can decimate an entire team.

Sharing a keyboard and mouse can help those new to pairing get the hang of it through the explicit "you drive" keyboard push. But once beyond that stage, use two keyboards and mice. They’re cheap.

You can keep plenty of alcohol based hand sanitizer and wipes around; a box of tissues on every desk and signs in the restroom encouraging hand washing. I'm starting to see restrooms with small paper towel dispensers by the door for the express purpose of giving you something to use when opening the door. One team I’ve seen sprays their keyboards and other surfaces with Lysol once or twice per week.

From the Chateau Grand Traverse men's room, Old Mission Peninsula

Eating well and getting exercise is commended in the places I've been.

But beyond those things, how can we convince our teammates to stop picking their nose? "I don't pick my nose!" they say. Ok, rubbing your nose. Biting your cuticles. Chewing on your pen. Whatever it is, keep your hands and other objects away from your face.

I guess sneezing into your hands is better than into open air and onto the desk, but go wash your hands afterwards. "Oh, bless you! A sneeze like that deserves a hand-washing."

I've been thinking about this a lot, to the point that empty beverage containers lying around creep me out. "Whose is this? Should I throw it away? Do I want to touch it?"

To combat these bad habits and their contagion in my teams I'm trying every approach I can come up with. I use humor when I can and the direct approach when it's all I can think of. And by the way, throw your used tissues away, will ya?

Pair Programming Stinks

What smells in your environment and what you can do about it.

Someone on your team has a keen sense of smell. Let’s call him Martin. Martin is annoyed by the smell of popcorn, can't stand scented deodorant and loathes air fresheners. Febreeze is sheer torture. He buys unscented laundry detergent. Only certain dryer sheets will do. Perfume gives him a headache. Baby powder makes his eyes itch, as does some hand soap. He is allergic to newsprint. Wintergreen to him is air pollution. Juicy Fruit and smelly feet make him nauseous. He can’t concentrate in the presence of these distractions.

Someone on your team smells. Let’s call him Andy, or maybe we’ll call her Andi. It’s his shoes. It’s her perfume. A little cologne. He smokes. She smells like the coffee shop she stopped by before work. His jacket smells like the bar he went to for lunch or the curry they have at home. The poor girl has halitosis and periodontal disease. Andy will wear the same shirt a few times between washings. Andy’s got gas.

Of course he can't smell this. He is used to it by now. He has, after all, been living with the smell for twenty years. It started gradually, innocently enough. It stnunk up on him. No one has ever told her to lay off the perfume. No one has told him about his smell. If he is aware, he doesn’t know how to fix it.

Few people have all of Andi’s smells or Martin’s sensitivity, but their conditions do exist in many forms and to varying degrees. It likely affects someone on your team. In a pair programming environment, these things hinder effectiveness. This isn’t just an unfortunate personal problem for Andy or Martin. It's part of your team; it’s now your problem. We who are leaders must address this issue. The benefits of pair programming are worth the effort.

Here are some tips you can share with your whole team:

• Many smells are caused by genuine medical conditions that require a doctor’s or dentist’s attention. Make an appointment.

TOP

• Use and share breath mints, but this should not be the 1st and only thing done for your breath. Sugarless gum can be effective since it stimulates saliva production more so than mints, and saliva combats bad breath. But remember that not everyone likes wintergreen and Juicy Fruit. Stick with cinnamon and mint.
• Chewing on a sprig of mint works as does a simple drop of lemon juice.
• Drink more water.
• Don’t be embarrassed to brush your teeth at work. Be a trend setter. Also brush your tongue.
• Flossing every day is mandatory for those on a pair programming team. Brushing your teeth is important, but the smell is coming from the rotting gunk that only floss will remove.
• Many companies provide a mouth wash dispenser in the restrooms. If yours doesn’t, you could ask them to or provide your own. However, the ADA says that most mouth washes do not have a lasting effect and recommends the other solutions as more effective.

TO BOTTOM

• Wear different shoes, ones that breathe better. Try shoes that you can slip off for a few minutes every hour to air out before the smell starts. But consider this carefully because removing your shoes could make matters worse.
• Air out your shoes over a vent each night -- be creative. Rotate your shoes. Don't wear any one pair of shoes more than twice per week.
• Change your socks during the day. Take a fresh pair with you each day or leave a few fresh pairs at work. But don’t leave the used ones lying around.

• Buy new socks. Try wool socks. Throw away the nylon socks. Try a thicker pair of socks. Start wearing socks if you normally don't.
• Stop wearing socks if you normally do. That is, try flip flops or sandals to avoid the whole sock/shoe airing out problem.
• Use an odor absorbing insole.
• Wash your feet with antibacterial soap every morning. Completely dry your feet after showering, particularly between your toes. Use a hair dryer. This has the added benefit of preventing athlete’s foot.

• Use foot powder on your feet. Use foot powder in your shoes. For those who have never used it, it might not have occurred to you that you can sprinkle some powder in your shoe, shake it around, put your toes in the shoe, sprinkle powder on your toes, put your foot in the shoe, and wiggle it around before putting on your socks. That really gets a good coating on everything. But note that this could backfire. You could end up smelling too much like foot powder. You want just enough to tackle one odor without introducing another. Try different brands. The sprays weren’t effective for me.

AND IN BETWEEN

• Wear deodorant, but preferably unscented.
• Wear a clean t-shirt under your golf shirt every day. Under ideal conditions you may be able to wear a pair of pants a couple times between washings, but make sure you keep count.
• Gas. Yeah. I’m just going to refer you to the National Institutes of Health.

Before you dismiss this as stuff everyone already knows, remember that we programmers are a peculiar lot. I’m not so proud to think that I don’t need to be reminded of these things.

ADDRESS IT

Set a good example. Let it be known that you are trying to turn over a new leaf. Get it out in the open.

Decide whether you can address this collectively. If there are many scent wearing individuals, consider an email to the organization asking everyone to refrain from wearing cologne and scented hand lotion. “Please keep smells as neutral as possible to help those with allergies.” It would help to switch to hypoallergenic hand soap in the wash room at the same time.

Otherwise, confront the issue with Andi one-on-one. Be direct and speak in a kind and helpful way. Most people are glad to know. The conversation may be uncomfortable for both of you, but just as he will thank you for pointing out food stuck in his teeth or something stuck to her dress, he will eventually appreciate your sincere desire to help.

Of course, the repugnance might not be a person at all, but an old chair or the carpet. I’ve seen a small leak in the restroom impact the offices on the other side of the wall. I’ve seen messy eaters leave spilt food on the carpet. Get down on your knees and smell. Wait until everyone is out of the office if you must; get someone from facilities to do it if you can. But if you are a leader in the organization, the environment is your responsibility.

SMELL YA LATER

Someone on your team has a keen sense of smell. Someone on your team smells. If you aren't the first person, think about it. You may be the second.

Use Chemical Hand Warmers for Toes?

I have been using chemical toe warmers in my cycling shoes for for a while and really love them. They are just the thing to keep your toes warm. I've been using the Grabber brand which are thinner than the little Hotties brand. (Just bookmark that link. Little Hotties is not something you want to google for.)

I picked up 8 pair of the Grabber toe warmers for $11 from www.joessports.com (12/2008). That's not a bad price, but it's just enough for me to make sure I really need them before opening up a pair. So I was tempted when I heard that Costco was selling a box of 40 pair of hand warmers plus 3 pair of toe warmers for $16 (1/2010). Any time I can get something for a third of the price, I'm all for it.

Well, you do get what you pay for. The little Hotties are great hand warmers, but they are less than ideal as toe warmers. They are the thickest of the three products shown here. I was able to put this over my toes and ride without thinking too much about them. But the flatter product is better. I'm not sure how the hand warmers would feel under my toes. Haven't tried it. Not sure I want to.

The toe warmers also have an adhesive backing which helps you get the warmer where you want it and keeps it there. And, they are larger, which helps spread the heat better over your toes.

Bottom line: Chemical hand warmers are a cheap and usable substitute for toe warmers, but they are not as enjoyable or effective.

My Chaffed Butt, Chamois Cream Review

There comes a day when a bicyclist discovers first hand the need for chamois cream. I have found myself in that situation. But if you are really frugal like me, you aren't eager to spend tens of dollars on a tube of something that you've never tried before.

My advice is to seek out some free samples, try what you have around the house, and ask your friends if you can try some of whatever they have. It's not a bad idea to search the Internet to see what other people say, but that wasn't terribly helpful to me since most of the reviews cover just one product: "I use product x on my tush and like it." It wasn't clear whether they tried any alternatives and why the other stuff was not as good. Cycling Coach Levi posted a great introduction to chamois and chamois butter but likewise did not give a detailed comparison of the products he mentioned. So that's what I try to do here. This is my first stab at a multi-product review.

For those of you who just want me to tell you what to buy, I'll go ahead and spill the disappointing beans and say that it seems that different solutions work for different people and everyone has their favorite. You might as well stop reading here and start trying stuff. For you analytical types who are interested in the experience report, read on.

Criteria
I was hoping to find a cheap solution that worked. A real value. But since my comfort on long rides is valuable to me, a product that actually works trumps cheap. My approach was to try the solutions lying around the house and those I was able to easily get free samples for. I didn't try to get samples of all options. I've been told to try Assos and Boudreaux's Butt Paste and Nubütte but I haven't gotten any.

Warning: 
 Graphic Details. Some of the following may not be suitable for young children or anyone else.

I've tried Paceline Chamois Butt'r and thought it worked fine. I had picked up a Paceline
sample at a BRAG Spring Tune-Up ride. Like many of the solutions, it's feels yucky in your shorts. Or, it does for a short time. Once it warms up and soaks in you forget about it. I don't remember its scent, which is a good thing. It's a little thicker than hand lotion, as are all of the products reviewed here.

Back in August I rode with some friends from Smyrna to Anniston, a 96 mile bike ride. My fanny faired none too well. I forgot to apply chamois cream before the ride and had a badly chaffed behind by the 60 mile point. That's about where we stopped for lunch and Bob O'Neal let me use some of his Bag Balm. Didn't seem to help, but perhaps it was too late. It also didn't smell good, but then what should I expect out of a product to rub on your rump?

The planned return trip  from Anniston back to Smyrna was the next day, so I was glad to see the Walmart next to our hotel. I didn't expect them to have any cycling specific solution to my suffering, but they did have Udderly Smooth Udder Cream. I slathered it on my hindquarters but the second day of riding was more painful than the prior. I believe the damage was already done so I can't say for sure if the cream would have prevented the problem the first day. The pain persisted for three days after.

The Udderly Smooth Udder Cream is cool and very slippery. It feels colder than most when you apply it to your posterior. It smells a little like sun block or cold cream. It's smell is mild, which is a plus for me since I am sensitive to smells. Perfumes and mediciney smells clog my sinuses and make my eyes itch.

In September I tried Balmex Diaper Rash Cream for the MS 150 on the 60  and 100 mile routes. The Balmex worked fairly well, but not perfectly. I still had hot-spots and felt the need to reapply it often. Balmex is thicker, stickier and feels drier than the Udder Cream and all of the other products here. It's very difficult to wash off your hands, something to consider on a long ride where the you may not have good hand washing opportunities. Balmex has a mediciney smell; an unmistakable diaper rash ointment aroma.

I had some Desitin Creamy diaper rash ointment on hand but chose to not try it. It is just about as thick as the Balmex and, after the Udder incident, I wanted something thick. Balmex and Desitin are waterproof, which is great on your bum but that makes it difficult to wash off your hands. Desitin has a more mild smell than Balmex. Perhaps the main reason I chose Balmex that time is that Desitin and Aquaphor and many other products you likely have lying around your house contain petrolatum (petroleum jelly). I've heard a few warnings about this ingredient clogging your pores, not washing out of shorts, and possibly breaking down the petroleum-based fabric in your Lycra/Spandex shorts. I don't know if any of that is true, so I recklessly perpetuate the rumor here.

The folks at Sportique heard of my plight (because I told them) and they were kind enough to send me a sympathy sample of their Century Riding Cream. I did a couple half centuries in November and December and used the Sportique, but the true test was the full century to Cedar Town for a snack and ride back. That was fantastic. A great trip, good friends and a nice meal.

On the way back we stopped for a break. I was hurting. Mainly my left knee and my buttocks. But the pain was in the gluteus maximus, the muscles in the rear, rather than a rear end rash. Nevertheless, as is the custom when stopping for a bio break, I applied a new layer of the Sportique. I'm not saying it was the Sportique, but that break gave me a second wind and I rode strong to the end. I had no rash that day or the next.

The Sportique is nice and thick. You know that wet feeling of rubbing on some hand lotion but not rubbing it in all the way? I got that feeling with the other products, but not as much with this one. Not sure if it's because it's thicker or because it has some kind of warming agent in it or something else. It doesn't feel as wet or yucky in my pants.

A Bicycling Magazine review says it smells like cinnamon. I wish! It smells like a medicine cabinet. It has two of my least favorite scents, eucalyptus and wintergreen. It smells like some kind of combination of those and the other 40 ingredients. That wouldn't be so bad if it was just on my derrière, but it's impossible to wash the smell off your fingers.

Sportique claims antifungal and antimicrobial ingredients. Assos claims to prevent bacterial and fungal infections. I saw no such claims for the other products.

So there you have it. I've come to think the chamois specific products have the edge, but I'd like to give Udderly Smooth another shot. If smell is not an issue for you, I'd recommend the Sportique. If it is, give Paceline a try. 

Question for you:
If you have tried more than one chamois cream, what have you tried and why is one better than the other?