Does Continuous Production Lead To Extreme Agility?

Many corporate customers don't want their applications changing on them regularly because there is a significant training overhead.

The training overhead issue only applies for habitual usage applications. And the significant training overhead is showing up because 1. the application was not designed with learnability in mind and 2. too many changes are being introduced at once instead of gradual changes

Non-habitual use applications require re-learning all the time and should be designed to be inherently intuitive to use (aka approach zero learning time).

Exactly, Jason. If a user needs to learn about one new feature, it doesn't take very long. If they have to learn about 10, it's going to take much longer... perhaps 10 times as long! ;)

I'm actually quite tired of hearing the argument that "the users don't like the application changing on them". This comes from the same people who scratch their heads wondering why the users are complaining that they don't get new features often enough.

I've been doing some work with a startup that deploys to production as often as is humanly possible. This isn't as much an indication of the group's agility, but rather it's essential for their business. If something is messed up in the release, then you simply revert back to the last released version. That's not a big deal, since it was probably only one feature ago.

Perhaps the key motivation here is based on fear. In the former case, the people are fearful of "screwing up" for lack of a better term, since a rollback would mean that many features wouldn't be delivered. In the latter, the startup fears not being able to show that they can deliver a product with features that people want, and can tolerate one or possibly two features being rolled back while they are fixed.

My experience has been that if the deployment process is relatively simple, delivering as often as possible really focuses the whole team. It doesn't have to be stressful, either. You build something, then you release it. Simple as that.

Dave Rooney
Mayford Technologies

The training overhead issue only applies for habitual usage applications.

"This isn't as much an indication of the group's agility"

It sounds like a pretty good measure of a groups agility to me!

"This isn't as much an indication of the group's agility"

It sounds like a pretty good measure of a groups agility to me!

"day traders who can't take their eyes off of the screen for a second" - would those day traders prefer to lift their eyes for an hour to learn one new feature a week, or take three whole days off each quarter to learn 24 new features, and not have the benefit of those features for up to 3 months after they were ready?

Note that where users' well-being or money is at stake you can't afford the 'continuous-beta' releases to be buggy.

"day traders who can't take their eyes off of the screen for a second" - would those day traders prefer to lift their eyes for an hour to learn one new feature a week, or take three whole days off each quarter to learn 24 new features, and not have the benefit of those features for up to 3 months after they were ready?

I can't find the article, but here's a blog entry talking about essentially what I had read:

beingextreme.blogspot.com/2005/10/my-first-real...

Dave Rooney
Mayford Technologies

I dunno if I buy that. Like continuous integration, frequent changes might make each change smaller and easier to absorb, whereas large batches of changes might require significant retraining.

It might be a different story if frequent change resulted in a lot of churn - changing one feature repeatedly requiring people to come to terms with "the latest" change over and over.

It's also tricky if the change is subtle - not visible, but important. So the way you introduce changes might become important.