People are creatures of habit and like to have a solid schedule for the projects that they have to complete. Software development is no exception to this rule. Think of anything you do in life or in your own job –it’s nice to have a repeatable process to go through, isn’t it? To have some semblance of order? This is why living and dying by a reproducible software delivery schedule is extremely important.
People like to have a repeatable process to work through. The same is true for a software delivery schedule. The time frame itself isn’t what is important. It could be a 3 week schedule or a 3 year schedule. You have to do what works for you, what works for your software, and what works for your team. The point is that you’re creating a process and schedule that can be reproduced again and again. As long as it’s a repeatable process, you are heading in the right direction. People can appreciate that more than just flying by the seat of their pants.
When you plan your timeline and deadlines around releasing software on a specific date, think of it like planning a vacation. You pick a specific week what works for you and then a specific day. Once you have your travel dates, all the other necessary tasks fall into a timeline. You have to find a place to stay, buy plane tickets and book other travel arrangements, babysitters or dogsitters, arrange for your mail to be held, etc. When the day comes that you’re set to leave, you don’t suddenly go, “Oh, I’m not ready. I need more time. I didn’t get a chance to do XYZ.” No. You just go on vacation. You may be missing a few things or be less organized than you wanted to be, but you still go.
That’s how delivering software in production is. You pick a date and then you live and die by that date. There are times you don’t go on that vacation, but it has to be pretty dire to cancel. The same is true for delivering software in production. It has to be a very big issue to cancel. Once you deliver on your deadline, you repeat the process and do it again. The same as your next vacation. Book your next date (you should already have these dates pretty well set up in advance with software development), and arrange all of your tasks to lead up to that date. That is your delivery date; that is your travel day. You’re going whether you’re ready or not.
So what are your thoughts on having a repeatable software delivery schedule? Do you think you should stick to it no matter what? Do you think the repeatable process makes it easier for a team to know what to expect and to know what’s expected of them? How has this gone wrong or right for you in the past? Comment below!
