We considered how stress and self-discipline result in growth and strength, whether that is physical, mental, emotional, or spiritual. However, an important corollary of this is that intervals of rest are needed so that we are able to recover stronger instead of ending up progressively worn down.
From nature and our own experience we can see that this rest needs to happen on several cycles. There is a daily rest (1/3 of our time is spent sleeping), a wise principle of weekly rest (one day out of seven), and a yearly rest (winter, vacations). We could even consider the wisdom of longer cycles of rest (e.g., taking sabbatical every 7 to 11 years as many universities practice for their faculty, and as Intel has done).
These principles apply not only to organic life but also to organizations. While agile principles and techniques do increase team efficiency and productivity, it is a mistake to think that agile’s goal is continuous apparent productivity. There are a number of shatterings of continuous apparent productivity that are necessary to healthy agile product development. It is important to brainstorm, learn, conduct retrospectives, take time to refactor, experiment and evaluate alternatives . . . and also to rest. Paradoxically, all of these ways of taking time to slow down often help to improve your team’s long-term productivity.
Obviously our individual daily, weekly, and annual cycles of rest help with the health of our agile team. But the team itself should also be engaging in rest. There are many possibilities here, including team outings and shared meals, team training, and planning for gap sprints or gap weeks to focus on lighthearted or experimental work (what if I rewrote this in Clojure, Haskell, or Racket). In keeping with the spirit of agile, the team should evaluate its own need for rest and plan appropriate kinds of rest.
Crossposted to I gotta have my orange juice.

The simple case is to deploy your virtual machines onto the logical switch and take advantage of the ESG to access the private and public networks. (Note that the ESG is initially configured with the sample NAT rule disabled, so you will need to enable it.) However, in our case study we want to deploy a virtual machine that will be used as part of the management stack to manage vCenter, ESXi hosts, and deploy workloads into vCenter. As a result, we prefer to have our virtual machine live directly on the private management network, but it will still need access to the public network, for example to download updates. This means we will need both to assign a private IP to the VM, and also to reconfigure the ESG to provide NAT from the private network to the public network.




Today IBM Cloud made generally available VMware Hybrid Cloud Extension for our VMware vCenter Server and VMware Cloud Foundation instances! I’m excited about this development: it is the culmination of lots of work and collaboration on the part of IBM and VMware, and it brings powerful network extension (what VMware calls hybridity) and workload migration (what VMware calls mobility) capabilities to your VMware instances in the IBM cloud.