Continuous Lifecycle London 2019 - Day 2: Communication & Collaboration

Day 2 of Continuous Lifecycle London 2019! See how Day 1 went here.

Some of the highlights:

Matthew Skelton (Conflux) - “Practical ways to increase operability within Continuous Delivery“

Image from iOS (3).jpg

Key Points:

  • Operability is all about customer experience and service viability, not short-term feature delivery. Address operability early on!

  • Continuous delivery needs food engineering practices, fast feedback from deployment practices, re-aligned architecture & team ownership of software and services.

  • Use 5 operabilty techniques:

    • Modern event-based logging - focus on the intent, not the tools

    • Use Run Book dialogue sheets

    • Endpoint healthchecks

    • Correlation IDs

    • Lightweight User Personas for Ops

  • Multi-dimentional engineering assessment: Team Health, Deployment, Continuous Delivery, Flow, Operability, Testing.

  • Operational aspects are also features

  • Make space for learning and sharing - promote good work and help to develop skills in speaking.

  • Involve teams in improvements - co-create engineering standards


Angie Jones (Applitools) - “ The build that cried broken: building trust in your continuous integration tests”

Image from iOS (4).jpg

Key points:

You can learn a lot from fables!

  • The shepherd boy and the wolf - regarding testing logs: when you are getting messages that say that the system is always broken, but it works fine you stop caring and do not notice when it breaks for real - make sure you are getting only relevant error messages.

  • The fox and the goat - look before you leap: if your end goal is fast feedback, do not make the mistake of caring just about automating everything whether it makes sense to automate it or not - make sure you do not forget the end goal.

  • The lioness and the vixen - quality over quantity: make sure you have relevant tests, it is not the number of different tests that matter but the quality of them

    • Manage flaky tests - the ones that sometimes fails - sometimes pass:

      • stable identifiers

      • intelligence waiting

      • source of truth, shortcuts

  • Magician: don’t value new code over the one you have already

Hannah Foxwell (Pivotal) - “Reliability Engineering for Humans“

Image from iOS (5).jpg

Key points:

  • #HumanOps - the wellbeing of human operators impact the reliability of the systems.

  • Failure is normal - we need to change our focus from preventative approach to being prepare when failure happens - it will happen.

  • Blameless incident review: we don’t call it postmortems anymore - nobody died, failure is normal.

  • SLIs, SLOs and Error Budget - acceptable amount of failure. You do not need to be the size of Google to use those practices.

  • 100% reliability is not your target. So what is? 99%? Set your service level objectives and set them realistically.

  • Enforce your error budgets, make sure everyone understands the error budget and how it works.

  • Psychological safety is important. Belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes. Teams were measured on psychological safety, error rates and team performance. Higher psychological safety correlated to higher error rates, however, higher error rates correlated to higher team performance.

  • Toil - anything that has no enduring value. Toxic toil is the one that wakes you up at night, ruins evenings and weekends, interrupts your work and distracts you.


Image from iOS (6).jpg

Key Points:

  • We talk about empathy between Dev and Ops, but what about the rest of the business? Excutives, marketing, finance, sales?

  • Different perception in different side of the business: c-suits, management and team usually have different view of the business, the higher up the more optimistic it gets

  • Impoverished communication leads to generalizations and inaccuracies:

    • Up and down the communications ladder - communication upwards isn’t accurate

    • We generally try to report good things, so if anything is not going well it is often does not get reported to upper management and they think that everything is going well until it does not.

  • Authenticity - the more you are likely like yourself, the more employees are likely to trust you and understand you.

  • Optimism bias - we end up looking at the wrong attributes. Biologically, our brains are not made for office work, brain takes shortcuts that are not useful in our way of life anymore.

  • Interpersonal distance increases optimism bias

  • Dial down management cynicism - we are all responsible. Managers are not the only hypocrites - we often delude ourselves that our software are better than it is.

Overall, the main theme for both days seem to be the importance of psychological safety and good communication skills - Maslow pyramid of needs was mentioned in most of the talks I managed to see as well as blameless culture, clear and precise communication up and down the chain of command. Also, AWS, operability and the importance of good logging practices were some other common themes.

Continuous Lifecycle London 2019 - Day 1: Culture, motivation and having fun!

I am really glad to be a part of Conflux team who went to the Continuous Lifecycle London conference today! It’s the fourth time the conference is being held in London and it’s always a good fun - so many interesting talks that make you rethink the way you do things and give you ideas on how to solve your problems, so many interesting people and interesting conversations!

Here are my impressions of the day:

Keynote: Tanya Reilly (Squarespace) - “Continuous“

Image from iOS.jpg

