The Rules of Deployment
When I explained the subject of this article to one of my colleagues, she laughed and said, “Well, duh! That’s obvious to anybody.” I then explained that I had had two recent conversations with different customers who were not taking this approach; for them, it certainly wasn’t obvious. My colleague was shocked, but I suspect that there are a lot of similar companies out there so I’m going to risk writing an article on the subject…here we go!
When you implement agile project management principles, you can’t continue to use a waterfall-based, calendar-driven product release cycle. It does seem obvious in black-and-white terms like that, but I really do have two customers who moved to agile development approaches but retained an annual product release schedule. They explained their logic in terms of customer expectations and the complexity of the product, and I can understand why they felt that it made sense. But how much functionality just sits on the shelf for months waiting to be deployed to customers who are crying out for it?
If you are going to commit to agile development, then commit to more frequent deployments and everybody wins.
More frequent doesn’t mean “less managed”
Let me be clear right from the start: I am not suggesting that each sprint get deployed to production--that’s not a
Please login or register below to read the rest of the article.