So what is the best way to organise work for an agile team?

I've recently been reading "Algorithms to Live By: The Computer Science of Human Decisions" by Brian Christian and Tom Griffiths.  I've found it interesting and there are some helpful insights we can apply to the challenge of scheduling work for developers and software teams.

In turns out that there is only an optimum scheduling solution 9% of the time.  So, if there is a 91% chance of there not being an optimum schedule for a software project, how do we organise work to maximise the delivery of software teams?

Apparently, scheduling by either earliest due date or lowest effort (least time) are efficient solutions that guarantee (on average) the best possible performance.  This can be improved by using "weighted-effort" instead of raw effort.  

To determine the weighted-effort, divide the importance of the item by the amount of time it will take to complete.  Use the result of this calculation to determine the relative priority of the items in the to-do list.

The to-do list now becomes a metric driven backlog which is easier to reason about and justify to competing stakeholders. 

Assuming these backlog items are defined succinctly and without ambiguity, enabling the development team to be effective, how do we create conditions where they can thrive and be efficient? 

It can helpful to think of developers as single-threaded machines.  Studies by psychologists show that interruptions cause both delays and errors.  These costs of context-switching mean that anyone interrupted more than a few times an hour, can look busy, but is in danger of achieving nothing - the human equivalent of an overloaded operating system.

Applying this theory:

• Customise the team's work tracking system to have a weighted-effort field.
• Create backlog items focussed on client value features rather than technical tasks. 
• Prioritise the items in the backlog using weighted-effort. 
  
• If necessary use revenue as a proxy for importance.
• Wean product managers off 'big bang' releases and onto releasing increments of value.  Where this is not possible, use feature branches, or preferably, feature-switches, to isolate the completed (and unreleased) features from the released product.
• Slice work items into the smallest possible units of testable value, preferably no longer than 3 days (code-review-test).  This maximises the ability to adapt to changing business priorities while minimising context switches.
• Reduce interruptions and context switches by minimising meetings, or cluster them together.  Hold stand up meetings at the very beginning, or very end of the day.   
• Train all team members to proactively keep their items in your team work tracking system up to date.  This removes the need to interrupt people to obtain a status update.
• When in doubt, deliver the smallest, most well defined items with the closest deadlines first. 

It may not be possible to define the perfect project schedule, but we certainly can deliver the best possible performance.