My solution is the humble Moleskine Weekly Notebook (below).  As the name suggests the weekly notebook is a cunning combination of weekly diary (on the left page) and notebook (on the right page).  This allows me to write my to-do list for the week on the notebook page and record what I do each day on the appropriate section of the diary page.

Having my work log and to-do list in the same physical entity has been a real break-through for me as it means I can track my progress towards my objectives and be able to account for where my time is spent each day.  This has allowed me to analyse my working patterns and evaluate what is taking up time that could be better spent working on the tasks in my to-do list.  Being able to record unexpected events that have taken up time e.g. build breaks or sickness has also proven very useful.

What I don’t use this notebook for is an actual appointment diary or strategic to-do list as I have found through experimentation that there is seldom sufficient space for such things.  I have Microsoft Outlook which does appointment and calendar management and Evernote which does high level strategic tasks lists and note gathering.

This balance can be seen in most projects involving more than a couple of participants.  A team’s experience distribution can typically be visualised as a pyramid with the most experienced individuals at the top of the pyramid and the most numerous and least experienced group of individuals at the bottom.  There is the occasional team where the experience pyramid is inverted but I have yet to have the opportunity to work with such a group.

The experience composition of a typical team usually works quite well, with the more experienced members directing those that are less experienced than them.  This helps to explain why the more experienced you become the more time you seem to spend in meetings planning, discussing and thinking about the design of the product.

The breakdown of the project tasks based on individual experience levels also means that each individual should be supplied with tasks that are mostly within their capabilities.  Some stretch tasks should also be set (with sufficient support from more experienced team members) to ensure each individual continues to develop their skills.  This should mean that the tasks you work on should be within your capabilities and as your capabilities increase so should the complexity of the tasks you are set, to prevent stagnation.

It should be noted that if an individual fails at a task then their next task should be something that is well within their capabilities. To do otherwise is to risk a loss of confidence, as multiple failures in a row can seriously undermine an individual’s confidence and ability (see negative reinforcement).  This is why most modern coaches will not allow their athletes to finish a training session with a failure.

Tasks that stretch or challenge you as an individual are a good thing but they should not be forced upon you and they should not be chained together, some respite is required between challenges.  More experienced team members are an essential resource to those undertaking stretch tasks due to the advice and moral support they can offer.

I think a lot of this underestimation of task length comes down to engineers not having an idea of what being done looks like for the task they are attempting.  Here is some guidelines I use, note that implementation does not take up a lot of space: the list is mostly focused on what is required before and after implementation.  These guidelines are not perfect and I sometimes forget or skip some points depending on the scale of the task:

• Design
  • Is the User Story (or requirements) accurate?
  • Has a brief design been created in some form e.g. notebook, whiteboard or electronically with at least:
    • The User story (or requirements), a sentence or two.
    • Solution summary, a paragraph or two.
    • A sketch of the solution.
    • Technical notes, if required.
  • Has the design been peer reviewed, remember its cheapest to fix bugs at the requirements and design phase.
• Planning
  • Initial task estimation.
  • Break the task down into sub-tasks (if required).
  • Estimate duration for each sub-task.
  • Scheduling.
• Implementation
  • Have all the sub tasks or features been completed.
  • Has any duplication that has been generated been refactored?
• Testing
  • Have unit tests been added or updated for the new feature.
  • Has the executing program code been walked through in a debugger?
  • Has the end user reviewed the finished feature?
• Review
  • Has every file that is about to be checked in been compared to its previous version with a difference tool to confirm the changes to the file are the changes that are required.
  • Has the code been code reviewed by a peer.
  • Has the code been analysed with:
    • Static analysis tools e.g, PC Lint for C++.
    • Dynamic program analysis tools e.g, Code Profiling.
• Check in
  • Remove any unchanged files from the change list.
  • Remove any temporary hacks from the change list e.g, for configuration or testing purposes.
  • Check that all files that need to be added/removed from source control are included.
  • If possible confirm the code builds on a separate test computer before checking in, to make sure no files are missing.

I’m still pondering ‘What done looks like’ so I’ll probably revisit and revise this list at some point in the future, as I’d really like to develop a simple check list I can use to educate more junior engineers.