In the long term the team needs to be able to deliver month in, month out, potentially for years. Natural changes over years mean you can expect technologies and people to change. To cater for technology changes it’s important that software is robust. Ways to manage this include thorough and regular testing (automated wherever possible, because that time will stack up over the months) and well-managed technical debt. To cater for people changes genuine and demonstrable knowledge sharing is critical. One of my favourite approaches is pair programming, but it’s not the only one. Ensuring developers rote roles or attendance at regular meetings is also highly valuable.
In the medium term the team needs to be able to deliver iteration to iteration, and move from one project to another smoothly. Here it’s helpful to ensure a steady supply of working features is produced each iteration; without this there is a poor feedback loop to ensure lessons are learned for the next iteration. It’s also important to ensure team members are treated as human beings with outside lives, and their working environment accommodates those external needs. This minimises people having to choose between work and personal life. Generosity one way is also usually reciprocated—people will tend to give more to their work overall, and be more attracted to work there.
In the short term the team needs to be able to deliver day after day. So late night sessions are to be avoided to ensure people are fresh every day. Unit tests are critical, to reduce the chances of unfathomable bugs which derail expectations. An entirely reliable working environment also ensures predictable delivery. This means the right versions of the right software in all the right environments, configured correctly, and always reproducible in the event of a hardware failure or the requirement for a duplicate.
All these thing require investment—sometimes up-front, sometimes on-going. The pay-off is for the long term. Without these things delivery will never be reliable.