The Eye Twinkle - Speedy Feature Deployments

Anyone who knows me, knows I like to do things quickly with quality. Don't get me wrong, I have great appreciation for unhurried, leisurely dev cycles, in fact we all need these periods. But it's a rush when we're in a rush, pun intended. When I'm given a short deadline to design a solution for a client there are a few rules of thumb I like to follow.

Divide and Conquer

I like to break the problem down into smaller manageable chunks. I find that delivering smaller pieces while keeping the finish line in view not only gives a feeling of instant gratification, but it also keeps up morale and momentum. I know I know, this is just how agile works, however there is some fluidity that can be incorporated into rigid sprints and user stories that allows a dev team seamlessly deliver back-to-back stories in inter or cross-sprint cycles. Tactics like stubbing out external calls, or 1-step ahead of dev design allows sequential tasks to be parallelized so waiting periods shrink. It's similar to a checklist with several tasks. Looking at the checklist in its entirety can seem overwhelming but looking at a couple of items on the list and completing them gives a sense of accomplishment and satisfaction. It also reduces the number of tasks left to complete, which provides a jolt of positivity to the team.

It's OK not to Know

It doesn't bother me if I don't have all the answers initially, but because I don't have all the answers I like to get iterative feedback. I like to involve my business, architects, auditors, and QA early enough in the process to correct mistakes. Getting feedback is a delicate dance during this period because too much review could cause unnecessary re-work, too little review could result in building the product incorrectly. When you hit the sweet spot you not only end up with a great product, but you've built great relationships along the way. I liken the experience to building a house while having an inspector onsite. The inspector can tell you while you're laying the foundation that things are off by an inch, giving you time to rectify the problem. Conversely, building a home and waiting until things are fully built to have an inspection could have catastrophic impacts.

Phased Deployments

I like deploying features in phases because it allows the team to fully focus on the next sprint. If the team has successfully tested a portion of a feature that could not run standalone, but deployment of this piece would not adversely impact the product it's good to deploy. For example if a new service has been fully tested, but cannot be invoked until a later period of time, deploying the new service has no impact on any existing work because it cannot be invoked. Similarly, if a new service is invoked but it's data or the results of the service are not used until integrated with other systems or services, deploying the service has no impact on the product. These phased deployments do 2 things.

• Give the team the freedom to move on to the next portion of the feature.

• Ease the deployment process by having production ready code living in production.

I have used these techniques and strategies across industries to help reduce downtime due to outages and to speed up delivery processes, saving my clients not only time but money as well. What techniques have you used?