Comprehensive Documentation - Bad Assumptions

Agile is easy to dismiss. Many people hear something that doesn't sound right, something that sounds different than what they are accustomed to, and they develop misconceptions. They share their misconceptions with others. They dismiss agile without any more thought. A common misconception concerns documentation.

This came across my inbox recently:

I spoke to …, and he doesn’t have a requirement for Agile. He is familiar with the methodology, and his concern is comprehensive documentation. He believes that is a critical part of development that becomes less critical with the Agile methodology.  If his assumptions are incorrect, please let me know.

Are his assumptions incorrect? There are likely a lot of assumptions in that short statement:

• "Comprehensive documentation is a critical part of development." That may be true for his project. But it is not true for many projects. If he assumes that comprehensive documentation is too critical to do without on any project, his assumption is incorrect.
• "Comprehensive documentation becomes less critical with the Agile methodology." Often this is true. But that's a good thing. So, he's probably concerned about this…
• If he assumes you can't write comprehensive documentation on agile projects, his assumption is incorrect.
  You can write all the documentation you want.

Agile simply warns against using documentation as a measure of progress. Instead, agile favors working software as a measure of progress. If comprehensive documentation helps you get to working software, or adds value after the software is written, then create comprehensive documentation. If you have a regulatory environment you can't get around, then meet your regulatory requirements, but be creative and try to find an automated approach to generating it. If we're talking end user documentation and you can't make your application usable without end-user documentation, then write end-user documentation. If we're talking about installation instructions, agile favors automation, but if you can't automate and can't make it easy, then document it. If you have published APIs, create them with great care, provide great documentation and treat them as contracts.

If we're talking about requirements specifications, agile prefers requirements documentation in the form of user stories, constant collaboration between the givers of the requirements and the implementers of the requirements, and automated story tests. If you aren't there yet, if you don't know how to do that yet, then keep writing requirements documents for now, and strive for continuous learning and continuous improvement.

If we're talking about comprehensive technical documentation of the implementation, agile favors the software craftsmanship approach of refactoring towards small methods with very clear and descriptive method, variable, and class names. This leads to readable and self-documenting code. Agile also favors high code coverage through automated unit tests, which documents how to use the implementation and the intent of it.

Every instance of agile is unique. Each adoption of agile must be tailored for the context in which it will live -- the organization.

Usually, however, comprehensive documentation is waste. If the documentation doesn't match the source code, the documentation is wrong. Documentation is almost always wrong. Using misleading documentation is wasteful. Maintaining documentation is expensive and it rarely achieves a defect free state. More waste.

At the very least, this person shouldn't throw the baby out with the bath water. A lot of value remains in agile even if he disagrees with its warnings about documentation. I'm not saying that agile is suitable in his environment -- it in fact might not be. He may have no change or uncertainty in his environment. He may have a very repeatable and predictable situation, ideally suited for a plan driven approach.


In any event, this person is most assuredly concerned about how something will be handled, be it support (handled by pair-programming and a coded test suite) or design (handled by design-all-the-time, pair-programming, test suite, refactoring) or coordination (handled by collaborative space, published and documented APIs as contracts), or etc... I could assuage his fears if I new what was underlying them. That would require a face to face conversation. I'd welcome that opportunity. With him, or with any of you, my readers, or with any of your colleagues. My email address and phone number are noted at the top of my blog. Contact me at any time.

Scrum Fundamental: Planning and Iterating

This is my last post, for now, in this series on common issues teams have with fundamental Scrum concepts. Here are a few tips, reminders actually, for planning and iterating.

Make story estimates visible to the Product Owner. Understanding the relative costs of features helps make better trade-offs.

Product Owners reprioritize work not started. Always work on the highest value story and risk reduction stories first.

Plan a second release from the start. This takes the pressure off. “We’ve just got to have feature X!” becomes “ok, we’ll put feature X in the second release and not worry about it now.” You may never do feature X, or release two, but it helps the first release move along unhindered.

