...copyright Elena Yatzeck, 2010-2017

Friday, March 28, 2014

PowerPoint for Those Who Must Use It

There's a lot out there about how to use MS-PowerPoint, starting with Edward Tufte's advice to NEVER NEVER use it

An example from Edward Tufte of what you should do graphically, instead of using PowerPoint.  http://www.edwardtufte.com/tufte/minard
But I cannot resist this chance to throw my hat into the ring.  What if you are not a graphic designer, and someone asks you to build a PowerPoint deck, and the thing they need to know about is not Napoleon's invasion of Russia?

I am a person who prefers to put as little effort into this as possible, so you will not get any cool design tips from me.  But to me, a very pragmatic and plodding user of the PowerPoint technology, the handiest thing is just to have a good example to follow, and guess at the rest.  So you can skip the rest of the blog and just look at this handy sample if you like!  That's what I would do.

If for some reason you are still reading, then in my opinion, the following are the most important points to keep in mind. (And most of the following apply to the Apple equivalent too, Keynote, despite its lovely, clean layout designs).

1)  Is it a live presentation, or is it a leave-behind, or is it both? 
  • Best practice for a live presentation is to 
    • Keep the slides very simple (25 words per slide, maximum, use a lot of images).  
    • Keep your main presentation as short as possible (20 slides per hour is a good starting point).
    • If you need more visual content available, in case questions arise when you present your deck, create an "appendix" section at the end of the deck with additional information you can show as needed.
  • Best practice for a leave-behind requires a lot more content, since there isn't a person talking to supplement the visual material.  If you promise never to present the deck live, write it any way you want, with as many words as you want.  You're essentially using PowerPoint where perhaps you should be using Word.
  • If you want to present live, but you want to end up with a leave-behind that can stand on its own, then the solution is:  
    • For live presentation purposes, keep the main body of the deck short, and keep the slides very clean.  You want to prioritize the comfort of your live audience over that of your later readers, because the live ones can and do fall asleep while you are talking, and that will make you feel bad.  Future private sleeping in the privacy of the reader's cube does not have the same visceral effect on the speaker.
    • For re-use of the same deck as "leave behind" material, paper or electronic, create and distribute a PDF which includes the "notes" section at the bottom of each slide, and put everything that needs to be said to interpret the slide in the notes section, along with hyperlinks to important available online content elsewhere.  
    • Important:  if you will be using physical handouts, you should spell out all referenced urls on the slide or in the notes, not use just hyperlinks, because you can't click on a piece of paper.  Or if you do, all you will get is a faint stain from the Cheetos you had at lunch.
    • There are several schools of thought about whether to have printed handouts that you distribute BEFORE or DURING a live presentation.  For maximum "surprise," don't distribute ahead of time.  For minimum "surprise," distribute.  My only recommendation here is that you do not include the notes in handouts you give to people to use while they are watching you present it live.  The version with notes is definitely for after the fact.
2)  Standard "Tellum" rule (tellem what you're going to tellem, tellem, then tellem what you toldem): 
  • Start with an agenda page as your first slide after the title slide, and visually bring back the agenda for each major point of the talk, and indicate on that agenda slide where you are now.  It reassures people that the talk will be over at some point. 
  • One nice "breadcrumb" technique to use is to create a long horizontal rectangle of some color, a little bit wider than the width of the agenda bullet points, and as tall as needed to fully cover whatever section of words it is highlighting (this will vary per bullet).  Set its properties to 50% or more transparent.  
    • The first time you show the agenda, it should be without the rectangle.  
    • Then, at each point where you are returning to the agenda to show progress, overlay the rectangle over the area of the talk you are now in.  It will gradually move down the page. 
  • Pro tip--build just one copy of the agenda slide as you compose your deck.  
    • When you are ready to "publish," copy that slide, add the rectangle over the first point you will cover, and then copy the slide plus rectangle for each section you need to highlight at some point in the talk.  
    • To make it beautiful, use the arrows to move it up and down, not the mouse, because you don't want horizontal wobble.  Keep all of your agenda slides together and build them at once.
    • Then move those other copies of the agenda slide, with the rectangle properly positioned, to the right point in your deck.  Otherwise you will be constantly changing the agenda points on multiple slides, every time you change your mind about what the structure of your talk is going to be.
3)  Use consistent capitalization and punctuation.
  • One rule of thumb is to Capitalize The Words for the actual title of the presentation, and for each slide, but Only capitalize the first word of all bullets and sentences in the actual slide content.  
  • And either use punctuation at the end of bullets, or don't.  You can drive people very crazy by interspersing commas, periods, and the occasional nothing
