Frequent releases reduce risk

This post expands on a train of thought initiated by Dan North in his talk “Kicking the Complexity Habit” at NDC London 2014.

“Frequent releases reduce risk” – this is something you hear all the time in conversations about Continuous Delivery.  How exactly is this the case?  It sounds counter-intuitive.  Surely releasing more often is introducing more volatility into Production? Isn’t it less risky to hold off releasing as long as possible and take your time with testing to guarantee confidence in the package?

Let’s think about what we mean by risk.

What is risk?

Risk is a factor of the likelihood of a failure happening combined with the worst case impact of that failure:

Risk = Likelihood of failure x Worst case impact of failure

Therefore an extremely low risk activity is when failure is incredibly unlikely to happen and the impact of the failure is negligible.  Low risk activities also include those where either of these factors is remarkably low such that it severely reduces the effect of the other.

Playing the lottery is low risk – the chance of failing (i.e. not winning) is very high, but the impact of failing (i.e. losing the cost of the ticket) is minimal, hence why many people play the lottery.

Flying is also low risk due to the factors being balanced the opposite way. The chance of a failure is extremely low – flying has a very high safety record – but the impact of a failure is extremely high.  We fly often as we consider the risk to be very low.

High risk activities are when both sides of the ratio are high – high likelihood of failure and high impact, for example extreme sports such as free solo climbing and cave diving.

Large, infrequent releases are riskier

Rolling a set of changes into a single release package increases the likelihood of a failure occurring – a lot of change is happening all at once.   

The worst case impact of a failure includes the release causing an outage and severe data loss.  Each change in a release could cause this to happen.  

The reaction to try and test for every failure is a reasonable one, but it is impossible.  We can test for the known scenarios but we can’t test for scenarios we don’t know about until they are encountered (“unknown unknowns“).   This is not to say that testing is pointless, on the contrary it provides confidence that the changes have not broken expected, known, behaviour.  The tricky part is balancing the desire for thorough testing against the likelihood of them finding a failure and the time taken to perform and maintain them.

Build up an automated suite of tests which protect against the failure scenarios you know about, and each time a new one is encountered add it to the test suite.  Increase your suite of regressions tests, but keep them light, fast and repeatable.  

No matter how much you test, Production is the only place where it counts.

Small, frequent releases reduce the likelihood of a failure

Releasing often, containing as small a change as possible, reduces the likelihood that the release will contain a failure.

There’s no way to reduce the impact of a failure – the worst case is still that the release could bring the whole system down and incur severe data loss, but we lower the overall risk with the smaller releases.

Release small changes often and reduce the likelihood of a failure and therefore the risk.

Book – "Build Quality In"

I’m extremely happy to announce that I’ve been asked to contribute to a new book about Continuous Delivery and DevOps called “Build Quality In”.  The book is being collated and edited by my LondonCD and PIPELINE conf colleagues Steve Smith and Matthew Skelton.  We’re going to be donating 70% of author royalties to the awesome initiative Code Club as our way of giving back.

It’s going to be a collection of experience reports, including the successes and failures of many teams and projects – there will be much to share and learn!  

The book will be released continuously (hah!) via LeanPub and you can register your interest here: https://leanpub.com/buildqualityin

Versioning

@AgileSteveSmith hah! It would probably say “Don’t, or try not to”. Although it varies by what you’re versioning.

— ~/developers/chris (@ChrisAnnODell) April 30, 2014

Versioning is hard, so why do we do it?  To enable consuming apps to resist change.

What if these apps were built to be tolerant of change? What if you built your API or library in such a way that you avoided breaking the contract, but added to it? What if you constantly push changes and consumers constantly consume them?

What would you need versioning for now?

Agile on the Beach – Day 2

After the first day of Agile on the Beach I had a restful sleep in the excellent student accommodation.  The next morning started with a tasty English breakfast provided by the campus kitchens.