If you need to know when you’ll be done, make a build up chart for the release. See Alistair Cockburn’s article on this topic.

Minimize the amount of work in process (WIP). Limit this in two ways: In each iteration, have the whole team work on just a few stories (like, three to six, depending on size). I put some rules of thumb on this in an earlier post. Don’t start work on something that cannot be completed in the iteration. With traditional project management using Gantt charts, you identify and care for the critical path. With agile projects, you limit WIP and increase cross-training, teamwork, team goals and collaboration to care for the critical path.

In addition to limiting the number of stories in the iteration, limit how many stories can be in progress at any one time. Limiting WIP to, say, one-third of the number of stories committed to the iteration might be about right. Then work towards limiting it to just one.

That’s it for now. But there is so much more that can be said. I welcome your own thoughts and lists and links to other relevant information in the comments below.

Scrum Fundamental: Communication, Delegation

I’ve been blogging lately on common issues in teams practicing Scrum or otherwise trying to be agile, and not having complete success. Yesterday's post covered a hodgepodge of items very loosely related to measuring progress. Last week's post covered user stories. Today I thought I’d talk about communication and delegation.

Communication

The purpose of the daily stand-up/scrum is communication. This is very important. The idea is to keep the meeting short (so make everyone stand) and have everyone share just the info that most everyone else needs to know. This can often be done in five or ten minutes.

Some teams cover what they did yesterday, what they plan to do today and roadblocks. It’s useful to mention some significant change that they are about to commit to source control.

Teams that are co-located and that pair-program with collective code ownership and limited Work In Process don’t typically need to discuss those topics because everyone already knows what everyone else is working on. Those teams just talk about less about what they are doing and more about their impediments – things that are slowing them down.

Decide what is most important for your situation. Whatever your standard topic is, don’t go into much detail or resolve anything during the meeting. Those that need to follow-up or work together or have a deeper discussion get together afterwards.

Whatever your standard topic is, vary it. Don’t get stuck in a rut. If you usually go in order by person, once in a while go in order by story. Throw in a different question to answer, perhaps related to something you are trying to improve upon identified in a retrospective.

The standup is a start, but don’t stop there. Stop using email. Get out of your seat and speak to someone face to face. And working with the whole team in an open space is a really really really good idea.

Delegation

Let go of assigning tasks to people. Let the team manage task assignment themselves. People will choose the correct tasks most of the time. When they don’t, let that be a learning experience.

Let the team estimate the stories.

Let the team come up with the tasks.

Make time for yourself. Take time to think about and to improve the system. By ‘system’ I’m referring to the process and the organization, not the software you are developing.

Next

Next up should be a post on planning.

What is on your short list of common problems related to some fundamental aspect of Scrum?

Scrum Fundamental: Measures of Progress

In my user stories blog post last week I claimed that problems on Scrum teams are often due to lack of knowledge about a Scrum fundamental. Today I’ll tackle the next item in my short-list of common problem areas:

• measures of progress,
• delivering value,
• demos,
• getting feedback,
• keeping it working,
• continuous integration,
• and testing.

Yeah, so, that’s more than one item, but one kind of leads to the next.

Requirements and Design

One way, the traditional way, to try to build trust and understanding between a development team and the business or client is to spend a lot of time on designs, analysis, and wirefames. The problem is that it’s difficult to predict the future with much accuracy. You will likely miss details and misunderstand how the app will be used in practice. Requirements and priorities will change.

The agile prescription, therefore, is to not spend much time figuring out details for some story that you may never implement or that may change drastically in the ensuing months. Understand the stories at a high level. Get into development and begin delivering working software as soon as possible. Get feedback sooner and begin reaping the benefits of the software sooner.

Defer any decision and any work that can be deferred. You’ll be smarter next month, you’ll understand the system and the requirements better. Let the design speak to you, refactoring as you go.

