Just a follow-up thought or two…
This morning I was watching my friend and old Sprint colleague’s David Anderson doing his video blog with Robert Scoble for the Channel9 Microsoft Developer Network.
It reminded me of some of the basic tenets underpinning David’s application of lean manufacturing to software engineering. For those who care, I think David’s work will have a lasting impact on the software industry long after Longhorn/Vista has been forgotten. Watch the video — yes, it’s quite long — and then think: what’s the impact of an order of magnitude increase in average software development productivity on the economy?
My contention is that thinking along similar lines might improve our human ability to manage multiple relationships and messages. You shouldn’t need to have a nervous breakdown when your tribe size exceeds 150 people or when you get 200 mail messages a day. You should never have to declare email bankruptcy and have to start again afresh.
Just like David’s epiphany that if the developer is overworked and stressed, the problem might be the system that assigns work to developers and accepts work from clients, not the lazy developer. If your message inbox is overflowing, you aren’t lazy. You just don’t have the right tools yet.
Thankfully, us hairless chimps are good at fashioning new tools.
The Feature-Driven Development (FDD) methodology agrees with the Theory of Constraints (TOC) by focusing on delivery of client-valued functionality. FDD does it by making the customer-valued feature the atomic unit for planning and tracking software development. Outputs, not inputs, are what are measured. Unlike function points, or lines of code, it isn’t an arbitrary intermediate product. Housekeeping code doesn’t count. TOC focuses on maximising the velocity that client-valued output emerges from a system by paying close attention to bottlenecks within the system. It also eliminates waste — particularly that of excess inventory. TOC also teaches us of the high real costs of “rush orders”, set-up time, and errors.
There’s a good reason I’m telling you all this; our processing of messages is also like an “action factory”. We accept “attention orders” from incoming messages. These have to be correlated, sorted, actioned, followed-up, filed, reviewed and archived. Some of these processes are complex.
Suddenly, it all starts to look familiar. Cars through a Toyota facory. Features through a software factory. Messages through an action factory.
Of course, you need to apply the metaphors where they work and know when to stop.
So what we want is an “agile messaging system”. We want small batch sizes. I should’t be presented with too many messages at once. My “getting things done” system tends to limit my daily to-do list to less than a dozen items.
We want small batch sizes — but not so small as the set-up costs start to outweigh the benefits of processing alike items. I’ve found it very beneficial to use the email subscription service of Bloglines. I forward certain mailing list subscriptions to special Bloglines addresses using a mail delivery script on my server. I can then peruse these as RSS feeds at my leisure. Two dozen emails from Gordon Cook once a week in a single sitting is better than twenty-four interruptions with “you’ve got mail”.
Speaking of which, the new mail flag is a productivity disaster. It flags every arriving attention request as a potential “rush job” that needs urgent attention. Somehow we need to fight against these machines and re-learn how to concentrate on one task for more than 3 minutes. Sometimes at the end of the day my head spins like a concussed cartoon character from attention atomisation.
When you come back from vacation, your inbox shouldn’t say “1273 new messages”. It should be “102 new batches”. It should have grouped and sorted them for you, ready for processing in what it sees as a reasonable order. Yes, you might miss an important one at first — but it can’t be worse than what we have now, can it? Small batches, frequent action.
We want to eliminate all waste. What is waste in email? It’s messages that you aren’t interested in, won’t action, etc. It’s also messages for authorisation of routine business transactions that you click “accept” without even reading. Much of the waste has to be eliminated by fixing the processes outside of the email system. But some of it can be fixed internally. Just apply a bit of filtering and collaborative intelligence to weed them out automatically.
The bottleneck of the system is the working memory of a human. That’s the constraint, the resource we’re trying to protect. The unique ability of a human brain is to perform associative memory actions across large and fuzzy data sets. Everything in a messaging client should be based around those limits. Martin’s getting tired now, I’ll hold that message back for a few minutes. Why not buffer messages out of sight until the right batch size is reached or until my working memory isn’t too tired?
In a way, this is what my RSS reader does. It holds messages back and batches them for me. I can now process a thousand messages a day where I might previously only handled a hundred.
A final parting thought. The theory of constraints introduces the concept of “drum, buffer, rope”. I won’t go into detail of where the terms come from. But part of the route to success is not accepting orders into the factory faster than the bottleneck can process them. A next-generation email system might ever write back to senders “Martin’s busy now — is this mail important”. “Your email wasn’t read while Martin was away, is this message still relevant?”.
Might give people some pause before hitting the send key in the first place.
UPDATE: Oops, forgot my key point. The client valued functionality of email isn’t messages received. That’s an intermediate by-product. There are a number of outcomes — actions, FYIs, social contacts, etc. I send David a cartoon joke about Glaswegians last week; ideally I’d preferred to submit it into a different queue than his email inbox, but I can’t. You build a better messaging tool by creating better outcomes (doh!). The only way of doing this, like with RSS, may be the gradual abandonment of email in favour of domain-specific messaging tools.
UPDATE: Benoit has been thinking along similar lines.
Posted by Martin Geddes at 10:41 PMTrackBack URL for this entry:
http://www.telepocalypse.net/cgi-sys/cgiwrap/mgeddes/MT/mt-tb.cgi/524.