The second day of the event was kicked off with a second keynote speaker, Gabriel Steinhardt, about his take on Marketing Driven Product Management.  The talk started off very well, with an overview and definition of the Product Owner role and where Gabriel sees it fitting into product development – it is indeed true that in many places the role lacks definition.

http://agileonthebeach.com/2013-programme/2013-photos/img_3368/

Gabriel then spent some time discussing where the role fits in a classic hierarchical company structure, followed by what seemed like advocating for the Software Development Team to be removed as much as possible from clients and even decision making related to the product.  This all felt a bit too “command and control” for my liking – he seemed overly concerned with putting people into boxes.  It was at this point that his talk began to become controversial – in an agile conference with a stream aimed at Developers and another at Teams, his points felt incongruent to the overall feel.  Though, as Alan Kelly stated, a controversial keynote is an excellent way to get people thinking. It’s good to break the effect of the echo chamber now and then, and I appreciated Gabriel’s points about Product Owners, but we’ll have to disagree on the role Developers should play.

After the Keynote I attended Steve Freeman’s talk Fractal TDD. This turned out to be the same talk I had seen presented at Devs in the Ditch. Regardless, as with all forms of learning, repetition is extremely helpful in assimilating new information and I appreciated the recap.

Seb Rose was up next in the Software Craftsmanship track with Good Test, Bad Test.  Seb has six attributes he feels define a good test and he backed these up with examples. A very good talk although I disagree slightly on one or two small things, but these are personal niggles and will need a blog post of their own.

http://agileonthebeach.com/?attachment_id=1110

Lunch was once again a range of sandwiches and a short session by Tanya Krywinska who was appealing to the general community for feedback and suggestions on a range of Games Development degree courses she intends to launch. I felt that some of the audience had forgotten what it was like to be at university as they made statements that the university fees alone should be enough impetuous to fully engage students in group work. I distinctly remember money and fees being a “future problem” that “future me” would resolve (and 10 years later that future is nearly here as my loan dwindles) and group work being something fraught with egos and procrastination.

I suggested regular 1-2-1s to highlight any group issues, although I conceded that this may not be practical. Also, regular demos, as in Scrum, could help maintain focus.

For the rest of the day I decided to leave the Software Craftsmanship track and saw Judith Andersen’s talk. This was probably my favourite talk of the event. Judith explained how, when groups grow, they reach certain numbers which cause a change in the dynamics – increased channels of communication, the formation of cliques, etc.  She included her tactics for tackling and overcoming these problems, which are a function of our human nature, and dispelled some myths. The incorrect assumption that talking about feelings is unprofessional being an extremely important one. I highly recommend watching the video.

Finally, I stayed on the Teams track and saw a talk enticingly entitled The “Just Do It” Approach to Change Management. Unfortunately I could not maintain my attention during this presentation. I don’t know if this is a reflection on me and how tired I felt or the speakers. They had attempted to do a kind of double act where they bounce jokes off each other, which I always feel is so difficult to get right that it mostly ended up feeling awkward.

All in all, it was a good conference. It was small, friendly and with interesting talks. The organisation was good too – many events forget to add a few minutes between presentations and they soon begin to go off schedule as laptops must be setup and attendees move from room to room.

I would also like to than Alan Kelly who badgered me into submitting my presentation – I honestly didn’t think people would consider it worthwhile but I’m happy to have been proven wrong.

I hope to see everyone again next
year on the 5th & 6th September.

Agile on the Beach 2013 – Day 1

This is the first time I’ve attended Agile on the Beach and I feel it was a very successful event.  There were three tracks, Software Craftsmanship, Teams and Business.  I almost exclusively attended the Software Craftsmanship track and a couple from the Teams track.

https://secure.flickr.com/photos/papyraceous/4376948144/

The event kicked off with a keynote from Dan North.  He explained his view on mastery – a progression from apprentice and journeyman with the defining characteristics of each.  Dan ties his talk together with a story of his own journey to the mastery of a particularly difficult origami fold called the Jackstone – a fold he attempted as a child, but failed to master until decades later.

