The more developers assigned to an application, the faster it can change -- I'm telling you this in case you couldn't have figured it out on your own.
Why release management by itself isn't good enough
If we were content to live with software delivery as IT's endpoint, we'd be done now. But we aren't because being done when the software meets requirements and adheres to specifications is what last-generation IT is about.
That's one of the problems with Scrum, in fact: While it might look new and snazzy from the perspective of someone accustomed to waterfall methodologies, it is, in fact, a new and snazzy way to do the same old stuff. Think of it as a Kevlar-and-titanium biplane. It's a big improvement over balsawood and canvas, but it's still a biplane.
In next-generation there are no IT projects. We've moved the goalposts, so the job isn't finished until business change has happened.
Making that happen with Scrum and release management calls for additional innovations. That's where Theory of Constraints comes in, along with some nifty embellishments to Scrum. But they won't come in this week's sprint -- you'll have to wait seven whole days for Advice Line's next releasable build.
Sign up for Computerworld eNewsletters.