This would be a good place to say something about lean and systems thinking and Pillar Technology’s “Business value over working software” appendage to the Agile Manifesto and about not building software when it would be better to redesign the system, without IT, then automate what makes sense. But that’s another whole post.

One good thing about working software is that you can have demos.

Demos

Favor demos over status reports. After completing each small story, demo it at least internally. Get to where you can have frequent (weekly or bi-weekly) demos to your clients/users. That early feedback is very important. This also holds staff accountable for quality, for “keep it working”, and for getting to done.

The demo isn’t for the Product Owner. Your Product Owner should have been involved with the team while the story was being implemented. Your Product Owner should have seen the story before the demo. There was an interesting discussion on the Agilistas LinkedIn group about who should do the demo, and why.

Keep it Working

Employ the “keep it working” principle. Build a usable system early on and keep it working continuously. The source in the version control system must always be usable. Set up an automated build/test process using a tool like CruiseControl, Cruise, or Hudson. Have it inform everyone when the build breaks. You should have a demoable product at all times. At the end of each iteration you should have a shippable product.

This requires automated testing. Pick a level with which to start coding test cases. Most often this is at the lowest level, unit tests. I recommend the xUnit framework or RSpec, but there are other good choices. [Hmmm. I feel compelled to say something about cucumber or BDD, but I intend this to be a fundamentals post. BDD ought to be fundamental, but it isn't as fundamental as this other stuff, particularly if I'm talking about Scrum. Admittedly, this post has left Scrum and is off in generic agile-land. But I digress.]

Sometimes, however, your methods are too large and have too many dependencies to be tested well at this level without first doing much refactoring. In those cases, automate your tests at a higher layer, then refactor and employ unit testing as you go. I’ve used Selenium and Rational Functional Tester for UI-based testing, but there are other choices out there. Working Effectively With Legacy Code by Michael Feathers comes highly recommended.

If you do a good job here, you’ll reduce the amount of manual testing you have to do. You can limit that to usability, break-the-box, and exploratory testing rather than regression testing.

Just a short word about testers. QA professionals think differently and approach testing in ways that developers do not. I like getting QA involved with the developers, pairing. I like getting development involved with anything that QA is taking the lead on automating. And I really like getting QA involved with the Product Owner to help define good stories and good acceptance criteria.

Parting Note

I almost abandoned this series of posts. There’s really nothing new here. I’ve said nothing better than it has been said before. I’ve just said it differently. Sometimes ‘different’ resonates with someone who hadn’t understood the way it was put to them before. So, I’ll press on with these posts. Unless I change my mind.

Scrum Fundamental: User Stories

In my line of work as an agile coach I get to help people who are just starting to use Scrum. Some common problems crop up with many of these teams. If often comes down to some Scrum fundamentals. Fundamental doesn’t mean easy. Professional athletes work at the fundamentals and so must we.

If I had a short list of common problem areas, the neglected fundamentals might be: good stories, “keep it working”, getting to done, collaboration, and planning. That’s a bit much for one blog post, so, maybe over the next few days I can address these in a series of posts. Here’s the first.

User Stories

Analysis of a business problem yields features that may either be “stories” or that may be broken down into stories. The first pass will have stories that have some very important parts as well as some less important parts. Identify and implement the most important stories first and address risk first. Defer as much as possible to the end of the project.

That sounds obvious, but it’s so easy for a developer to “just add this in while we’re working in this area.” It’s seductive to the Product Owner to want to “round out” some feature set. So many useless features and dead code gets bought and paid for that way.

Maximize the amount of work not done. Be ruthless in deferring what is less essential until later; you might not ever have to do it. Don’t build frameworks in advance or build support in for features you plan to work on later because You Aren’t Going to Need It – the well known YAGNI principle.

Split Stories

The approach here is to split your stories. The “User Management” story becomes “Add Users”, “Delete Users”, and “Modify Users”. You might never implement Delete, and Modify isn’t needed in the first release. You may further split Add User into basic and wiz-bang versions. This can likely be split further to deal with different types of users, assorted permissions, error cases, cascading, and more complex attributes of the user. After splitting, implement the most valuable stories first, of course.

