Some quality developer time

My previous 3 weeks has re-installed the feeling that building computer applications is a great thing to do.  Some quick reminders for myself:

• Know what the current tasks are and where they fit in the bigger project task list
• Make sure the rest of the team do to
• Plan to build useful tools which will help the robustness of the code and help automate testing scenario's.  Plan how the tools might be used after the product is complete.  Ensure that the tools have limited scope and that development on them is closed off when they serve their purpose.
• Know what schedule you are on
• Whiteboard regularly and visibly
• Acknowledge success
• Know what is hard (and be honest about it).  Hard stuff should be paired!

As developer lead I like to place reminders in Outlook at 2-3 day periods to jot my memory that I should be keeping the project jumping.  Reminders such as: “When did we last whiteboard a problem“, “When did I last see a working feature“, “Where are we compared to estimate” and “What are the next steps” are useful.

Another method which has worked well for me is to get developers to break their day down into 3 clearly defined segments:

• 1.5 hours Planning: You can plan individually and as a team.  You should plan what you will be developing and you should develop a plan for testing it to.  Use this time to talk as a team and to share ideas about the plan and areas of concern.
• 3.5 hours Developing: This time should be spent coding the tasks which were set out during the planning session.  There should be little need to interrupt other team members in this time.  Head down!
• 1.5 hours Testing: Use this time to study your code and to unit test sections of it.  Scan comments and variable names to ensure that the code is self-describing.

Repeat these steps for each day of the week.  On Monday the planning session should define a set of component or application tests which will be performed publicly to demonstrate progress.  The demonstration should be the last thing for the week and is a time which can be used to field questions which tie the product back to the requirements and architecture documents.  It is also a time that is useful for the team to see the product taking shape and to acknowledge progress.  The developer lead should use this time to re-assess where things are at compared with the estimates in the technical documents.