Follow The Sun is the management concept that by spreading your development team across the world you always have someone who is awake and can work on a problem. In the imagined perfect world Team A works on a problem for their eight hour day and then hands off the partially developed feature to the next team arriving on the next continent. The idea is based on the notion that developers and software are both fungible assets. (Fungibility is the property of a good or a commodity whose individual units are capable of mutual substitution. Examples of highly fungible commodities are crude oil, wheat, orange juice, precious metals, and currencies. Wikipedia)
Since developer A is equivalent to developer B it just make sense for them to hand off bits of partially developed code to one another. (sic)
In the real world this often becomes Chase The Sun rather than Follow The Sun. There are two variations of Chase the Sun.
In the first variation all developers are basically expected to be available for questions and support 24 hours a day. Between Skype and text messages and laptops or smart phones we often see developers basically in perpetual on-call mode. This can actually be effective...until the team burns out.
In the other variation team A makes a change that breaks the system or changes it significantly, and then goes to bed. Team B comes to work to find a broken or "different' system and spends their day doing archeology on team A's changes. Successful or not they try to warn Team C about the state of the system and the changes that they've made in an attempt to resolve the issue.
Each team leaves emails that will be read 18 hours later by the team prior to them in the earth's rotation. Besides being inefficient this variation leads to predictably negative team interactions. Its just too easy to explain each day's problems as being caused by "them".
Chase the Sun can be changed back into Follow The Sun by following a few simple rules
a) developers are not fungible
b) there is enough code that the code also isn't fungible, so not everyone will understand everything
c) geographically dispersed teams can assist each other investigations or in remote pair programming where one team develops and the other tests
d) asking geographically dispersed teams to work on the same code or features is often a recipe for disaster
No comments:
Post a Comment