Each story should have some value to your business/client/customer, particularly to an end-user. Each story should deliver some function from top to bottom. It should be a complete vertical slice through your application. Don’t divide stories along architectural lines. Avoid technical/horizontal slices (the DB framework, the complete object model, all the UI components). For the “user management” story, don’t have a story for the UI and a story for the backend.

Spike Stories

Use spike stories when you need to figure out how to implement or estimate something. A spike is a short time-boxed experiment or research, with a specific objective to address unknowns and risks. The conclusion of a spike may beget more stories and spikes.

Rules of Thumb

Some rules of thumb for story size:

• One story should not take the whole team more than half the iteration.
• The team should be able to finish any story in one to two days for a one-week iteration.
• The team should be able to finish any story in one to four days for a two-week iteration.
• Aim to have 3 to 8 stories for a one-week iteration.
• Aim to have 3 to 8 stories for a two-week iteration.
• If most of your stories can be done by a person in half a day, they are too small.
• If your team is doing more than 8 stories per iteration, your stories are too small.
• If your team is doing more than 9 stories in a three-week iteration, your iterations are too big.

Remember, these are just my rules of thumb. There are valid exceptions.

Summary

Poor stories will make Scrum painful. I’m not the first to write about good user stories, not the most eloquent, and won’t be the last. If what I’ve written describes your problem, read more about it or find a good coach. I’m available.

Question for the day

Disagree with my recommendation? Have a better way to word this? Hate my rules of thumb? Have a better blog post on user stories? Post your thoughts or post a link.

Scrum Master? Or coach?

I've seen many more open positions for Scrum Masters than I have agile coaches. I've been asked to be a Scrum Master more than I've been asked to be a coach. Is it just marketing? Scrum has market share; it's widely known and understood. Does the market distinguish between a Scrum Master and a coach?

I often find that companies looking for a Scrum Master want someone to run their standups, planning and retrospectives. They want an agile project manager to manage the projects, to report status, to track budget.

They seem to not want the change agent and process improvement aspects of the Scrum Master role. Or, they want a little change agent and process improvement to happen as long as it's directed towards the team and not management. And anything directed toward the team mustn't involve facilities or pair programming. Or HR. Or empowerment.

But isn't that what a Scrum Master is supposed to be, a coach?

I dislike this dichotomy.

There was a recent discussion on the Agile Alliance discussion group on LinkedIn about the career growth path of a Scrum Master. The question was, is there a growth path? I liked Irene Michlin's response:

Have they all brought their teams to "performing" stage? Process is perfect, as in "nothing left to improve" a constant motive in retrospectives?

They are either all very brilliant and need to go and become trainers and coaches, or they don't get what it means to be a Scrum Master.

If there is something left to improve, then your job as a Scrum Master is not done -- you haven't mastered Scrum Mastering. Or, at least you aren't done coaching. But there is that distinction again.

I dislike this distinction between Scrum Master and coach. Unfortunately, I find it useful. It's a tell, as in poker. It helps evaluate an opportunity. It's how the conversation goes. "No, I won't be your Scrum Master, but I'll gladly train your team to handle this role. I'll be your coach. Are you ready for a change agent?" Sigh. I find it useful, therefore I tend to perpetuate the distinction.

What should we do? Not use the term coach and elevate the term Scrum Master? Should we live with it because it is what it is? Once the dichotomy is there it's not possible to kill it. Is there a useful distinction between the two?

CAN: Shifting the Voice of the Business to the Team

I've been thinking about Mike Cottmeyer's "12 Keys to Success with Agile", specifically his bullet #3, single voice of the business, where he says "This cannot be shifted to the team..."

It can.

