How to communicate within a company what is being Continually Deployed

Question

I work for a small development company, 20 people total in the entire company, 3 in actual development, and we've adopted CD for our commits to trunk, and it works great, from a code management and up-time side. However - we're getting flak from our support staff and marketing department that they don't feel that they're getting enough lead time on new features and notifications on bug fixes that could change behavior. Part of why we love the CD system is for us in development, it's fast, we fix the bug, add the quick feature, close the Bugz and move on with our day to the next item.

All members of our company are now on HipChat at all times, and when a deployment occurs, a message is sent to a room that all company members are in, letting them know what was just deployed (it just shows the commit messages from tip back to the last recorded deployment). We in development are also attempting to make sure that when we're making a change that modifies the UI or a public facing behavior, we post a screenshot to the All Company room and explain what the behavior change is, seeking pushback or concerns. Often, the response is silence. Sometimes, it's a few minor questions, but nothing that need stop the deployment from happening.

What I'm wondering is how do other users of the CD method deal with notifications of new features and changes to areas of the company that are not development - and eventually on to customers in the world?

Thanks,
Francis

Answer 1

Your problem isn't one of communication of changes and isn't one of a poor execution of CD, it is fundamentally a problem of the current structure of your company, and one of developer fanaticism.

Organizations that LIKE Continual Delivery

Much like with people, companies can lean Conservative and Liberal. No I am not talking politics, just a fundamental way that day to day business is viewed and looked at. Liberal companies tend to be open to communication and the inflow of information. They thrive on it. They are more excited about change and see adaptability as opportunity. They tend not to care for following strict processes and can suffer from wild swings in stability and solvency.

Companies that are more conservative are very good at having a specific business objective in mind and achieving their goals in a careful methodical process driven way. Rapid influx of information can be daunting and sometimes threatening. Stability and predictability are more important than being cutting edge and experiencing the latest and greatest. They are good at finding a niche and tenaciously protecting their market positions. They tend to be more stable and consistent in performance.

Liberal companies like startups that are getting off the ground are much more interested in Continual Delivery because it gives them the latest information about progress immediately. They don't have a stable source of funding and fierce competition means that time can be even more valuable than money. Continual Delivery ensures that there is no wasted time from the business perspective when the opportunities for growth are endless.

Conservative companies will ignore CD at best and be annoyed or threatened by it at worst. Their management culture formed as a result of a successful business venture that ensures a steady stream of income. They frown on unnecessary change as it could be risky, introduce new bugs, and the benefit can sometimes be null. It may not matter if the user is any happier with your new features if you already have the users company locked into a service agreement or contract. The money is separate from the quality of the software at this point.

Your company doesn't seem to understand it because perhaps their business model and customer base lend them to lean conservative and fear the constant change that is implied by CD.

Developer Fanaticism and missing the big picture

They may not understand why you even are motivated to achieve this, and to be honest I don't either.

• Is it something that you wanted to pad your CV with?

• Is it a misguided attempt to organically change the culture of the company from within?

• Is there a specific misunderstanding or tension between Customer Support and Development that you are hoping to solve?

This you will have to figure out for yourself. Ultimately though I come to these conclusions about your company by the fact that it seems the Developer Group in your organization needs to "win over" Customer Support on this thing. In a Developer centric organization that is open to change, opportunity and continuous improvement, the Developer group will set the rules and standards and customer support will have to adapt to you.

In the end I am not saying that CD is a bad thing by any means, but it won't benefit your organization. Customer support would ideally be happy to do nothing but order bug fixes from the Developer group as needed like the drive-thru at a fast food restaurant.

Answer 2

The best way to keep everyone in the loop is to have a set production deployment day/time on a reoccurring basis. Then you can send out a notification to all affected employees a list of all changes that will be implemented with the next deployment. This should be sent out well in advance of the changes being deployed (I would say at least an 8hr notice for non break-fixes), and preferably at the same time every cycle so all users know when they have to look for upcoming changes. Asking users to be continually aware of a chat-room message or up to date on their email at all times every day is unreasonable.

On a side note it sounds like there is not staging/QA step in your process, if this is true you should add one, otherwise you are sitting on a time bomb.