Spence Green

The key to efficient programmer tasking involves telling programmers exactly what to do and then allowing them the space to do it. Practically, this means providing them with specific development tasks in a sequential order. If the project’s tasking model can achieve these mischievously difficult conditions, then programmers can enter the ‘Flow’, which is impossible with heavy context-switching.

Below, I describe the task model used in my team’s software process. An iterative software project has three task types:

• Non-technical: Any task not associated with code. Includes most work completed during the Preparation phase. Design schematics, system-level use cases, and whitepapers are all non-technical tasks.
• Implementation Request (IR): Directly associated with both a Level2 software requirement and the code that implements the requirement.
• Change Request (CR): Directly associated with a change to an existing requirement and the code that implements that change.

An effective tasking model has several key requirements:

• Unambiguously answers “What”: The task data object should include a title, detailed work instructions, and links to relevant documentation.
• Enables Easy Estimate Tracking: An engineer must be able to enter labor estimates AND evaluate his performance.
• Associates Tasks with Exit Criteria: Each task should be associated with a reviewable work product.

Finally, each engineer should have a personalized view of his work assignments that is not cluttered by unrelated tasks. He can immediately determine not only the current day’s objective, but also his future workload.

Organization
All tasks should appear in centralized container that is collectively owned, ie all programmers have write permissions to it. Most web-based project management tools (FogBugz, Basecamp) and enterprise portal platforms (OpenText Livelink, Microsoft Sharepoint) can satisfy this requirement. Tasks are organized in the “To do List” using the following abstractions:

• Tasks: Each of which is associated with a task group.
• Task Groups: A collection of tasks associated with a milestone.
• Milestones: Date upon which a specific business objective must be accomplished. A milestone frequently coincides with a Work Product Inspection (WPI).

If your project management tool is integrated with both your requirements management system and you change management (CM) tool, then you can use the same organizer for IRs and CRs. Otherwise, you must create a separate tasking model in your CM package.

What to Do Next
Programmers should receive an email notification after a task is assigned to them. They must then provide estimates:

• Set due dates for each milestones.
• Set due dates and durations for each of your tasks relative to the associated milestones.
• Add any missing tasks
• Provide work estimates.

IMPORTANT: Programmers should not change task due dates if they encounter a delay! The tasking activity has little benefit unless programmers improve their personal estimation skills. When an engineer changes a task status to ‘Completed’, the task manager will record the differential between the estimated ‘Due Date’ and the ‘Completed Date’. Programmers should challenge themselves to minimize this interval.

A Daily Regime…
Programmers start their days with the following process:

• Review current task assignments.
• Set a task’s status to ‘In Process’ when starting work; change the status to ‘Completed’ after finishing the task.
• Add new tasks as necessary.
• Arrive at the morning ‘Stand-up’ meeting aware of not only your current work assignments, but also the team’s current location in the project trajectory.

IMPORTANT: The task list has no purpose unless it actually reflects what the programmers are doing during the day. THEY are the source of project status, for management without data is nothing more than sorcery. Good estimates build credibility, which the team should gather rapaciously.