Jim Barrett had the first slot in the Software Craftsmanship track and he was unfortunately beset by some technical difficulties.  After the initial hiccups he dived into giving an overview of Clojure.  I haven’t done anything in the language before, nor have I tried anything in Lisp which it is based upon and so was interested in learning of its power.  Unfortunately I feel he spent too much time on the syntax.  I personally don’t get much out of watching people code simple snippets on-screen.  I realise this isn’t very constructive feedback.  Maybe it would have worked better as a workshop with a Koans approach or with some direct comparisons between Clojure and Java code to show the advantages and differences.

(negative) feedback

Marcin Floryan was up next with a presentation focussed on feedback and how important it is to collect, review and act upon relevant feedback you can gather about your system.  An enjoyable presentation with a dash of humour.

Lunch was a variety of sandwiches, nothing particularly special, but nothing bad either – vegetarian options were well represented and there was plenty available to ensure you got your fill.  I know I’m commenting on food, which may seem inconsequential compared to the presentation content, but I feel it’s an important part of keeping up the stamina and morale of all attendees and speakers.

After filling our bellies James Lewis had the difficult after lunch slot but he managed to keep us interested with an overview of how systems built as microservices can create highly reactive and flexible ecosystems.  This is essentially how the architecture is designed at 7digital – small, focussed internal HTTP based services supplying functionality for their bounded contexts.  We’ve found it to be highly successful and it was good to see it being presented.

I took the stage next, hiding my nervousness by cajoling the audience into a Mexican Wave, a silly thing to do, but it made the distance between us feel smaller.  I believe my presentation went well and I fielded many questions, some of which I am now finding to be repeated each time I give the presentation and as such I must find ways to incorporate the answers into my slides.  I’ve got answers to some previous questions asked listed on a blog post here.

I’m afraid that I didn’t attend the final session as I was too amped after my talk (apologies to Phil Nash) – I’m still getting accustomed to speaking and I find that it can knock me sideways once the adrenaline wears off.  I hung around in the communal area, grabbed some coffee and wrote up some notes for the day.

The day was finished up with a few Lightening Talks of which the highlight was a method for visualising problems and obstacles, which I believe the person called The Mercado Technique, but I must have heard wrong because I can’t find any sources of this on Google.  If anyone managed to get the proper name, or the name of the person who presented it, please let me know. Update: @AnthonySteele informs me that it is The Mikado Method and @EwanMilne let me know that @facilligent had presented it.

https://twitter.com/Agileonthebeach/status/375701598535954432

The day wrapped up with a Beach Party which included a free pint of the local ale and a hog roast (veg burger option too).  The British weather let us down a little and it was slightly cold and windy, but nevertheless the sunset was beautiful and the conversations were interesting.  A good first day.

Slides and videos from the event are being added here.

Presenting at Agile on the Beach

After some reassurance from my friend Alan Kelly, I submitted my experience report on Continuous Delivery to this year’s Agile on the Beach.  To my surprise and delight I’ve been accepted!  This will be my first full scale conference as a speaker and I’m very excited and nervous – I hope I can finish the day having inspired at least one person.

Agile on the Beach is a two day business and technology conference taking place in Falmouth on the 5th and 6th of September.  It’s on the Cornish coast and from what I’ve been told the weather is great and there will be a fantastic beach party on Falmouth’s famous Gyllyngvase Beach.

The conference includes three strands of agile adoption – Software Craftsmanship, Business Strategy and Teams and I’ll be presenting in the Software Craftsmanship stream.  The full list of speakers and a schedule are up on the site.

I can also let you know about an offer of 10% off your ticket at Agile on the Beach using discount code SGUEST13 when booking in via Eventbrite – tell them I sent you 😀

Early bird tickets are available until the 31st of July at £265. Accommodation is also available to book on site at an additional cost.