4)  Just choose a simple built-in theme and stick with it at first.  If you don't try to get fancy, you won't go too wrong.  Do not get caught up in drama over which type of slide to use.  
  • Complex is not good in the theme, and the built-in ones are generally well behaved.  If your executive or some communications authority unskilled at powerpoint has already "customized" a template for himself/itself, that can be a drag.
  • Usually, a powerpoint theme has a "title page," a "section page," and a set of "page pages" that have some combinations of header and content.  I typically prefer to use one title page at the front, and then all page-pages, because I prefer to use an agenda page with a moving bar to a "section" page.
  • Common page templates to use--blank, header plus blank, header plus content, header plus two columns of content.  For uniformity, do not move the "content" area(s) around or resize it (them).
5)  Executive pro tips. 
  • Each content slide should have a title at the top, a main take-away point in smaller print beneath the title as the top line, and then some other content.
  • Use a discreet page number in the bottom corner of the slides.
  • If you are presenting with physical hand-outs to a group of executives, print the slides out in color, one-sided, unstapled.  Paperclips are okay.
6)  About animation.  Generally, I am in favor of animation, used prudently, because it's entertaining.  But the problem with it is if you aren't expecting it, you may bring up your partially blank slide in front of an audience and freak out, forgetting that you have to click again to get the fly-in.  
  • So if you are giving the presentation live, or if you are writing it for someone else, make sure everyone is on board about the animation.  
  • Also, if this is a deck you plan to use as a leave-behind, do not do "layered" animation where the printed version of the slide only shows the slide as it appears before everything has flown in and out. 
  • Note that animating is fun and addictive.  Do not be lured into something you will regret.
7)  When you get to be a communications director, you will want to invest a few hundred dollars to have a powerpoint designer create a template which is well behaved and has proper colors and branding on it.
  • A well-behaved template has a standard color and theme, and does things like handle bullets uniformly.  
  • I have worked with a lot of corporate templates that had the color, theme, and font perfect, but which were horrible when it came to bullets.  There's a technical side to a good powerpoint theme--make sure someone handles that after the designers are done.
 A "power" powerpoint user might get into creating templates, applying layouts, etc., but if the whole point from the get-go is to create a simple presentation with useful add-ons in the notes or somewhere on the web, you don't need very much of that stuff.

If any of this resonates, feel free to steal my handy reusable powerpoint deck, and alter it at will.  To get the full effect you will want to download it and print it out with notes.  And now go out and make 'em, well, not doze! 

Wednesday, February 19, 2014

Return of the Matrix: The Organization Around the Self Organization

Do you have a group of, say, 100 people, whom you want to organize optimally for a software delivery program?  Martin Fowler is famously on record saying that "scaling agile is the last thing you should do."
A better approach is to try to scale down your project. ...an unscientific straw poll revealed that most projects could lose about half the people of the project without making things go slower. Time and time again I hear of success occurring when a team is cut significantly in size. Large teams carry a big overhead in communication and management. Using smaller teams staffed with more able people is usually faster and cheaper, even if the everyone is more individually expensive.
This brings to mind one of Tom Waite's "non-lethal weapons," the Shrink Ray, in the movie Mystery Men,.  Aficionados of the movie (or comic) will remember that the ray is "based on simple dry-cleaning technology."
From the Blu-ray site:  http://www.blu-ray.com/movies/Mystery-Men-Blu-ray/42756/
You are left with the (perhaps not completely false) impression that in reality, you should do a completely different project, (a more interesting one), and lay everyone off (and hire Martin Fowler peers). 

Perhaps you don't have that option.  It can happen.  Moreover, if you're pragmatic, you want to keep everyone in your current work force around to figure out how they will fit into future teams, rather than starting with a clean slate (and zero subject matter expertise about the specifics of your operation).  Some people may choose to leave, and you may eventually find responsibilities shifting dramatically, leading to other staff reorganization and reduction, but you should let that happen later.  Don't start there

So if starting over from scratch isn't your first and best option, here are some questions you should ask, and some options which will vary based on the answers to those questions.

