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).
Video:
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.
Video:
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
Video:
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.
Video:
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
Video:
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.
Video:
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
Video:
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!