To book tickets to Agile on the Beach visit http://www.eventbrite.co.uk/event/5135380060 and follow them on Twitter @Agileonthebeach / #agileotb.

Presented at SyncIpswich

Following on from the success of SyncNorwich, Carl Farmer has set up SyncIpswich – a regular event for technologists, creatives, entrepreneurs and graduates to meet up and talk in with the aims of growing the community in Ipswich.  Paul Grenyer recommended me to Carl as a speaker and after letting Carl know that I’m not proficient at speaking (yet) I agreed to come up and give my presentation on Continuous Delivery at 7digital.

Despite fighting with the traffic in Ipswich town centre I made it just in time and spoke in front of a crowd of roughly 60 people.  As before, my slides were done in roughly 15 minutes and I fielded questions from the audience for about another 15 minutes more.

After a short break I was followed by Richard Astbury giving an introduction to the Azure platform where he deployed an empty MVC App from his laptop and then a simple Hello World node.js site from his Raspberry Pi at home, which was rather impressive and demonstrated how smooth it can be.

We then gathered at the nearby pub where we broke into a few discussions about the advantages and disadvantages of feature branches among other things and I admired the view of the boats in the marina before I left for the nearly 2 hour drive home.

I had a great evening and it was good to talk to people outside of London and once again be reminded that we don’t have the monopoly on smart, inquisitive, talented developers doing great things.  Thanks to Carl for arranging it and Paul for recommending me.

2012 Retrospective

As all Agile methodologies teach us, the action of looking back and reviewing your progress is an essential part of improvement. As such, I’m going to try and run a simple retrospective for my 2012.

Review

Lets start by reviewing the last year on a timeline. As it’s such a long period I’ll stick with monthly increments and pick out notable events.

January: 
 – Discovered WebGL and my messing about got picked up by LearningWebGL.com

February: 
 – Nothing of note 😦

March:
 – Attended first GDC Meet a Mentor event
 – Started planning the “Devs in the ‘ditch” events

April:
 – Organised a successful first “Devs in the ‘ditch” event
 – Organised the 7digital stand at the “Find your Ninja” event.
 – Attended GeekGirl Meetup in London

May:
 – Organised and helped man the 7digital stand at Silicon Milk Roundabout
 – Attended the Progressive.Net Tutorials

June:
 – Organised second “Devs in the ‘ditch” event

July: 
 – Became a STEM Ambassador

August:
 – Nothing of note 😦

September:
 – Organised third “Devs in the ‘ditch” event
 – Stepped up to take over the ACCU Mentored Developers from Paul Grenyer and thereby co-opted into the Committee.
 – Kicked off an ACCU Mentored Devs book group on JavaScript: The Good Parts
 – Attended DDD10

October:
 – Organised and presented at the fourth “Devs in the ‘ditch” event.
 – Presented the same talk at ACCU London
 – Became the API Team Lead Developer

November:
 – Took part in a Year 9 Careers Speed Networking event as part of being a STEM Ambassador
 – Presented to undergraduates at the Middlesex University IT Careers Forum
 – Passed Grade 1 of Cello

December:
 – Presented at APIDays 2012 in Paris

Other Stuff:
 – Adopted a lovely Cat
 – Attended at least 18 events, and spoke at 3.
 – Attended 4 Weddings (one of which was a surprise)
 – Lost just over 10lbs in weight and no longer officially overweight
 – Visited Portugal, twice, and Paris.
 – Finished reading 5 books, and started at least twice as many.
 – Wrote 12 blog posts
 – Created 13 Github Repos

Good / Bad / Change

Now is the part where I reflect on the year, using items that I brought up in my review as an aid and write down what I felt went well, went badly and what I’d like to change going forward.

Good

– Finally started speaking at community events, I’d been wanting to do so for so long, but was afraid
– Attended many events and conferences
– Improved my overall health 🙂
– Began organising events and learned a lot from this
– Began putting myself forward as role model to younger people as part of the STEM Ambassador work

