PIPELINE Conference 2018 — learning Continuous Delivery


Last month I went to PIPELINE Conference, the annual not-for-profit one day conference focussed on Continuous Delivery.

It was the 5th conference in the same number of years and being the anniversary edition, it was even better than the past two previous years that I went to.

Keynote speaker Elisabeth Hendrickson started the event with a lot of laughter and food for thought. See below a short summary of the talks I managed to catch:

Elisabeth Hendrickson— “Care and Feeding of Feedback Cycles”


Elisabeth talked about the importance of discovering the problems as soon as possible and the many different forms of feedback, both healthy and not.

Key Points:

  • Quality pumpkin = quality death spiral.
  • The stronger QA team is, the weaker is the developer testing.
  • Digression: Schrödinger’s release: until you open the box to see if the release was live or dead — you do not actually know if the probability wave has collapsed.
  • Feedback cycles used to be too long, the idea is to make those shorter.
  • Feedback levels and latency: different kind of feedback has different levels of latency.
  • Agile (theoretically) does tighten the feedback loops, except not exactly -it does not work when done isn’t actually done.
  • Reduce latency by pairing on code — it counts as code review. In addition, it has a side effect of making people more productive and learn faster.
  • Perfection cannot be the goal.
  • Designated merge people used to be a thing.
  • Reduce latency by reducing batch sizes.
  • Do not confuse speed with progress.
  • Pollution cleaning strategies: separate the streams, cross-team partnership, carve out time.
  • Pragmatism vs expediency: false dilemma.
  • Recommended reading:Better Testing, Worse Quality (2000).


Elisabeth Ayer— “ Beyond the Black Hole: Product Management for Continuous Delivery“


Elisabeth talked about the principles behind the agile manifesto and the black holes of common agile implementation practices.

Key Points:

  • From the big bang (releases) to black holes —real users are a black hole for agile that has been implemented. No data back from the real users = black hole.
  • Prioritisation method MoSCow was standard before agile. Then agile came, but early implementation was still flawed.
  • Most prioritisation techniques are designed for Black Hole Agile.
  • “Agile is fundamentally a philosophy of business. Software was its first application.” — Vasco Duarte
  • Continuous Delivery is about shortening cycle times.
  • OKRs are a good solution to shorten the cycle times.
  • No estimates movement
  • Not everything true is measurable, but an awful lot of stuff IS measurable.
  • Prioritisation for Big Bang used requirements to express and rank importance of work. Prioritisation for standart agile orders features to maximise value per developer hour.
  • Prioritisation for Continuous Delivery: recognises the business hypothesis as a loop, removes translation of business goal into prioritisable feature, uses design-led techniques to identify highest-value problems to solve, generate solutions and test their viability.


Daniel Jones - “Continuous Delivery is better for your brain”

Daniel talked about the cognitive psychology findings regarding continuous delivery.

Key Points:

  • People care less about out-groups (silos). Present bias is unavoidable, so we need to exploit is instead of falling victim to it.
  • Social capital correlates with productivity. Human contact > empathy > sociability > productivity.
  • Mironeurons — mirohypothesis
  • The faster neurons are firing, the more valuable is the choice.
  • Self-service makes feature-based workflows economical
  • Scarcity test — IQ dropped 13 to 14 points.
  • Executive control: scarcity reduces willpower
  • Scarcity effect can be triggered by time, social contact, money…
  • Rewards replenish willpower
  • Continuous delivery makes deadlines meaningless
  • Scrum makes you dumb


Tommy Tynjä— "A year of Mob Programming"


Tommy introduced the audience to mob programming concept and explained how and why this works.

Key Points:

  • Agreements evolved naturally — eventually all the code looked the same — you could not tell who’s code it is.
  • Traceability is very important.
  • Keyboard time —they had a timer (etc 6 minutes), then moved to Pomodoro.
  • Give the keyboard to the person most confused about the problem.
  • Definition of done is important, but even more important is to have a definition of ready and know when the team is ready to start solving the problem.


Chris Young— "What can the ARPANET teach us about Continuous Delivery?"


Chris gave us a lesson on early history of internet — ARPANET and demonstrated how it actually worked.

