IT systems have many parts. Each needs to be upgraded or patched. The old way to handle this is to align all the individual release schedules so that you can make a "big release" that gets tested as a unit, and released as unit. You can do this when things change at a sane rate.
Now more things are changing and the rate is much faster. We also have less control. Operating systems have frequent patches. There are urgent security patches that need to roll out "immediately". Applications have frequent updates, many even upgrade themselves. Our PCs have firmware updates for the BIOS, the keyboard, the IPMI controller, the mouse (yes, my damn mouse needed a flash update recently!). There is no way we can align all these release schedules, test as a unit, and release it as a whole.
The situation is the same or worse for web services. The whole point of a Service Oriented Architecture (SOA) is that each piece is loosely coupled and can be upgraded at its own schedule. If every service you depend on is upgrading out from under you, it isn't possible to align schedules.
The old best practice of aligned release schedules is becoming less and less relevant.
I'm not saying that this is good or bad. I'm saying this is the new reality that we live under. In the long term it is probably for the best.
My question for the readers of this blog are: What are the new tools and best practices you use that address this new paradigm?
I think it really depends on the business environment you work in. Most banks, for example, have very good reason to maintain the status quo of waterfall development and the attendant monolithic release cycle.
My employer, which is globally distributed, for a long time, had all of the development for all the groups take place in one office, by one team. Getting one group's plans onto the development team's radar typically only happened once or twice a quarter, barring something particularly urgent, and even then, just getting it on their radar didn't reliably mean you'd get it any time soon.
We recently brought our development team in-house and have been developing according to classic two-week-long sprints. Even this much has proved difficult for the business, having so much inertia and culture attached to the old style. After a year like this, their finally getting used to the new style, just as we're starting to get enough traction within the development team to feel comfortable talking about Kanban. That should be entertaining, trying to explain this to the stakeholders.
I don't think aligned release schedules are necessarily become less relevant. There's still a lot of cultural preference and familiarity for monolithic releases, along with the bureaucracy that's inevitably involved with the old cycles. Getting the technologists working agilely isn't nearly as difficult as getting business stakeholders doing it... and as far as tools you need for that goes, you're pretty much limited to the clue-by-four if you can't apply executive pressure.