Bad

– Didn’t read or finish as many books as I’d have liked

– Didn’t really travel or visit many places

– Only wrote a few blog posts

– Didn’t finish any programming projects I started

– I wanted to have done more with WebGL

– I seem to have coasted through the first quarter of the year

Change

– Must commit to projects and finish them before starting new ones
– Must commit to finishing reading books that I start before starting new ones
– Try to read more books
– Blog more, it improves writing and communication skills
– Stop procrastinating!

Goals & Actions

Normally the team would vote on which topics they’d like to promote to goals and actions but as it’s just me I’ll pick three that I feel are the most important.

Goal: Make 2013 The Year of Reading
Action: Read and finish at least one book a month.  Preferably a technical book but any kind counts. I’ve put the GoodReads Challenge in my sidebar as a reminder.

Goal: Present and speak more.
Action: Volunteer for more events. I did three last year, I’ll aim to improve on that.  I’ve already put myself forward for an event with the London Continuous Delivery group in March

Goal: Visit a new country
Action: I’ll make a point this year to take holiday somewhere that I haven’t been before.  It doesn’t have to be far, just somewhere new to me.

Retrospective Close

I feel that this was indeed a useful exercise.  It took a couple hours to do and write up mostly because a year is a long time period and I wanted to go back through my calender and emails to ensure I picked up as many events as I could.

Looking back I can say that that I’ve both done a lot of things, but also not enough things.  I picked up new items such as speaking and becoming more involved in the ACCU, but I also let things slip such as blogging and reading.  It’s so easy to let things slip by you when they happen one day at a time.

I’m hoping that 2013 will continue along the trend that I started as there is so much that I want to see.  At the end of the year I will run another retrospective and compare it with the actions above, which should be interesting!

Group Feedback

Cross-posted from the 7digital Dev Blog

The API Team decided to trial a Group Feedback in our last Retrospective influenced by this post from Mark Needham – we were hoping to promote a safe atmosphere for everyone to talk about each other in a frank manner.  Initially the idea was received with trepidation and a fear of public humiliation, but we were willing to try a new approach.

Hibri, our Team Lead, suggested that we should present our feedback as three points in a similar vein to the “Start, Stop, Continue, More of, Less of Wheel” but sticking to just Stop, Start and Continue.  This would focus the feedback and prevent any potential for the retrospective from spiralling off course.  The team took a vote on whether to try this approach before starting.

The ‘Subject’ sat on a chair, called the Hot Seat, facing the team whilst everyone else had 5 minutes to jot down on three cards an item for that person to Stop, Start or Continue.  The cards were then tacked onto the whiteboard behind the Subject.  Everyone took their turn in this manner as the Subject and afterwards we got a chance to read the points suggested and comment if we wish. The original plan was for the team to read out the cards to the Subject, but we decided against that and reviewed the feedback as a group.

We found that there were overall themes for each person and it was felt that nothing on the board was a complete surprise to anyone.  This may have been due to it being the first time we’ve tried this as it was noted that it was harder to write the cards than be the Subject being assessed.  As expected everyone had areas they could focus on more and areas where they were strong.  Each person was encouraged to create their own personal actions from the feedback, which was not divulged to the team.

We also found, whilst reviewing the cards, that we had a couple of common themes across the team, and we decided to rearrange the cards and group them up. This showed that the team felt we were focussing really well on Refactoring, but that we needed to address Pairing and Communication (as well as being late for standup…).  We discussed the cards further, noting the overall themes and devised a couple of actions;  Pomodoro techniques whilst pairing and Bi-Monthly team “Show-and-Tell” sessions for anything that needs communicating, such as major refactorings undertaken and any lessons learned.

The exercise turned out to be very useful and was a different way to find areas within the team as a whole which needed attention.  Also, we were focussing on ourselves and not our output, our processes or our environment as per most retrospective exercises and everyone received positive along with any negative feedback.