You really should read this article!  http://www.unspecial.org/UNS649/t37.html
Things you already know, but may be questioning, now that you're "going agile:"
  • You still need a line management structure of some kind, yes, seriously, you do.
    • Even before you consider organizing people for delivery, you need to consider organizing them into some kind of reporting structure which allows you, as the employer, to support them and ensure their overall well-being.  
    • The line management structure does not need to be the same as the delivery structure.  In fact, it may be better if the structure is different.
    • After witnessing many bizarre varients of "flat" or "wire-archy" structures, I have come to believe strongly that you are best off with an old-fashioned "matrix" where people with like skill sets report into a line manager who stays in touch with them regardless of what delivery team they are working on.
    • So if you are a company of 100, and you are wondering how to organize your whole set of employees in an agile way, then you should figure out what your line management structure will look like (shallow or deep), and subtract people who do line management tasks from delivery.  I suppose this point is controversial, but all I am saying is that if you leave "line management" tasks to take care of themselves, you are conceding to a seemingly random system of hiring, annual review, and other work allocation negotiations where politics will take over.  Your team will never survive the ensuing chaos.
  • You need a delivery structure of some kind. 
    • The remainder of your 100 people are going to have to be divided up into:
      • Some team groupings, "teams," "pods," "work streams," or whatever you decide to call them locally.
      • Some leadership positions.  You cannot self-organize a program of 100.  You will need servant leaders to think about coordination and the big picture.  Examples:  program manager, software lead or architect, lead quality person, overall product owner.
    • You will need people with the appropriate skill sets:  some leaders, some people who can develop, people who can wrangle stakeholders until coherent requirements emerge, people who can design tests (and the data to drive the tests) which will allow the team to detect whether the software continues to work as it is developed.