Key Points:

  • ARPANET (Advanced Research Projects Agency Network)— an early packet switching network and the first network to implement the protocol suite TCP/IP.
  • What can the ARPANET teach us about Continuous Delivery?
  • Have vision
  • Have purpose
  • Measure
  • Test in production
  • Build health checks you can respond to
  • Refactor for resilience
  • Embrace exaptation


John Allspaw— “Poised To Adapt: Continuous Delivery’s Relationship To Resilience Engineering”


John talked about the importance of being able to adapt to unexpected situations.

Key Points:

  • All work is contextual.
  • Report from the SNAFUcatchers Workshop on Coping With Complexity
  • Resilience engineering — grew out of cognitive systems engineering, early 2000s. Mainly matter when people work in complex scenarios which have some characteristics of uncertainty, ambiguity and high consequences (Surgery, Power Plants, Aviation, Military Agencies, etc.). Software engineering is a very recent attention of focus.
  • Resilience is an expression of how people, alone or together, cope with everyday situations by adjusting their performance to the conditions.
  • You never see the world bellow the line, you see only the representation.
  • Resilience is something that a system does, not what a system has.
  • Resilience is a story of an outage that did not happen.
  • “A change is not a change is not a change”
  • Complete testing is impossible.
  • Incidents as drivers of software design:
    — Shape the design of new components, subsystems, architectures
    — “Incidents of yesterday inform architectures of tomorrow”
    — Incidents “below the line” drive changes “above the line”
    — staffing, budgets, planning, roadmaps, etc.


Dave Farley— “Optimising Continuous Delivery”


Dave talked in depth about continuous delivery optimisation and deployability.

Key Points:

  • Fundamentally we want smart automation — a repeatable, reliable process for releasing software
  • The Pipeline is a Strategic Resource: It is the only channel to production, all change in production flows through it, so if it breaks or goes slow, the impact is enormous.
  • Slow commit stage: this is not as easy as it seems, dependency management is one of the really HARD problems is Computer Science
  • Common causes of intermittent tests are: rare conditions, poor test isolation, poorly designed test cases and only sometimes something serious.
  • Pipeline problems: slow commit stage, slow acceptance stage, failing tests, intermittent tests and pipeline changes
  • Make your pipeline the only route to production.
  • Branching strategies: don’t branch


Overall, the conference was up to the usual high standard with a large crowd of excited people attending. The talks were very high quality and informative, some common themes were agile malpractices and no estimates movement.

Do check the PIPELINE Conference videos on YouTube as they are worth watch!

Open Forum and Talks: “Digital in manufacturing and making — what’s coming next?”


Today I went to see “Digital in manufacturing and making — what’s coming next?” open forum which kicked off Leeds Digital Festival - a two week long multi-venue city-wide celebration of all things digital.



Despite it being Monday morning, the open forum did not let the attendees to snooze — the topics for the day ranged from the IIoT/4IR industrial automation, bridging the digital skills gap, industry collaboration opportunities to insights from large-scale software delivery — there was something to suit all the attendees despite the wide variety of backgrounds.

We were fortunate to be able to try our hand at coding: Claire Garside of Foundation for Digital Creativity brought over a few Raspberry Pi computers, already assembled and wired up to digital sensors to show the available capabilities and let the attendees have a go.

The open forum was organised by the team from Assembly Conference: an upcoming conference for people in manufacturing, making, and software (the next Assembly Conference event is on Tues 02 October 2018 in Leeds).

The event consisted of three short talks — with speakers from Conflux, Foundation for Digital Creativity, and Thingtrax — followed by discussions during lunch and a Raspberry Pi demo. The opening slides give a bit of context:

Here are the key points from the talks:

Matthew Skelton (Conflux Digital)— “20 Years of Digital: what lessons can we learn for manufacturing and making?”

Matthew Skelton of Conflux

Matthew Skelton of Conflux

Matthew talked about his experience in how software engineering changed in the past 20 years and how it is applicable to manufacturing industry.

Key points:

  • Design for change and failure

  • Iterative delivery works

  • Design for version control

  • the system is socio-technical

The Yorkshire Post featured an interview with Matthew about digital in manufacturing, covering the open forum and industry trends.

Slides from Matthew’s talk:

Claire Garside (Foundation for Digital Creativity)— “Bridging the Digital Skills Gap”

Claire Garside of Foundation for Digital Creativity

Claire Garside of Foundation for Digital Creativity

