Most time management books have a powerful idea they teach.  The idea of putting your to-do list together and then as something is done, marking though it with a  pen.  Marking though the finished task is the cap to the completed work.  It feels great to complete that task

One of the most powerful aspects of agile development is iterative development.  The idea of taking a large development effort and breaking it into distinct smaller efforts.  Those efforts are then planned, committed to, worked on and completed.  You know the drill.  But it’s not just the coding that’s done, but all the work, including testing, documentation, install packages, whatever it would take to make it usable in its final destination.  It may not be feature complete.  In fact, most iterations won’t release something that is feature complete.  But, the features that are there work as they are expected to.

A large problem with large development efforts (think waterfall) is they take so long between starting and when something is “done”.  That long schedule greatly increases the risk that things will go wrong.  And much worse, you don’t know it went wrong until such time as it is much too late to mitigate the problem.

Johanna Rothman, project management consultant, uses the ides of inch-pebbles.  If you can not estimate to milestones, go to inch-pebbles.  Meaning, take smaller pieces of work until you get to an effort/time combination that you can estimate with a feature set you can commit to.  And then, make it happen.  Get the work done, not just done but “Done”.  If you are still seeing challenges in meeting the commitments, break things up into even smaller chunks with smaller measures of time.

“Done” allows you to see exactly where you are. Many things may appear to tell you where you are in the project including status meetings, reports, hallway discussions and morning scrum meetings.  But there is nothing like having something “Done” that tells you where you are.  You can see what is done, look at what was expected and then make decisions as to future expectations.   I remember an old joke where the comic talks about the typical weather man that says “How’s the weather?, lets go the map”.  The weather man brings up the map and talks about barometric pressure, temperature and dew points.  The comic says, “Go to the map??, Let’s go to the window”.  Many metrics can be helpful, but there is nothing like knowing where the actual product is at that time.  And that is the power of “Done”.  You can see what is done and what is not.

When the terrain and the map to not agree, trust the terrain.  Knowing what is done, is like seeing the terrain.  It is reality.  Scrum meetings, reports, etc are maps.  They have some information, but it could be wrong.  Knowing what is “Done” and what is not is realty.

If is not “Done”, that is not bad, it is information.  If you treat something not “Done” as bad information, you risk alienating the messenger.  In fact, be glad you got the information.  You have something you can use to improve the outcome.  You can regroup, understand what happened and make course corrections for the future.  Without the information, you have nothing to act on.

Don’t just be kind-of-done, or sort-a-done with that task or story.  Be Done!!

Scott Schimanski Esoterica