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

Krzysztof Rakowski
Apr 3, 2017 · 7 min read

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

2017-03-15 20.45.27
2017-03-15 20.45.27

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

Continuous Delivery value to your organization and customers

  • 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

Time to market — business vs. DevOps understanding

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

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 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

Rigid rules vs being very agile

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

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

2017-03-16 17.31.56
2017-03-16 17.31.56

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 :)

eMAG TechLabs

On this blog you will find materials written by eMAG Tech…

eMAG TechLabs

On this blog you will find materials written by eMAG Tech community about the projects they are currently developing, the technologies they use and the manner they are using them for best results.

Krzysztof Rakowski

Written by

Web apps expert, fan of new technologies.

eMAG TechLabs

On this blog you will find materials written by eMAG Tech community about the projects they are currently developing, the technologies they use and the manner they are using them for best results.