What Puts the ‘Velocity’ In ‘Service Velocity’?

Publish date:

cited as cause for going
“more IP,” and eventually “all-IP,”
is the notion of “service velocity”
— new-tech talk for getting more
stuff to market more quickly. As in,
ditching the time-tested “one new
thing every 18 months” plan, long
an unfortunate shackle of the settop-
based digital video world.

Rather than trudge yet again through the depressing
realities about why things take so long
in today’s world, let’s look at what puts the
“velocity” into new-service rollouts.

This probably doesn’t come as a big surprise:
Turns out it has a lot to do with the tsunami of
software-based everything that’s making the
workplace, and people, more efficient.

Talk to the people whose work it is to bridge
between now and next, and specifically service
velocity. They’re almost always IT/information
technology people. Chances are high that you’ll
hear two terms pop up again and again: Agile
programming, and waterfall programming. “Waterfall”
is old world; “agile” is new world. Proponents
on each side tend to snark on the other.

Here’s some examples, from recent notes:
“Waterfall is a disaster … you get these designs
that aren’t influenced by reality.” And (puffed out
with pride): “We run an agile development shop.”

My personal favorites: “Agile is the only way you
can keep track of all the sh#t that’s going on in the
network and at the end points,” counterpointed by
“Agile, tiger-teams, it’s all a bunch of crap.”

“Waterfall” coding goes like this: You need to
roll out a new video feature. After it’s designed, by
the design team, it goes to the quality assurance
team. Then to the solutions, integration and test
team. If that’s all good, it gets released. Waterfall
time is measured in double-digit months — and
heaven forbid something changes along the way.

(Things that take a long time always remind
me of a favorite joke. MSO to vendor: “Great!
When can I have it!” Vendor: “In six months.”
MSO: “Six months from when?” Vendor: “From
every time you ask.”)

Agile programming is different. It splits the coding
workload into chunks, which are constantly
shipping, written by small teams that work in twoweek
“sprints.” Changes are assumed, meaning
that time is reserved to add stuff in, if requested.

None of this is new, by the way. In the world
of computer science, it’s an old saga. A Google
search on “agile v. waterfall programming” returned
540,000 results. Books are written on it; seminars
are taught about it. It’s new to us because software
is eating the world — and to survive and thrive, we
need to know what and how software eats.

Stumped by gibberish? Visit Leslie Ellis at