Why Batch Defects If You Don't Batch Email?

One way to think about it is that you probably prefer to answer emails throughout the day rather than at the end; you want to deal with bugs during the sprints.

Of course, I fully agree that you need to deal with bugs during the sprint/release, or in other words, keep the number of Bugs In Progress limited. (Is anyone for the Limited BIP society?)

But the email parallel doesn’t convince me.

many productivity experts (e.g. http://www.inboxoverload.com/time_management-partI.htm) will tell you to turn email off for most of the day, and open it in specific slots throughout the day, to avoid context switches, etc. This will protect your flow on the tasks you should be focused on.

This is btw different between managers and makers, and is similar to how their calendars look like (see a great post by Paul Graham ). I would say that the more reactive your role is, the more responsive you probably need to be to email, and the less actual creative flow you can expect.

When you do need to make something, TURN YOUR EMAIL OFF.

I would add a caveat to this rule to say that in collaborative environments like Agile teams, care and balance need to be applied to allow both Flow and collaboration/fast feedback/osmosis in the team.

Now what do we tell those makers of software, that we instruct to ignore their EMAILs for most of the day? that they need to deal with defects as soon as possible? Why?

The reason its different is that emails during the day don’t really “ROT” like the vegetables in the market, do they? or at least a major part of them doesn’t.  The cost of addressing an email a few hours late is not much different than addressing it a few minutes after its sent.

Again, the caveat is those decisions others are making in our team, that they want fast feedback and collaboration on. We should find a way to allow those to come in (maybe by coming by and talking?), maybe by marking the emails from the team as higher priority, whatever.

Defects or decisions in software development, in general, are different. The cost to deal with late feedback is exponentially higher as time goes by. Also, having a large inventory of those issues risks the release since you don’t exactly know how long it will take you to fix all of them.

See this classic piece by Scott W Ambler…

Back to email - yes, if you keep all emails to the end of the day, you don’t know exactly how much time it will take to fully address them. but you can decide whether you are scope-driven so you get to inbox zero every day (check out 0boxer btw for a nice gmail extension that makes a game out of this…), or whether you give a time-slot priority based and do what you can, and periodically deal with the overflow.

For sure, probably reading your mailing lists (e.g. kanbandev, agile-testing) are all highly valuable, but can be described as intangible benefits to the day, so can be scoped out if necessary. Again, some of us actually see participation in the lists as a tangible ROI, but then probably the way to deal with that is put it on our schedule, think about the appropriate SLA, etc.

If its important enough to answer in realtime - then by all means make kanbandev a high priority email in your inbox and let it thru. Have it SMS you, twit you, whatever. But be aware of the decisions you are making. This is similar to managing demand for a product development group…

The decision about the level of WIP and cycle time you are shooting for should be an economy-driven decision. both context switches as well as late feedback have a price, in the waste they create. you need to weigh the price and decide what is best for your context.

The reality of product development in most of the projects out there, seems to be that its MUCH more economic to build quality in and don’t let defects rot outside in the sun.

PS If MY inbox were turned off, I would probably not see this email from my colleague and write this post. Now, what would be the price if I answered him in the evening? The cost of answering and dealing with the feedback would probably be the same. Thinking about it caused me to switch contexts and write this blog post.

Now, I usually defer answering to such emails and writing blog items (I use rememberthemilk.com and have various draft post ideas there that I get to at some point). If I was perfect, my algorithm for when to answer and when to defer would be economically sound.

Since I’m not, it’s probably more about enjoying the moment and the journey. This colleague of mine especially appreciates this. You know who you are!

Improving flow means fewer bottlenecks, faster feedback, and less wasted capacity. Explore flow advisory or let’s talk.