Claire introduced us to a few Raspberry Pi projects she is involved in and how they are trying to solve the skills gap problem in UK.

Key Points:

  • Remove barriers

  • Offer open access to cutting edge infrastructure

  • Focus on education

  • Build on partnerships


Imran Shafqat (Thingtrax) — “How Digitalisation Saves Money for Plastic Industry”

Imran Shafqat of Thingtrax

Imran Shafqat of Thingtrax

Imran shared some case studies from his personal experience and gave a few ideas how to use the new technologies in industry that were not previously available due to large cost.

Key Points:

  • Industry 4IR are notjust for the “big guys”.

  • Those who dismiss the 4IR are at risk of competitive advantage.

  • Start with small and simple projects.


Hands-on experience with devices and sensors

Several people said how impressed they were at how simple they found it to write code with the PiTop computers using the block editors:


Overall, it was an informative event that give a lot of food for thought and started a few discussions, we will see in the next few years if the current tendencies prove to be right.

You can see other Leeds Digital Festival (16th — 27th April) events here.

The next Assembly Conference — the event for people in manufacturing, making, and software — will be held in October 2018 in Leeds.


Raspberry Pi 6th birthday weekend — Leeds Raspberry Jam

Raspberry Pi is 6 years old this weekend and there are #PiParty events going on all around the world. I went to the Leeds Raspberry Jam party at Swallow Hill school in Armley/Wortley run by Claire Garside of Foundation for Digital Creativity and her fab team.

There were all kinds of things to do: programming Minecraft with Raspberry Pi and PiTop cases, robot wars with the Crumble Controller, Raspberry Pi tutorials with Scratch, and a live web competition with Raspberry Jams from Manchester, Hudderfield, and Hull. The braniacs from UKSTEM were also there with their Control Freak activities. There was also Raspberry Pi cake!

Thanks to Premier Farnell (who are based nearby in Armley) people at the workshop could take home a copy of the excellent book Adventures in Raspberry Pi by Carrie Anne Philbin — 9 awesome Raspi projects. There were lots of other magazines and resources there to take and borrow and of course many different people of all ages to discuss projects with; this is one of the great things about Raspberry Jam events.

Programming the Crumble using a block editor

I tried my hand at programming one of the 2-wheeled drawing robots powered by the Crumble Controller, a tiny microcontroller a bit like a micro:bit that lends itself to physical computing applications. I was interested in the experience for a complete novice (although I have 20 years’ experience of programming commercial software, I had not before today programmed using a block-based editor). I wanted to see what the block-based approach feels like, particularly as we’re expecting to use block-based programming for our CodeMill training programmes in the near future.

The code-test-fix cycle s very rapid. To “run” the code, you simply press Play in the Crumble editor and it squirts the code down to the Crumble robot in half a second and the robot starts moving. This makes for a nice, rapid feedback loop for code changes.

Block editor for Crumble Controller

The constraints of the block editor make for very rapid decisions about what algorithm is possible to use to achieve a goal. In this case, we were trying to draw the Raspberry Pi logo (a raspberry) using a whiteboard marker pen held in the robot chassis. I found that — compared to learning a full new language — the pre-defined blocks really help to constrain the “search space” for a solution and helped me to focus on the problem rather than worry about syntax and language features.

In the absence of any test-driven features, I began with some simple robot movements to assess how the robot moved (it turned out that the wheels slipped a bit on the whiteboard surface, so we had to compensate in code). After a while, though, I found that the program had become difficult to read and I really missed both comments and (more importantly) the ability to define functions or methods to structure the code. I think that encouraging clean code early on is key to success with coding, so I’m looking forward to using other block-based editors (like MS MakeCode) that support constructs like functions. In the end, my Raspberry Pi logo was reasonable (could be better!):

Drawing a Raspberry Pi logo with a Crumble Controller robot

The enthusiasm and excitement around Raspberry Pi, micro:bit, Crumble, CodeBug, and similar small computing devices is really remarkable. In the 6 months since we’ve been running CodeMill digital skills meetups, I’ve been really impressed with how accessible these devices are to such a wide range of people. It’s a refreshing change from the world of business software systems! Hats off to Claire Garside and her team for a great #PiParty.

Raspberry Pi cake!

For future Leeds Raspberry Jam events, see Eventbrite or Twitter.

For future CodeMill digital skills events, see Meetup.com and the CodeMill website.