Some highlights:

  • We are busy all the time and it takes time to disconnect - “how much are you here?”

  • We are continuously moving but not always in the right direction, thus we need step outside of the continuous and make sure you we going the right way.

  • “If you don’t think railroads are cool - you are like an alien to me”

  • Two theories of motivation:

    • Maslow pyramid of needs

    • Daniek Pink - autonomy, mastery, purpose

  • “Shiny-driven-development” - we are drawn to shiny and interesting things, we want to solve interesting problems.

  • Productivity - personal output, generativity - difference between the team’s output with me and without me.

  • Don’t do less well. Do less, well. - Colm MacCárthaigh.

  • You don’t need to fix every single thing that’s broken, it would feel more productive, but lots of on-going things would just slow you down and won’t make you reach your goals faster, leave it for designated time. Also, leave fun but not too useful things for right now for the designated time also.

  • Don’t lick the projects! Don’t claim it unless you are doing it this quarter.

  • Write down whether you are or you are not doing things. Keep away from being vague, make sure everything is clear, precise and there is no confusion between people in the team.

  • Being nice is not the same as being kind - nice is external, kind is internal.

  • Senior people set the culture whether they plan to or not - be deliberate. Ask questions, admit you do not know things, learn out loud, call out good work, say that you approve, thank people who admit they broke stuff, notice who’s blocked and help them, make everyone better. If you are senior person, part of your job is to make everyone else better.


Michael Cote (Pivotal) - “Creating a DevOps culture, whatever that means“


Key points:

  • Technology is easy. It’s the people that are hard.

  • “Robot dogs are coming to destroy you” - that’s how you used to scare the people into innovating.

  • Easy culture definition - how do we do things here.

  • You want the people in your organisation to be innovative, risk takers and teams to be people-centric, but it is not easy to get there.

  • You have to figure out a way to make people to take risks, however, risks need to have some sort of safety net, i.e. -If you want to learn how to surf, you need to know how to swim. Support is essential.

  • Leaders needs to give the teams autonomy, trust and voice. Teams need to own their product - responsibility and “parentship”. The autonomy is not easy, but managers have to learn how to trust the teams to do the work.

  • Some more tactics for the leaders: delegate, give feedback and celebrate failure.

  • Blameless postmortems - build trust, talk about your failures.

  • Unmotivated executives: focus on cost reduction to motivate the executives - everyone cares about saving money.

  • Change is hard - so create a new organisation! Sometimes it’s easier to start from the beginning.

  • Money plays a big role in actually putting a good culture in place.

Besides all the useful tips, Michael gave lots of good book recommendations! See them in the slides.


Holly Cummins (IBM) - “The importance of fun in the workplace“

Image from iOS (1).jpg

Key points:

  • Why is fun so unacceptable at work? Why people don’t put that they like having fun in the CVs?

  • There is a ton of research on fun, though research drives the fun out of fun. When fun is your job it becomes not fun.

  • Funtinuum is a thing.

  • What defines fun is positive effect.

  • Programming is fun - we have exploration, puzzles, games which should make it fun, so why are most of our workplacesnot fun?

    • 80/90s management model - hierarchical, dates back to the military

    • fun used to be frowned upon, though even Aristotle said: “Pleasure in the job puts perfection in the work“

  • Studies shown that when employees have fun, they take less sick leave and are more productive. Research has proven that after watching a comedy video, people were 12 % more productive.

  • Computers don’t expect to have fun (yet). Make them do boring tasks - automate!

  • Continuous integration should feel fun, if it does not feel fun - you are doing something wrong.

  • Your brain needs breaks - breaks with exercise are even better!

  • Is it possible to get fun wrong? Yes, team building activities - nobody likes being forced to have fun. If you want to ruin an office party - take attendance.


Elisa Binette & Beth Adele Long - “Fighting fires for fun and profit: How to be a great incident commander “

Image from iOS (2).jpg

Key points:

  • Incident reports differs from every day tasks by being high stakes and high cadence. Also, almost all incident response is group activity.

  • Incident Commander regulates the flow - IC is the person at the centre of the storm, coordinating all the people together, bringing everyone up to speed.

    • they are not controlling what happens

    • they need to coordinate all the people together to make it less expensive - less overhead for engineers, less confusion for customer support etc etc.

  • ICs deal with emotion, information flow and analysis:

    • Emotion - when incident happens, you usually have a lot of people in one room - all experiencing fight, flight or freeze responses. The role of the IC is to get people out of that reactive mode, because people in the reactive mode are really bad at solving engineering problems.

    • Information flow - ICs regulate the information flow to make sure all executives, security, customer support have the relevant information concerning them.

    • Analysis - good IC needs to know what the current priorities are.

  • Training IC - how do you find the right people and train them? You can train people to be ICs, but normally they need some personal prerequisites:

    • technical fluency - vocabulary + calibration; self regulation - calm + sense of urgency; willingness

  • To prepare ICs you need resources - process and tooling, documentation, training, also - practice! Have game days, let them practice on small incidents, do apprenticeships

  • Habits of great incident commanders:

    • being familiar with explodey bits, knowing the boundaries of your expertise, knowing how to gather resources instead of being the resource, being able to compare the perspectives instead of seeking the right one.

