Agile NYC version of the Multi-Sensory Kanban talk

Why do companies like Toyota and Zappos open up their shop floors for tours? It's because they know visitors won't be able to replicate their culture, yet Toyota/Zappos may learn something from a visitor's questions. So these companies actually have something to gain--and little to lose. Their culture of continuous improvement is almost impossible to replicate--which is exactly what Ravindar and I have witnessed in multiple environments that are implementing Kanban. As a result, we've come up with a series of tactics to help teams develop a learning culture--nothing that would surprise you in a healthy Kanban system--but signals that aren't written about elsewhere.

This week I was invited to talk about Multi-Sensory Kanban for Agile NYC, so I've decided to share the slides here. In a nutshell, this is a talk about how to keep a kanban system healthy. We find that a focus on work-in-progress and flow blinds people to the whole system; our minds tend to lock in to either in a synthetic (whole-system) or analytic (subsystem) mode, and we need regular reminders to switch between the two. Since Kanban is normally a visual control system, and therefore the visual channel is already saturated, we encourage teams to use signals from our other senses, most notably the auditory channel and kinetic channels.

These slides have few speaker notes; if you'd like to learn more please invite us to speak! It's easy to get in touch with me-- write to andre -a-t- dhondt-teams-gel -d-o-t- com.

vote Dan Mezick for the Scrum Alliance Board

If you care about the Scrum Alliance, or have benefited from its work, please vote for Dan now!

Why? Dan Mezick will make the SA stronger by encouraging discussions on ethics and promoting service over profit. Read more about him at http://newtechusa.net/agile/scrum-alliance-bod-election/
In Agile Boston, he’s led a team of organizers to live by these values:  http://newtechusa.net/user-groups/ma/visionmissionvalues/

Who else is running?
 If you Google the other candidates, Stephen Forte and George Gosiski, you'll see they haven't had the same reach or impact as Dan. Their qualifications show they are definitely strong Agile team members--but I'd much rather depend on someone that's a great organizer to bring the Scrum Alliance to the next level.  That's Dan!

Who is Dan? Dan is an accomplished Agile coach, speaker, and mentor, has come to Agile Philly to speak, and knows his stuff. He's long been a community organizer for technology professionals, and cares about delivering value to both the community and his clients.  Vote for Dan today! – it’s just two-clicks to vote!  I know Dan personally and fully endorse his candidacy!

When? The elections will close in the next 10 days. Vote for Dan today!

Announcing a new PMI-ACP course with coaching

Are you in the Philadelphia region (<50 miles from center city)?  Want to take the PMI-ACP exam, but need help getting ready for it? I'm offering a 21-PDU, 3 full day (or 5 half-day) course. Read more at my corporate site: http://www.dhondt-teams-gel.com/services/pmi_acp_course

Why take the course from me? You'll get two half-day coaching sessions included in the price of your team's classes (for every 5 paid participants). It's hard to apply all this knowledge--so why not take advantage of a local coach that can help you implement what you've just learned?

toward more effective communication

Over the past year I've gone to at least 4 workshops on more effective communication, and I'd like to comment on my take-home messages from each, rather than a summary of what happened. When possible I've linked to online summaries of the session content or an explanation of the ideas.

Powerful Questions presented by Carton Nettleton -- summarized by Sam Laing.
Assuming we have established a trusting relationship, it's much more effective to ask open-ended questions, or even questions that help others analyze a situation. Listed from more powerful to less, we've got:

• Why
• How
• What
• Who/when/where
• Which/yes-no questions

The questions at the top help people process the information themselves.

Refactoring Conversation Smells by Gil Broza & Luiz Claudio Parzianello
deletion - generalization - distortion; deletion is summarized by Esther Derby.
Just as in Weinberg, Seashore & Seashore's "What did you say? The art of giving & receiving feedback", it's often very useful to extract comments from their emotional wrapping (distortion). Or, to follow up with a person for more specific information (generalization), or to ask for missing information (deletion).

Wendy Thompson's presentation of the Four Horsemen that kill teamwork
stonewalling - contempt - criticism - defensiveness
These are red flags in a team environment. When you see them, dig further to find out what's going on.

Pat Arcady's Open Space (slow download) session on Navigating Conflict with IntegrityIt was interesting to see Pat in action--she's a skilled mediator/facilitator, and she taught me to hold back more so that people around me can show their smarts when they discover what a workshop is designed to help them discover.

Failing Fast slides

