(London .NET User Group – 24/02/14)
On Monday, Gojko spoke a little about his experience with continuous delivery and how continuous delivery can have a transformational impact on the way that you do business.
If I had to boil down this talk to two key ideas, they would be to
- have feedback loops in your software wherever you can
- use shipping/deployment as (what Econometricians would call) a “natural experiment”
These are of course fairly well-worn ideas (the Google spellchecker is a classic big data feedback loop example). Natural experiments were apparently used in the 19th century (Wikipedia to the rescue).
Still, there were a lot of interesting specifics here and Gojko himself summarized the main points he made as:
Don’t surprise users
Users still need to be able to perform their tasks easily: They should be allowed to gradually opt in to new functionality (the example here is the classic google path of announcement, opt-in, standard with opt-out, dropping the opt-out).
However, beyond this users should also expect UI consistency. You should not be shocked into new versions. On UI design in general, he mentioned a very interesting-sounding book called “Usable Usability” which I hope to have a look at (in the fullness of time. There is just too much reading to do!).
Don’t interrupt sessions
Here, he used the examples of Adobe reader and Windows updates which both force you to update at a time that is convenient for them and not for the end user. In particular, he explained how continuous delivery for websites here has a strong effect on multi-versioning: If you do do continuous delivery, you will need to support multi-versioning or you will break existing users sessions.
Both of the first points deal with a funny (but I think common) scenario where there is technical capability to have continuous delivery, but no business desire for it. What you end up with is, as he put it (using the Scumbag-Steve meme), “continuous delivery to staging”. This is probably worse than no continuous delivery at all!
Start at the top and build up the backend
He called this the “skeleton on crutches” after the slightly more famous “walking skeleton“. Again, the examples he used where website based where he implemented the UI first and implemented an extremely thin Email-based-backend of a feedback button using Jotform. Personally, I think the difference here to a walking skeleton is marginal, but I guess the emphasis is on delivering user value quickly
Learn from shipping
One of the most interesting points, here, he made was on the importance of measuring achieved user value (and how this feeds into future development):
If nobody presses the feedback button, then you get rid of it rather than investing in an expensive backend system.
For more enterprise-y systems he recommended having KPIs (“e.g. minimize time taken by user to order something”) for what you want to achieve in general. Scoring each user story against the KPIs (“makes task x 20 seconds quicker to achieve”) and then measuring (in production!) against these. This kind of feedback loop allows you to see whether what you did is actually worthwhile and where you should expend effort in the future.
All in all a very worthwhile talk!