Here's the biggest tip for managers and companies that want to get code deployed. Fix the process, not the people - and let the people doing the work define the process.
http://teriradichel.blogspot.com/2014/11/fix-process-not-people.html
* Decline extraneous meetings
* Make sure the business requirements are complete for the story you are working before you start.
* Focus on writing and testing code
* Ignore distractions and noise like complaints and process discussions that don't get software deployed.
* Avoid being a distraction by complaining or instigating dissent and conflict.
* Stop talking about all the work you aren't going to be able to get done. Sit down and do what you can.
* Lead by example. Do what's right for the company.
* If you have competing priorities, ask the people giving them to you to prioritize them and start from the top. Make it visible to all the priority list you have been given.
* Think about ways to get everyone working in parallel. Make sure you are not the bottleneck and blocking others from delivering value but rather contributing to them doing so successfully.
* Make new stories for scope creep. This is makes the new effort clear to business.
* Before nixing a deployment go over the pros and cons of releasing all or part of the work in a certain state with business and give them the option of releasing or not.
* Focus on must haves for the end result that delivers business value.
* Sit with people when it makes sense and fix problems together
* Collaborate to resolve problems. Focus on the resolution that delivers the most business value, rather than an idealistic scenario or the one that gets people to stop bringing it up if it is truly hurting the company.
* Call out impediments that can be fixed; deal with those that are part of the process creatively, if you can.
* Write unit tests when you can and while QA is testing; Don't be ivory tower about it and block the whole team.
* Have QA write automated tests while waiting for code drops so their testing is faster and repeatable.
* Find ways to seamlessly share data set up scripts for QA automation and developer unit tests to leverage people's work in more places and get more automated tests in place.
* Create system designs that are flexible to change.
* Design new systems that can run in parallel with old systems and can be turned on or off before or after deployment if something goes wrong.
* Structure code with appropriate interfaces and decoupled components so they can be independently unit tested and team members can work in parallel.
* Avoid monolithic designs with 5000 line stored procedures or classes that are a bottleneck to your project.
* Design the system so it can be deployed in pieces by thinking about how to break the system down into independent processes - which could ultimately become distributed services.
* Work towards a horizontally versus vertically scaling architecture, but make sure your management and visibility into all systems rolls up into a single source. Think correlation of logs and Splunk or a service for logging all actions by all systems.
* Break off most problematic bits of complex systems into decoupled, horizontally scaling component intstead of rewriting and deploying a whole new system in one shot.
* Automate everything. Make people's jobs easier and avoid mistakes.
* Avoid technology for technology's sake.
* Beware of making a new technology or set of libraries a dependency until you have done a proof of concept and completely vetted the technology to understand implications, limitations and security risks (published on security and other web sites). Do research. Test. Consider the cost of every project forced to use it going forward, including maintenance and production support. Consider the potential longevity of the technology vs. other options and industry trends so you can find people who want to work for you in the future.
* Be like Amazon. Use services for interfaces between systems.
* Measure and think about what will deliver the most profit to the bottom line.
* And if you are like me and obsessive about delivering business value, and your schedule is flexible, adjust your schedule so you can work at least a couple hours when there are less people in the office and no meetings.
* Working from home one day would be really nice but it would be helpful if the team could agree on which day because in office collaboration can be extremely helpful at times to move a project forward.
* Amazon tells employees to be self-critical. I like that. If you are wrong admit you made a mistake rather than obstinately protecting your ego and blocking delivery of maximum business value.
* Considerations for the process as a whole: http://websitenotebook.blogspot.com/2014/04/agile-and-scum-how-to-make-it-work.html