For Agile Day NYC, I was invited to give a Pecha Kucha talk, so I decided to cover Failing Fast. It's hard to capture a PK talk online, but the short version is: failing fast is all about learning. To foster learning in our own work environments, we invite our colleagues to be curious, to ask how we can find out sooner, and to use set-based design. Failing fast breaks the monotony of failing slowly, and makes work fun. Read more in the linked slide deck!

Freedom in Meeting slides

In September at Agile Boston I ran an open space session called Freedom in Meeting (this link to the slides includes speaker notes). The short version of this talk is: when we bring open-space ideas into our daily meetings, they become more effective, are shorter, are more interesting, and have better participation from everyone.

Agile Coaching Ethics

Recently Dan Mezick (of Agile Boston and Agile Connecticut) has been writing about Agile Coaching Ethics. I welcome this conversation, and agree that a coach cannot be embedded to be effective. This is something I've come to learn the hard way--and was greatly inspired by comments at Rachel Davie's Grumpy Old Coaches panel at XP 2011 (Madrid).  Currently I have to admit that I do both contract work and coaching--but I have been clear with my clients that there is a difference and that I want to focus on the coaching. I've always measured my success by how well a team does after I've left--but I'm learning better and better ways to do this. My mantra, these days, is "I do nothing, I own nothing".  When I follow this mantra well, the teams I work with do better too--they become Leaderful Teams.
So let's work together as a community to make expectations clear about what a coach does, and doesn't do. Here's my stab: An Agile Coach helps a team shift its perspective, thereby allowing the team solve its own problems.  I also second George Dinwiddie's definition:

[A coach] build[s] the capability of the existing team. Rather than making choices for the team, the coach provides guidance about the choices available, perhaps making recommendations, and encouraging them to consider the options and choose their actions. The coach teaches the team about techniques or tools that increase their available choices. The coach offers observations about the team’s activities, and helps the team make it’s own observations and reflect on them. The coach helps the team articulate the results it wants, and generate courses of action to achieve those results. The coach partners with the team on the coaching process, but allows the team to exercise its own judgement about the software development practice. The coach does not become a member of the team, but endeavors to wean the team off of the need to consult with the coach on a regular basis.

With this kind of definition of Agile Coaching, I believe that clients will benefit even more from coaches-since there's the expectation that the coach isn't always there, and for that reason will be more likely to bring ideas in to the team from other environments. Another slant to this is that to me, a key responsibility of a coach is to go out and learn as much as possible that can be applied to the teams being coached.

What Dhondt Teams Gel is all about