Overall, the the talks I managed to catch had a common theme of emphasising the importance of having a good culture in your organisation, what a good culture actually is and how to achieve it.


We are at the Continuos Lifecycle London tomorrow also! Visit our stand to know more about Conflux, get 30% discount for Conflux Books or win the construction set!

More information about the promo:

Sustainable Digital Delivery - What Works? - Leeds Digital Festival 2019

As part of Leeds Digital Festival 2019, Conflux hosted the “Sustainable Digital Delivery” event - half a day of talks from local industry experts and community leaders. The topics for the day ranged from the engineering culture, MVP to open API - there was something for everyone. Also, the attendees had an opportunity to discuss the topics further with the speakers after the talks.


Matthew Skelton of Conflux opened the event by defining "Sustainable" , "Digital" and "Delivery" and what it all means together:

Introduction and welcome by Matthew Skelton (Conflux)

Key Points:

  • "Sustainable" - avoiding human burn out, making sure teams are not affected by how we build software and the way we build software enables the ongoing evolution of the software

  • “Digital” :

    • 1) Rapidly-developed services accessed via personal compute device

    • 2) Rich telemetry for existing processes provided via software and sensors

    • 3) Highly effective ways of working discovered & evolved through 1 and 2.

  • "Delivery" - software gardening, you build it, you run it, co-creation - not “throw it over the fence”

Short talks by Leeds-based experts

The rest of the day consisted of 7 short talks and a discussion afterwards. Here is a quick summary of each of them:

Tanja Lichtensteiger (Sky Betting & Gaming) - How to Build a Great Engineering Culture


Key Points:

  • Engineering culture is it is all about the people - happy engineers build better products

  • Main ingredients for good engineering culture:

    • People & teams, if you don’t get this right, you won't have a chance in hell to build great engineering culture.

    • Hire for potential, attitude and resilience - technical ability comes second

    • Ingredients for job satisfaction: autonomy, mastery, complexity

    • Psychological safety - let them be who they are at home to be at work, encourage diversity, no ego

See more about Engineering Culture by Tanja Lichtensteiger

Clem Pickering (Infinity Works) - M is for MVP (or is it?)


Key Points:

  • MVP - minimum viable product - just enough features to make the client satisfied.

  • Ideally you should move towards:

    • M - multiple, M - is for Monthly - when you come from once a year, once a month release cycle is a good change.

    • V - valuable

    • P - experiment

  • Challenge the concept of MVP - focus instead on establishing regular, iterative delivery, take the tube not the release train.

See more about MVP by Clem Pickering

Lorna Mitchell (Nexmo) - Describe your APIs with OpenAPI


Key points:

  • Decribing APIs - describe RESTfullHTTP API in a machine readable way:

    • Produce API reference documents

    • Auto-generate code SDKs

    • Use description in other developer tooling

  • Spec-First API design

    • That's what’s magic about it - it is open, there is so much that you can do about it.

See more about OpenAPI by Lorna Mitchell

Royd Brayshay (New Redo) - A little sustainability insight


Key Points:

  • Little's Law: Cycle-time = WIP/ Throughput - comes from queuing theory

    • Limiting WIP positively improves cycle time, reducing cycle times (reduce blockages) reduces IP

    • Adding capacity (throughtput) with people or process improvement benefits cycle times

  • There is a mathematically provable relationship between the work coming in, and the work leaving.

See more about Little’s Law by Royd Brayshay

Claire Garside (Foundation for Digital Creativity) - Developing diversity in the digital talent pipeline

LeedsDigi19 social media cards (4).jpg

Claire talked about working with students who use digital skills for courses that would normally not be related to IT but nowadays need IT skills also.

  • How can being out of your conform zone can improve your skills?

  • Proven through the theory?

  • Democratising IoT

  • thingQbator

    • the practices are embedded in the course

    • Students respond to real world problems

Ben Davison (Axiologik) - Techniques for sustainable digital delivery at scale


Key Points:

  • Digital is not Agile or cool tech. Digital is paradigm shift in how we consider business and tech. It is a fundamental re-imagining and re-engineering of an organisation around customer journeys.

  • To succeed, you need to worry about three things:

    • what you are going to do

    • how you are going to do it

    • how you are going to get there

See more about techniques for sustainable digital delivery at scale by Ben Davison

Matthew Skelton (Conflux) - Sustainable software delivery through operability


Key Points:

  • 5 practical operability techniques:

    • Modern event-based logging

    • Run-book dialogue sheets

    • End-point healthchecks

    • Correlation IDs and traces

    • Lightweight User Personas for Ops

  • Address the operability early on - good logging is foundational

See more about sustainable digital delivery through operability by Matthew Skelton

See all videos on YouTube - Sustainable Digital Delivery

Overall, the day included many interesting talks that had a lot of useful information to make software delivery as painless as possible, tips and tricks on good engineering culture and how to make your software delivery sustainable. Check out individual blog posts to each talk to get more information!