Continuous Delivery value to your organization and customers — notes from Retail:Code 2017 conference

Last week I attended Retail:Code 2017 conference in London. In this article, I will write about my experience at this event and discuss the key takeaways of the experts discussion panel on Continuous Delivery that I facilitated.

About the Retail:Code 2017 conference

The event’s mission is to bridge gaps in retail and e-commerce between managers and IT people, especially in the terms of Continuous Delivery and DevOps. What was unique is that two and a half days were packed not only with talks but also with many opportunities to exchange professional experience and do networking. Speakers presented their experience with topics such as DevOps and Agile implementation in large companies, building data-driven strategy and cloud based solutions. There was also separate track related to fintech solutions. The event was partnered by such well-known companies as Atlassian, GitHub, Puppet, Chef and many more (most of them related to testing, automation and DevOps).

Challenge Your Peers

I was invited to be a moderator of one of the knowledge-exchange panels under the “Challenge Your Peers” format. Goal of this type of meeting is to gather IT professionals and business managers together and let them share their experience in a moderated discussion. Role of the moderator is to facilitate the discussion and compile a list of key takeaways to be distributed later as a part of post-conference materials.

Continuous Delivery value to your organization and customers

The subject was compiled by the organisers from so-called “hot topics” gathered through the questionnaires filled out by the attendees. As the conference’s leading theme was Continuous Delivery and DevOps, the topic of my panel was “Continuous Delivery value to your organization and customers — improved effectiveness and time to market”. There were also three questions defined to put the discussion on the right track:

• Continuous Delivery — what are the business advantages?
• How to break down the siloed behaviour and develop a culture of responsibility across the organization?
• How to align the goals of developers with the company goals and values?

I organized the panel into four phases: introduction and formulation of the topic and then discussion of each of the three questions prepared by the organizers.

The reality turned out to be completely different, as the participants passionate approach moved the discussion into other direction — which proved to be beneficial and very educational.

Discussion participants: IT vs. business

As anyone could sign up to be a participant of the discussion panel, I wasn’t aware — until the last moment — who will attend the session. Ultimately, there were around ten participants from diverse backgrounds, which made the discussion really interesting: among others, we had a strong team of IT guys from large e-commerce company from Western Europe, e-commerce director from well-known German retailer and representatives from one of the world’s biggest retailers based in France. This made a great mix of IT and business people, which later turned to be a great opportunity to see the issues from different perspectives.

Time to market — business vs. DevOps understanding

First talking point that emerged right after the presentation of the subject was how “time to market” is perceived by IT people who implemented Continuous Delivery principles and business people, who are involved in conceiving projects and then are responsible for introducing them to the market.

Rapid development and deployment process coming from the Continuous Delivery principles cause the projects to be really small, such as one user story or small feature. “Time to market” in such environment is defined as a time between creation of said user story (or other workable item) and deployment to the production infrastructure.

Participants from the business side of the companies highlighted, that their understanding of “time to market” is completely different and frequently inconsistent from the one presented by the developers. They understand it as a time from the project being researched and defined (for example by the business analysts, based on the business intelligence input) to the point where it is deployed, properly advertised and introduced to the market (preferably with the quantitative results).

Results of introduction of Continuous Delivery practices

For the remainder of the panel we discussed the results of introducing Continuous Delivery practices in the participants’ organizations.

Main nuisance before the introduction were lack of control over what work is being done and technical problems piling up. When paired with the lack of any project management methodology (i.e. agile, such as Scrum) this caused often chaos and low motivation of the team members.

We then discussed the positive outcomes of introducing the Continuous Delivery. Most of them were related to the better organization of the teams work, such as introduction of agile methodology, frequent releases (not less than once a day) and independent release schedule for each of the teams. This also meant architectural changes: moving from monolith structure to microservices, which are easier to maintain.

Smaller apps and more frequent releases mean that the risk introduced with each deployment is much lower and easier to control, than when one big change is done once in a time. In an unlikely scenario of failure, the small rollback is uncomplicated and safe.

Lower risk wasn’t only outcome of the change. Time to market was reduced — in both the IT and business understanding. Feedback loop from the other department and customers was really rapid, with updates possible within very short timeframe. It was also observed by the IT management, that the teams became much more productive under the new regime.

How to motivate the developers to change?

One of the important topics is how to motivate ourselves, our colleagues and subordinates to change to the new way of thinking? We discussed some of the ideas.

One of the companies introduced a model, where developers had to earn the trust of the former “Ops” teams, to have access to the production environment and be able to do the releases. They had to show knowledge of proper rules and prove it through the internal certification.

Gamification is also useful tool in such situations: people are motivated through various — frequently virtual — incentives to perform specified tasks or trainings.

The theory says, that changes cannot happen overnight, especially when innovation factor is involved. Managers cannot expect, that one day everybody will change their thinking and start behaving different. In such cases pioneers (also called early adopters) are important: they are restless minds, who will take the challenge and show initiative to shape the world around them. Even they won’t do this on the spot, but with time the idea will grow and they will be the change leaders and an example for their colleagues. Shortly others will follow, seeing that the success is possible and brings valuable and positive outcome.

Some of the discussion participants underlined the role played by the sense of urgency: it gives everybody an inspiration to change the behaviour, when the shift is imminent.

Very popular Spotify engineering culture model was also mentioned as an inspiration for change and how to shape the organization aftewards. Common conclusion for this point was that this model should be analysed and adapted to the local needs, not treated as an “one size fits all” solution.

Different management structure before and after introducing of Continuous Delivery

Participants from the e-commerce company shared their experience related to the management structure before and after the change — which also implied the organizational structure. Initially, roles of development and operations managers were separated, with people doing the development and deployment located in the different silos. This — of course — was contrary to the Continuous Delivery principles and most agile methodologies (in terms of the team cross-functionality). During the change, structure was modified so that separate development and operations managers were merged into the domain or product managers (with line managers left intact).

Rigid rules vs being very agile

Introduction of the new principles often requires creation of new rules, architectures and workflows. Sometimes this may kill the agile spirit if the rules are too rigid. On the other hand, too much agile may mean chaos and lack of control over what is happening and will happen, destroying the purpose of the improvement.

The conclusion from the discussion was that it is hard to specify permanent rules at the beginning of the transformation. Continuous improvement is required, through frequent reviews, feedback and incremental changes.

Metrics are very important

At the end of the panel we talked about how metrics are important for the Continuous Delivery and agile process. It is essential to find, how to illustrate the health of the project, workflow or team with indicators and then monitor them. Dashboards or other interactive tools are especially effective in propagating such information.

Of course, the best is to have everything “green” — team’s success can be impartially confirmed and business people are happy, when they see the numbers go up and up :)

Conclusions from the discussion

As you may have noticed, I didn’t tend to teach you authoritative knowledge, but rather reported on the contents of the talks. That was the purpose of the “Challenge Your Peers” session — to discuss different views and share knowledge. The burden of interpreting them and planning on what to incorporate into your environment rests on the panel participants and now — on the readers of this article.

We concluded, that our discussion was really fruitful, informative and entertaining. With this in mind we went for a beer and conference’s networking dinner to the nice restaurant in the posh Kensigton High Street :)