Too busy fighting bugs and doing rush jobs? For less than the cost of getting your team certified, contact us to coach your team to more effective, higher quality software (if you're in the greater Philadelphia region)! Dhondt Teams Gel is staffed by yours truly as well as an associate or two when we need a second opinion--all for the same, low monthly subscription. Subscription rates vary, but are approximately the same price as a one or two-day training course. Basically, you don't pay until our coaching delivers real value to your organization--and even then, we are so confident that our results work in the long haul that payment for our services is made in a two-year annuity.


Pay for Results, Not Hours
Many coaches charge by the day or by the hour--regardless of the outcome of their work. Some offer satisfaction guaranteed--but still charge before the results are realized. If we're working on cutting the cycle time of your dev team by 50%, you don't pay anything more than a flat subscription fee until you're seeing working software sooner! Our Coach on Retainer product is only profitable when we deliver results for you!


Training Plus Coaching
We also offer training workshops and soon we'll offer classes for a certification program (no official announcement yet). Since I believe that training and certifications are just the beginning of an intentional learning journey, I also include two "refresher" visits in the price of any class with 5 or more participants from the same company. It's the long-term relationships where we provide the most value, and that's why we want to visit course participants again and again.

Communication About Design Workshop Series

Since a client of mine asked for help on communication skills in the team environment, I've been doing a short series of workshops on the topic (60 minutes each). For the first workshop, we did the [spoiler warning]: Marshmallow Challenge. Many participants enjoyed the workshop and saw how some of the teams had worked together while others had participants that checked out entirely. We talked about what it would take to work together better, to make a higher tower, and whether they've seen similar performance problems in the work environment. Normally I have everyone start this workshop at the same time, but in this instance we had some latecomers who began after they saw the final result of the other team's towers. The first two teams had built towers at 0 inches tall (it was unstable) and basically one spaghetti stick tall--and the latecomers were determined to win--so they focused on a design that would get them two sticks tall, and prevailed. Of note is that the teams that worked together by talking through and adapting their design ideas, succeeded at building something stable, while the team that had some people check out were unable to adapt their vision to something more stable.
For the second workshop, I adapted a game invented by Olivier Albiez and I--a brainstorming activity designed to show ineffective communication. We had 4 local participants and two remote (through a teleconference bridge). To make things more dysfunctional, I randomly gave each participant a 'vice card', with one of the following captions:

• ignore it
• criticize it
• be defensive
• say it's too simple
• support it
• rephrase it in your own words and ask if that's right
• ask clarifying questions

We tell participants they'll be brainstorming, and that no matter what anyone else says, they're to follow the instructions on the vice card in their response about the idea.  The same vice cards can go to more than one person; they're actually just a tool to save face for anyone that has a strong personality.
We set the stage by saying we're designing a fire safety kit to be used in office buildings, which includes instructions and basic fire safety essentials. All the participants are asked to do is to list what should be in the kit and/or on the instructions. As the moderator, my job was to write down any idea I heard as the group made suggestions. As you can imagine, hilarity ensued. People argued about every idea, and they repeatedly had me change the words I'd recorded. We ran this session for 7 minutes, followed by 5 minutes of observations like:

• we didn't get very many ideas
• almost every idea was from the two most vocal participants
• people on the teleconference bridge couldn't get a word in edgewise
• few people were listening or building upon others' ideas

We did one more round, this time without the vice cards, and people were more respectful of the phone participants--but the list was basically as short as before. Why no additional creativity? Here's what we came up with: 

• the product goal wasn't clear--was there a market for what we were building?
• participants who were now listening said they didn't understand their colleague's ideas, and so asking questions slowed them down from coming up with new ideas

For the third round we said we'd pick what goes in the tool bag for a long bicycle ride. In the first 90 seconds one person seemed to misunderstand the task, an argument ensued and the confused person never spoke again. We discussed this in the observations step, but offending party didn't accept the feedback--saying that person's ideas were off-target and so were rightly rejected. Based on this, I think I'd need to do yet another round, or to change the topics for each brainstorming session so people would be more likely to learn what it takes to brainstorm effectively.  Has anyone here played a similar game?
Overall, I'd say I'm happy with this workshop--I was hoping to create a situation where communication broke down, and we could get people to talk openly about it. I wish we could have gotten there quicker--and so that's what I'll work on the next time I run it.

The third workshop is yet to happen, but I'd like to get this team comfortable identifying "criticism, contempt, defensiveness, and stonewalling" during their planning sessions. I'd also like to set clear ground rules that prevent arguments, allow only simple explanations, and focus on moving forward (and even capitalizing on misunderstanding).

For the fourth workshop, I'll have the team quickly draw our real system architecture in 60-seconds, then ask what we'd have to change to support a real backlog item. There are two objectives in this workshop--to learn to manipulate our system architecture quickly and easily, and to learn to talk openly about new ideas. I don't know if we'll be ready for this by the fourth workshop, but I'll report back here!

3 Questions Considered Harmful

Since I've been reading a lot of pre-agile books, Dykstra's GOTO Considered Harmful seemed fitting here.  I think that the standard three questions for Daily Scrums (what did I do yesterday, what am I doing today, any blocks) should be considered harmful, because these questions force people to focus on themselves--and we want people to focus on the team! So for years I've been experimenting a lot with the Daily Scrum, by changing the format with  hot potato, pull, and synchronization points, and by changing the questions:

• are we on target to finish this iteration on time?
• what's important?
• anyone want a second opinion on something they're working on?
• any decisions to be made by the group?
• what's left to finish the iteration?
• what can we deploy next?
• open-ended questions about stories that are active
• any topics for the parking lot?
• any ripple effects? [that is, for something I just changed or am about to change, who needs to know and what effect with it have?]

It would be great if we had a stable list of questions, but I find it more effective to use two or 3 from the list above for a month, then to use a new set--it keeps people on their toes, and this thinking creates better communication.

To help clients and conference attendees see what I'm talking about, I've also prepared a slide deck entitled Freedom In Meeting.

Technically Philly Groups

Learning and Networking
Have you ever wanted to talk to other people using your favorite new development language--but just didn't know where to go? Have you ever wanted ideas on how to improve your teamwork or software development life cycle? Or do you just want to network--trying to find a job or trying to find good recruits?  Imagine a place you could go meet talented and passionate software team members--and you only had to wait for the right day of the week, since we've got events booked every week for the foreseeable future!  Welcome to Technically Philly Groups, a consortium of existing technical user groups in the greater Philadelphia region and an incubator for your favorite topic!


Values

Technically Philly Groups is founded on the following principles:

• Serve Others: we all do better when we share what we've got. Sometimes all we have to share is curiosity; other ways we can serve are to: teach; sponsor food for an event; bring a friend to an event.  We believe in, and live by the principles of, a gift economy.
• Create Relationships: we care about the long-term sustainability; we seek win-win opportunities by getting to know one another well enough that we can treat others the way they'd like to be treated.
• Increase Learning: the more we learn, apply what we learn, and validate that it's useful, the better we'll be at our jobs (whether we're in a start-up environment, academic institution, public service, or established business). The purpose of our meeting together is to learn from one another, and to accelerate our ability to deliver results in our software/technical environments. We also believe that learning is maximized when we're having fun--and joy at our events is closely tied to supporting autonomy, mastery, and purpose in the way we structure discussions.

We expect Technically Philly Groups events to be a hub of innovation, communication, and learning. We know that by uniting together we'll help build a more common language for talking about technology, ideas will spread faster, and we'll be able to show what topics we value.

History & How to Join
On June 15, 2011, organizers from 21 user groups founded Technically Philly Groups. Since then we've helped promote one another's events, attracted another 10 groups,  held co-located events, and have shared sponsor money to feed our attendees for free. If your group would like to join, contact us at http://groups.google.com/group/tech-philly-organizers.

loneliness and conference assimilation

Recently, I've been saying that conferences leave me feeling lonely--ironic, since I typically meet 20 people per day and have interesting, deep conversations with at least 5. I know from conversations on the topic that I'm not alone in this experience, yet I also know I'm contributing to the problem. How do I contribute?  It's this game I play--at every conference meal, I sit with strangers, so I can get to know more people. Sometimes we hit it off, sometimes our conversation is forced and dull. By never returning to eat with the same people, though, I'm implicitly saying that none of those new connections are important. In other words, if I don't show that "I like you" by finding you again, it implies that I don't.  That's not an accurate conclusion--I'm just trying to meet more people--but the more people I meet, the more people I leave feeling lonely. With lots of people playing either this game, or sticking with the people they already know well, odds are that many of us aren't feeling the love.  Within three days at these conferences, I typically have talked to 100 people or more, and I can always find someone I know to talk to during a break... but by this point I feel utterly vulnerable and lonely.

Loneliness is not just for Conferences
How do you feel, commuting to work? Watching TV? Reading a book? At the end of these activities, are you satiated? While these activities can be unavoidable, cathartic, or intellectually rewarding, respectively, they're not as emotionally rewarding as a long dinner conversation with good friends. Humans are hard-wired to seek, and to crave, emotional connection. In Community: The Structure of Belonging, Peter Block talks a lot about loneliness, and how to break the cycle by creating things together. Conference organizers, and even speakers, often feel connected to each other and to the community, due to the fact that they've worked together (in small groups) making the conference. Attendees, however, have an entirely different experience until they connect to a small group.

Self-Improvement / Specialization also causes Loneliness (and myopia too)
Since I'm so passionate about software process and teamwork, I spend most of my spare time (at least non-family spare time) reading blogs and books in the lean/agile domain.  Unfortunately, all this reading is lonely work--I'd love to talk about what I'm reading with my family, friends or colleagues in the office, and often mention it--but few other people are interested. So not only does this specialization make me lonely while I'm reading, but also when I try to chat at work. All this makes events at Agile Philly and conferences more important to me.
Even worse, specialization doesn't even give us the mastery we seek.  We've learned from the wisdom of crowds that experts and specialists are less likely to have the "right" answer predicting the future of complex situations than a crowd of competent generalists. Why? For any non-trivial subject, specialists must focus so much on one aspect of a problem that they miss the forest for the trees--and can't make holistic evaluations. So what good is it to isolate oneself, to focus on a topic to the point of mastery, if we'd simply be more wise if we spend time with other people?

Building Relationships
How do we break out of this loneliness? We build something together! In my next post I'll talk about Technically Philly Groups, a community built to promote networking and learning in the greater Philadelphia  region.

Conference Format Can Help Too
As David Rock says, people go to conferences for a couple of main reasons--to soak up new information, and to meet new people.  Rock argues that in this age of going online for our information, maybe the priorities of these two goals are backwards for most conferences. I agree. I don't want to sit in a room with 100 other people, staring at a speaker for 90 minutes, without a chance to speak up myself. If that was my goal, I would sit all by myself at home and listen to podcasts or watch conference videos. Rock breaks the mold of multi-track big conferences by imposing some interactive structure onto all conference speakers--something he calls DEAQ (at least every 30 minutes, stop for digestion, application, exercises, or questions).  I don't think he goes far enough, and prefer Pecha Kucha Pull (3-5 minutes of oration designed to provoke questions, followed by Q&A, then repeat) or repetitive exercise-then-debrief. I really expect more conference organizers to focus on session format.  Last year at XP2010 the organizers had a great variety in session formats, but not this year for XP2011 nor LSSC11. I'd even be happy to see more Bar Camp or Open Space style sessions... though I love Open Space, speakers rarely show up prepared to the same extent they would for a planned talk. Let's be agile about our conference talks--come with a deck of slides, prepared to talk about a variety of subjects, advertise those ideas, then let the audience  'pull' the information out of you!

Unconferences Don't work For Newbies
This past week at Agile Day Boston and Agile Day NYC, I applaud the organizers (especially Dan Mezick and Joe Krebs) for combining planned talks and open spaces in a one-day event. Even keynotes were limited to 20 minutes in Boston--letting us whet our appetites on ideas from many different speakers. Following the planned talks, we had afternoon open space sessions that attracted a huge number of topics and participants--as well as a sense of belonging!

Conference Season is Coming

Soon I'll be presenting, with my colleague Ravindar Gujral, at the following two conferences:

LSSC 2011, Long Beach, California, 1st week in May: Multi-sensory Kanban
XP 2011, Madrid, 2nd week in May: You Get What You Measure

Work on these presentations over the last few months has kept me quiet on my blog.

If you'd like to see these at Agile 2011 in Salt Lake, please click on the session names above and add a public comment!

magic

Magic--Beware?
As Jurgen Apelo shows, people don't trust magic. Oracles, witches, magicians, and even mad scientists have long lived on the fringes of society. A colleague of mine considers the word 'magic' a sign of incompetence or an over-reliance on luck. For Jurgen, magic is the art of illusion. Rather, he prefers the scientific method--repeatable, and rational: "When determining whether something exists or not, rely on the words of the scientists, not the hands of the magicians." But is there nothing good in magic? I recently went to a re-creation of a medieval warlock's workshop--and was captivated by the wonder and excitement he inspired in my children. As a person who focused on chemistry in undergraduate school, none of this show was new to me--I could picture the chemicals he'd chosen, explain the colors, smoke and fire, and remember working with some of these materials myself. Was the warlock's work all an illusion, all unreal?  I do see that his storytelling was not an explanation of the chemistry, but what is his purpose in the show? Can we dismiss it because it is not serious? What about learning through play, the agile trend to play serious games, and multi-sensory learning in today's schools?
What is more likely to create a a desire to learn more about science--a magic show, or a dry lecture? I think that the test for what is real is misguided--why limit ourselves to what is real right now? To an extreme: is the wonder and excitement our children feel after hearing fairy tales an illusion? No! Their hope, their hearts full of wishes, drives them to play, to experiment, to try new things. Magic unleashes our imaginations, it is the key difference between humans and machines, it is the ability to act irrationally against a set of known laws and scenarios. Instead of mistrusting magic, let's use it to our benefit.

What is Magic?

To me, magic is using uncommon knowledge to produce dramatic change. Another key element of magic is the artistry--the holistic view, as opposed to the scientific analysis. Science brings us understanding, reproducibility; magic brings us inspiration and discovery. It is that which gets our feet tapping to good music, it is the way good food makes us want to share it with others, it is the power a good story or show has over our emotions. Magic is that which gives us life energy, the contagious, social power that makes us human--simply, it is passion for the work we do, it is love. Magic is what makes work fun!

How do we bring magic to work? It's hardly prescriptive. Magic may use science, timing, charisma, skill, or craft, but is more than any of these--it is an art. Just as jokes go stale, magic only mystifies when it's fresh. Furthermore, a true magician has rehearsed and knows how to handle an unexpected turn of events. We show people things they can't make sense of. We support the irrational, and we bring magic into work by staying current, by keeping healthy amounts of slack, and by practicing in a playful manner, both at work and after work.

Magic--Making Ideas Real

In a lab environment, a scientist is trying to control for variables and principles that are not yet fully understood.  Science makes history repeat itself--but magic is the key to creating something new: invention is 99% perspiration and 1% inspiration. This environment makes inspiration more likely, but only rarely does one make a breakthrough to a great, new idea. All of this makes me believe that we need more magic in the software development world, just as Beck has urged us to "embrace change", and as Ghandi encourages, "be the change you wish to see in the world". It is not more control, more repeatability we need in this world--that's why we hand off the most boring tasks to machines. What we need more of is magic/inspiration. Rather than asking if something is real, let's imagine the possibilities brought to us by magic--the suspension of disbelief--the creativity lurking behind our self-imposed barriers.

hot-potato daily Scrums

There's a client I'm working with that always uses a teleconference bridge to include remote team members and stakeholders in the daily scrums. Though I have done remote scrums in the past, I've always had a hard time hearing some people on the other end of the call, and I also found it to be exceedingly boring--something about the remote/virtual team puts pressure on people to talk a lot while they've got everyone's attention on the phone. A couple months ago we changed our Daily Scrums to be more self-organizing: at the first second of our 9:30am call, every developer present chimes in by announcing her/his name. The last one to 'arrive' shares what needs to be said, and calls the next developer. This forces everyone to at least remember who's on the call, and who has spoken--and it also helps people pay attention to one another better. Yet we noticed it wasn't helping the chickens much--so someone suggested yet another modification. Now, after the chime-in by developers, chickens chime in too--then it's a chicken who calls the next developer. Well, it's been great fun passing around the 'hot potato' as well as catching the chickens that aren't paying attention!

Do you have any phone-conference Daily Scrum tips to share?

fighting inbox clutter

For my current client, I'm spending an inordinate amount of time reading e-mail just to keep up with what's going on in the project--inordinate, I think, because I've never gotten this much mail in any other work environment. This e-mail comes from a culture of copying everyone on the most trivial messages; another is the habit to send e-mails instead of stopping by someone's desk, calling, or sending an IM--all of which are superior in most contexts because they're synchronous. As I've mentioned on Twitter (@adhondt), I've tried sending no messages--but there are definitely situations that e-mail and its asynchronous communication is better--for example, for sending and accepting meeting invites. Yet whenever I respond to an e-mail, I find it spawns more e-mail--someone inevitably responds to my message--so I've decided the most effective way to fight inbox clutter is to send fewer notes. It's been hard for me to remember, sometimes, not to reply to messages someone sends me--so I've configured some Outlook macros to remind me. I also added a line to my signature:

* Fight inbox clutter. The total number of messages I sent today (instead of closing the loop with a visit, a phone call, or an IM) is indicated at the end of the subject line as (sent / quota). 

My quota, admittedly a constant in the code, is 10 messages/invites per day--and though there are days I exceed it, I think it's my average.  I've also made this a public quest, explaining to people each time I follow up synchronously to an e-mail, that I'm stopping by because I think a conversation is a quicker way to resolve the issue than to respond with another e-mail.
We're using Outlook 2007, so I set up this VBA macro to remind me about my quotas. Tell me if you use it!

'About: D. André Dhondt, dhondtsayitsagile.blogspot.com 

Dim WithEvents loadedMail As MailItem

Private Sub Application_ItemSend(ByVal Item As Object, Cancel As Boolean)

    Cancel = canAvoidEmail()

End Sub

Private Function canAvoidEmail() As Boolean

    Dim areYouSure As String

    areYouSure = "You've already sent " & countSentMessages() & " messages today. " & _

        "Are you sure a visit, a call, or an IM wouldn't resolve this? Click OK to send."

    

    canAvoidEmail = (MsgBox(areYouSure, vbOKCancel) = vbCancel)

End Function

Private Function countSentMessages() As Integer

 Dim sent As Outlook.MAPIFolder

 Set sent = GetNamespace("MAPI").GetDefaultFolder(olFolderSentMail)

 countSentMessages = sent.Items.Restrict("[SentOn] > '" & Format(Date, "ddddd h:nn AMPM") & "'").Count

End Function

Private Sub Application_ItemLoad(ByVal Item As Object)

  If TypeName(Item) = "MailItem" Then

    Set loadedMail = Item

  End If

End Sub

Private Sub loadedMail_Open(Cancel As Boolean)

  If loadedMail.sent = False Then

    loadedMail.Subject = loadedMail.Subject & " (" & 1 + countSentMessages & "/10)*"

  End If

End Sub