Earlier this week Scott Chacon of GitHub presented his approach to projects, called Developer Driven Development, in a keynote address at CodeMash 2011. I won't try to explain DDD here, since the details aren't germane to this post.

However, key to DDD is that you must have careful hiring practices, careful to the point that you only hire people that already demonstrate a commitment to the project and possess great knowledge of the domain. (My words, not his, but I think he'd agree.) Hire those that are already involved in the project or in related ones. Clearly, to be already involved in the project before you are hired likely implies you are either involved in an open source project or are an actively involved customer or user of the product, be it open source or commercial.

Can that be applied to Corporate America? Not completely sure, but we can certainly apply some lessons. If your team hasn't already caught the vision, you need to help them catch the vision. This is important on any project, agile or not. But its importance is indirectly proportional to the extent to which you have an effective voice for the business involved with the team. That is, the less that the team understands the business need already, the more that vision casting is needed. The more that the team knows the business need own their own, the less involvement the team needs from "the business".

I've been on at least one team of note in Corporate America that the single voice of the business was successfully shifted to the team. In this case the team sold the business on a need. The team was given the leeway to run with the idea. Each person brought to the project what they thought the project needed. Each person on the team had a voice in prioritization. Anything that was to get done had to have the support of the team. (So, this wasn't a free-for-all to the extent that an open source project would be. Everyone did not go off and build whichever feature they wanted. The team agreed to the iteration's backlog.)

This worked because the team wanted it to. We wanted to keep doing what we were doing. We liked the product, the project, the team. To keep it going we had to demonstrate value to the organization that was paying the bills. So, we listened to those using the product and took their needs and suggestions into consideration.

It worked much like the open source model: I build what I want, what is interesting to me. But motivation is multifaceted. I'd like help from others, so I have to consider their interests. I'd like my product to be useful, to be used. I'd enjoy a little fame or appreciation from others. I'd like enough money out of the project to take money off the table. So if I'm relying on the product to pay the bills or support my multifaceted motivation, then I'm going to listen to my users and supporters.

It's going too far to say that you cannot shift "single voice of the business" to the team. A trusting cross functional team with empowered team members sharing accountability who have the vision can BE the single voice of the business.

Wearing the Right Hat

A Scrum Product Owner at a client of mine once told me he didn't trust development to build what he wanted built. Sadly, I find this quite common with the more technical POs. The lack of trust was largely due to his negative experience with some other dev team at a different company. His concern was that future value would be blocked by using a simplistic approach now. This PO therefore stepped way over the PO/DEV responsibility line into specifying some of the "how" for a set of stories.

Lack of trust is a significant issue. I could have told the PO that he needs to be able to trust the team. I could have suggested he create opportunity to build that trust, or change the team. Either way, that would take some time and we can work on that. But that's not the focus of this post.

And I could have explained emergent design and the danger of over-architecting things now. I could have told him YAGNI, but have also said that it is okay to share the big-picture vision with the dev team. That it's okay for the dev team to think about where they are headed long term as long as they "pay as you go" and not design and build too much up front. But that's not the focus of this post either.

The focus of this post is that I told him it was okay for him to not trust the developers for now and that it was okay for him to step over the line.

Now, before you take away my Agile Badge, let me explain myself.

Product Owner	Architect

I told the PO that if he is technically capable and can pull it off, then he can AT THE APPROPRIATE TIME review development's planned approach and make suggestions. I told him he can have a PO hat and an architect hat, but that he can only wear one at a time and he needs to wear the correct one at the correct time. He must wear the PO-only hat and only the PO hat during the planning game. Once the business requirement is sized, split, resized, scheduled, and planned, he can visibly remove his PO hat and put on his architect hat during the design and tasking part of the sprint.

In this case, I told him that I believe he is wrong and most likely doesn't need what he was requesting and that what he was requesting will greatly complicate the design and require much much more code than necessary. There was a better approach. Nevertheless, I didn't tell him not to put forth his ideas. For me, it's just a matter of timing.

What would you have done?

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.