Some rules of thumb to start with for agile delivery teams--some "patterns," if you will:
  • Teams larger than 15 grow unwieldy.  10 is a good number, and 6-8 is better even than that.
  • A single servant leader (program manager, software lead, lead quality person, lead product owner) will have trouble with creating vision and facilitating the work of more than 10 teams.  Create a scaling structure where no manager needs to provide servant leadership to more than 6 people at a time.
  • A grouping ratio that often works is 1 analyst: 2 pairs of developers: 1 tester.  
  • Putting it all together, a starting assumption about the 100-person delivery organization might be:
    • 1 Program Manager + staff as needed to handle
      • External reporting/compliance
      • Scrum of scums team coordination
    • 1 Lead Developer/Architect + staff as needed to handle
      • Solution tech stack architecture visioning and hands-on evolution
      • Delivery tech stack architecture visioning and hands-on evolution
      • Librarians/curators to keep things tidy without becoming a bottleneck (refactor to remove duplication, rather than creating one "shared tools" team that everyone has to depend on.
    • 1 Lead Tester + staff as needed to handle
      • Solution automated test architecture (functional + non functional) visioning and hands-on evolution
      • Delivery data and test harness architecture visioning and hands-on evolution
    • 1 Product Owner + staff as needed to handle
      • Consensus building in the business hierarchy
      • Business architecture visioning and hands-on evolution
      • SME identification and outreach
    • Other extended team members (DBA, Security, Trainers, etc.)
    • Remainder allocated to teams of 6-14 people:
      • Scrum Master/Iteration Manager
      • Product Owner
      • 1-2 Analysts
      • 2-8 Devs
      • 1-2 Testers
And finally, some basic questions to consider when you design your staffing plan:
  1. How do we allocate our current workers to teams while moving towards teams of "T-shaped" individuals who can do more than one job?  In final state, in a large enterprise, you are likely to have people who CAN do anything, but who may PREFER to do one kind of work more than another.  So don't worry too much if, at first, your testers specialize in "how to test" but don't automate, or your developers specialize in development plus test automation, but don't know how to do analysis or rigorous test scenario development.  Allow people to grow, but take advantage of their current skills and interests.
  2. Are we staffing tactically or strategically?  If you have a diverse set of technologies, or over-specialization in your current workers ("I only do the UI."), you may choose to staff to people's current strengths ("all Pega work goes to team A"), or you may want to distribute people with specialized skill sets across multiple teams, to make each team more flexible and content-agnostic.  In general, the more you stretch people towards being able to handle complete stories from UI to DB and back, the slower things will be at first, but the better off you will be in the 6-12 month time frame.
  3. How do we design a set of parallel efforts that can be internally cohesive and loosely coupled with each other?  See Mike Cottmeyer's excellent post on this point.  Concretely, this means if you are building a workflow, you may want to cluster functionality in "stages along the workflow" to allow each team to build the full stack of one closely-related set of functions, and reduce the interdependence between teams to small APIs which can be virtualized by the first side to be done, until the second side gets to it.  You may NOT want to set things up so that "all common things" are owned by a single agile team, since that team will become a bottleneck to everyone.  Instead, think about a design curator/librarian to keep things clean, while allowing parallel efforts to proceed unfettered.
  4. Do we already have an automated continuous delivery pipeline which accommodates automated functional regression testing plus manual exploratory testing as needed?  If not, you will need many more people and probably a different schedule, in order to avoid killing the teams under the load of functional regression testing.
  5. How diverse is the technical stack?  If you have many different platforms, each set up differently, with, perhaps, a few vendor packages in the mix, then your staffing will be more rigid, because you will need people who are expert on each of those platforms, and hardly anyone can be expert on all of them.

    Thursday, February 13, 2014

    Patterns for Agile Transformation Success: Agile Enterprise Adoption Without a Gut Rehab

    Mike Cottmeyer has re-emerged in the blogosphere, after a bit of a lull, with an electrifying series of posts about enterprise agile, one of which is entitled How to Structure Your Agile Enterprise.  I love the whole series, and especially this post, anchored as it is in Cottmeyer's real life experience:
    First of all… let me share that I have NEVER worked on a small agile team. I’ve coached many of them, but my introduction to agile was in the context of large enterprise class financial systems… things like online banking and bill payment. The kinds of systems where the company makes a penny or two on every transaction and does millions every year.
    Is this your enterprise business flow reality??  From http://thedailywtf.com/Articles/The_Customer-Friendly_System.aspx
    Cottmeyer provides some really crucial insights about agile at scale that may run counter to what you believe is "fundamental" to agile:
    • "Feature teams" are not practical, if any given feature involves a workflow where data passes through many different application silos, end to end.
    • In contrast, "Governance Teams" and "Product Owner Teams" are needed at scale, not just a single scrum master working with a single product owner who knows everything about every system, and a single self-governing team. 
    In fact, Cottmeyer says, what is practical is a delivery team structure analogous to SOA systems architecture, where "services [are] loosely coupled and highly cohesive. When building Scrum teams, we want each team to be loosely coupled and highly cohesive… just not necessarily responsible for an end-to-end slice of the entire product."
    A wonderful diagram from http://www.planetgeek.ch/2011/07/08/presentation-agile-code-design-how-to-keep-your-code-flexible/ -- applies both to code and to agile delivery team structure!

    A question which may come to your mind as you read this, however, especially if you don't have Cottmeyer's organization currently coaching you, is "how do I get there from here?"  How feasible is it to morph from your current executive and vendor management strategy, from your current HR strategy, from your current policies about software delivery, from your current location strategy, from your current staff, and so on, to your optimal organizational end state?
    From http://ethicsalarms.files.wordpress.com/2011/05/you-cant-get-there-from-here.png

    The good news is that as an organization which is already making money through some kind of strategy and tactics, you are very likely to be set up very well for these changes already, and without having to throw away all your binders of regulations and policies (or requirements, if you were worried about that).  And, in fact, by leveraging your corporate goals, and using agile techniques to steer your strategy and tactics better to align with those goals, an agile adoption is likely to be the fastest way to make the most of your strong points.

    From http://www.incredibleart.org/lessons/middle/tessell.htm
    Let's start to talk about patterns of what is feasible, because, as Cottmeyer says, there are techniques and tools that work that can be described architecturally without descending into a coaching process that micromanages everything about a team's day to day operation.  And, just as Cottmeyer does, let's borrow from the now-standard concept of architectural design patterns to talk about things we may want to establish in some locally appropriate way with the business architecture which surrounds our software delivery.  Here are some ideas I've thought about already, some that I've blogged about already and some that I will build out in the coming weeks. 

    Creational patterns
    Structural patterns
    Behavioral patterns
    Concurrency patterns
    The secret to agile transformation is that your enterprise already has patterns in place which promote the values of the manifesto:  working software, valuing people, keeping up with the market.  Further transformation can be aided by a coach that can help you reflect on what will get you closer to your corporate goals, and that you act on your findings.  Use what you're good at, and fix the rest as you go, based on the ROI of further investment in change.  And please let me know if you've seen other patterns that have worked--I would love to hear your ideas as well! 

    Friday, January 31, 2014

    Battle Plans for the Self Disorganized

    As agilists, we all hear a lot about self-organizing teams.  I'm pretty sure I have already aired several, probably conflicting, opinions about self-organizing teams, like "someone else should assign people to the teams and decide what they should do, and THEN they should self-organize," but today I would like to talk about something even more fundamental:  the self-organizing self.  Are you fully able to function on your own behalf, or even on the team's behalf, at times when you don't have a scrum master acting as a sort of personal time assistant?  Do you procrastinate?  Are you distracted?  Do you run out of money?  Do you lose things?  Let's assume you've tackled work--how well-armed are you for life?

    Helpful advice from http://xkcd.com/337/
    I would like to think that most of you are more personally organized than I am, and you probably are, but for those of you who need a little help, as I do, there are some free or cheap techniques and online tools that can help arm you for the struggles of day to day life.  These have worked for me--perhaps some of these will help you as well.  Today's tips focus in four areas to organize:  things, tasks, time, and money.  If none of these are areas of personal challenge for you, then move along, there's nothing for you here!  Otherwise, here we go.  Let's start simple, to avoid frightening ourselves:

    Don't lose things.  Sure, it sounds basic, and yet how many things have you lost this month?  My advice is that you just keep everything in your purse, man bag, laptop bag, backpack, briefcase, or, if you have somehow managed to miss the memo, "fanny pack."  If it is not important enough to keep in your purse, then you can do whatever you want, but don't come running to me if you can't find it in an emergency.  Most things that won't fit in your purse are harder to lose, in any event.
    From http://www.examiner.com/article/international-fanny-pack-day.  Isn't that a horrifying concept?
    Pro usage tips:
    1. Never, ever, keep something "in your hand."  If you notice something in your hand, put it back in your purse.
    2. When you use something, make sure it is actually "in use," "being charged," or back in your purse.  You can charge things located in your purse if you don't mind the cords dangling out of there.
    3. Do not charge gadgets on the floor, because you might step on them.
    Tasks.  I have heard many folksy anecdotes about people who use a card wall for tracking their family chores at home.  Good for them.  For many of us disorganized people, the problem isn't "delivery."  The problem is "keeping track of the backlog."  Or in layman's terms, "having an un-lose-able list of things to do."  You could do this by having a piece of paper you keep in your purse.  And a pen.  But if the challenge level of keeping a pen handy has already caused you to break out in a sweat, I recommend you get "personal productivity software."  There are a bunch of these out there, but I personally recommend Toodledo, which as this reviewer says, is: "Too robust to be called a simple to-do list, ...not quite powerful enough to be called a project management tool. Despite the lack of a handy category to slot them into, this is a nifty tool for anyone with a complicated life."  The basic idea is that you put stuff on the list when you remember you have to do it, check the list on some regular cadence, and check things off when they are complete.  It's pretty neat!  You might like it.  Here's a screen shot of the web application:

    Pro usage tips:
    1. There's an app for that.  You can get apps for iphone and Android for toodledo, which means that every time it occurs to you that there's something you need to do, you can jot it down immediately, using whatever gadget you have handy.  Do that.
    2. Avoid nagging.  You can give your partner, spouse, or other loved one your login and password to the free version, and get them to put things directly on your toodledo list instead of nagging you.  Or you can pay for the official multi-user upgrade, if you need more privacy.
    3. Toodledo is Covey-highly-effective-person-friendly.  Once you have a way to keep the list and not lose it, you can try advanced practices like "figure out what is important and plan that first."  If you need to do some heavy duty life planning, you will want to use the web interface, though, not the app. 
    Time.  There are many people out there making tons of money on this topic, and you can go out and buy their books if you want.  But if your issue is just being distracted and getting to the end of the day without anything to show for it except a new high score in Candy Crush, you may want to bring in the heavy weaponry:  the Pomodoro Technique.

    A branded kitchen timer
    Pomodoro was invented by a graduate student who actually wanted to finish his dissertation and to move into the paying work force.  Some graduate students do want to leave school eventually!  The Pomodoro inventor used a a piece of paper, a pen, and a red kitchen timer shaped like a tomato (hence the name--"Pomodoro" is Italian for "tomato").  If you do not have a red kitchen timer handy (or a piece of paper and a pen), then you can use an application on your laptop or smartphone to simulate these objects.  My choice of tool is an Apple-centric product called Vitamin-R.  I'm not sure what the smartphone or not-Apple-computer equivalents are, sorry.

    In essence, at the start of the day (or the night before), you take your list of things to do (like, from toodledo...), figure out which ones are realistic to do today (or tomorrow), and slot them into 25 minute segments called "Pomodoros."  Typically, your day will be set up in sets of Pomodoros, interrupted by scheduled breaks.  To avoid frightening yourself, you don't call this a schedule.  You call it an "unschedule."  I swear, I didn't make this up.
    From fan site http://www.michaelsliwinski.com/power-of-unschedule-and-pomodoro-technique/
    Classically, you agree to work without stopping for 25 minutes, then take a 5 minute break.  Then you do another 25 minutes and another 5 minute break.  After you do four of these, you take a nice long break, like a coffee break or a meal break.  And you make sure to take those short breaks, as well.  Unless you allocate an entire Pomodoro to "reading email," you will need to fit your emailing, tweeting, facebooking, etc., into the break time.  You will be amazed how much you can get done when you make a promise to yourself to focus for just 25 minutes at a time.  So your day might be:
    • 2 hours of Pomodoros (4 Pomodoros)
    • 30 minute break
    • 2 hours of Pomodoros (4 Pomodoros)
    • 1 hour break (for lunch)
    • 2 hours of Pomodoros (another 4)
    • 30 minute break
    • 2 more hours of Pomodoros (final 4).
    The rules are "do nothing but work during a Pomodoro" and "do NO WORK when you are NOT in a Pomodoro."  You can see in the above schedule, you get 7.75 hours of productive work, which may even be more than you get today with your lassaiz-faire "I think I'll just play some foosball with the guys and work until midnight" methodology.

    Pro usage tips:
    1. Don't freak yourself out or overthink this. You can plan the whole rest of your life once you've gotten the basics under your belt.  Just do this one Pomodoro at a time, one day at a time.
    2. If you are using Pomodoros to schedule your personal time as well as your work time, you will likely schedule a couple of Pomodoros at the beginning and/or end of the day.
    Manage your money.  I am sure this doesn't happen to you, and of course not to me, either, but just in case, let me say speculatively that I bet it is really inconvenient to just up and run out of money unexpectedly.  Don't let this happen to you.  I'm not sure what the whole market out there is for this type of tool, and I'm not sure whether these are available outside the US, but for what it's worth, I use two cash flow related tools:   mint.com and YNAB ("You Need a Budget.")  
    mint.com shows you when you have run out of money
    Both applications can be used from a laptop, and both have iPhone and Android apps to access the same basic data, as well.  Mint.com lives in the cloud, and easily hooks up to almost any US financial institution and provides handy alerts like "just dipped below zero" when that happens in real time.  For a tiny bit more control, you can use YNAB to actually plan where you will spend your currently available dollars.

    YNAB action shot, laptop interface
    YNAB is different from other tools you may have used, like Quicken, Microsoft Money, or even mint.com, in the sense that it asks you to just focus on what cash you have, and how you plan to spend it.  It does not let you get pulled into an endless categorization of last year's data.  That's nice.

    Pro usage tips:
    1. mint.com has a budgeting tool, but it is cumbersome, and you will get lost in there and never come out.  Just use mint.com to tell you whether something terrible has just happened or not.
    2. YNAB lets you just focus on what cash you have on hand, and what you plan to spend it on.  You can gradually move into planning one or even two months ahead, but you don't have to.
    So there you have it!  Things, Tasks, Time, and Money.  All under control.  Isn't that fantastic?  And if you like, you can extend this winning streak by looking into house cleaning and organization with the Flylady, who is completely adorable, and will help you get your home in order, starting with the kitchen sink.  She is awesome.

    So by now, some of you may be saying, "seriously!?"or the like.  I had hoped you people would go away earlier.  For the rest of us, let me just say, yes, I understand!  No matter how hard your work is, it may be a picnic compared to the complications of modern life.  Before you start organizing your self-organizing team, take a few minutes to organize your self.