2014 Retrospective

At the end of 2012 I performed a simple Retrospective of the year.  I seem to have neglected to do one at the end of 2013 but it shall be a yearly habit from now on.

Conferences attended:

Presentations:

Published:

This is a big achievement for me personally.  Thank you to those that made it happen.

  • Joint Contributor with Paul Shannon in More Agile Testing by Lisa Crispin and Janet Gregory
  • Contributed a chapter to Build Quality In – the collection of Continuous Delivery and DevOps stories edited by Steve Smith and Matthew Skelton
Personal:

  • Co-organised my first conference – PIPELINE 2014!
  • Went skiing for the first time
  • Started Portuguese lessons
  • Took Cycling Classes and Bicycle Maintenance classes
  • Continued my Cello lessons (aiming for Grade 3 this spring)
  • Attempted the Computer Networks Coursera course and achieved a grade of 47%. I’m proud of this score as it was a pretty intense course.
  • Stepped down from the ACCU committee as I could no longer devote the proper time to it.
  • Only managed to finish reading 6 books when I’d hoped to read 18.
  • Donated blood 3 times before being temporarily suspended to investigate anaemia 😦
  • Sadly, I still have limited proficiency with the Portuguese language

Changed Jobs
In August I left my role at 7digital, I job and company I loved and spoke about, after 4 years of being with them.  I wanted to try a new challenge.  I know it sounds corny, but I really did.  I wanted to see if I could take all the things I’d learned there to somewhere new, share my knowledfe and learn even more.
I took up a Senior Engineer role at JUST EAT and it’s been great.  I’ve had much to learn and as a result have been battling my own Imposter Syndrome, but I hope I’ve been making a difference, even a small one.

Next Year

I plan to get back on top of my reading, blogging and neglected fitness – the usual stuff.

Having left 7digital in August I now longer feel comfortable presenting about the experience report about their journey towards Continuous Delivery.  Change happens there every day and I am no longer able to ‘finish’ the presentation with details of what is currently being achieved.  There are still many things I could talk about from that time though, possibly distil the learnings into something more transferable, but I believe the audiences enjoyed hearing a real life experience report.

Creating a new presentation is top of the list and I’m open to ideas and suggestions.

Conclusion

Once again I’ve achieved more than I thought – a year is a long time and we regularly fail to remember anything other than recent events.  This feeling has been compounded by my focus in the latter half of the year being centred almost exclusively on my new role at JUST EAT, which is to be expected.  A new role is challenging with a new codebase, domain, terminology and people to learn about, which is exactly what I was seeking, so I’m happy!
Here’s to 2015!

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

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.

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.

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.

Team Transformation Presentation for London Continuous Delivery Group

On Tuesday 19th March I gave a short presentation on the steps 7digital took to transform our team in order to facilitate Continuous Delivery.  This was held at Skillsmatter for the London Continuous Delivery group.  I also managed to rope in a few of my colleagues for a discussion panel after my short set of slides

I’m really grateful to Hibri, Goncalo, Matt and Rob for coming along as I felt that having more than just my voice would add to the credibility of what I said and it would also be more interesting.

You can see the video on the Skillsmatter site and these are the slides.  James Betteley also posted a running commentary of the event where you can read some of the discussion which took place.

//speakerdeck.com/assets/embed.js

APIdays 2012

On Monday 3rd and Tuesday 4th December Paris held host to the first international API focused event in Europe – APIdays.io.  Myself, and my colleague Hibri, eagerly took part and we gave a short presentation on how 7digital grew their public API, the lessons we learned and the effect it had on the way we work.  You can view the slides at the end of this post.

We received great feedback from our slides – it felt as if many people are just getting started in the world of APIs whilst 7digital have had their public API for many years and that they were very interested in hearing our real-world story.

The format of the event was a little odd, with talks in slots of less than 30 minutes, which on the plus side meant that we got to see a lot of different viewpoints and experiences but that there wasn’t enough time for anyone to get deep into a topic.  I’d like to suggest that a technical track has available 1 hour slots for anyone who wants to host a full-on technical presentation and debate – it felt like we barely scratched the surface in less than 30 minutes.

It was a great couple of days, and the first time I’d ever been to Paris.  I’m hoping that this event becomes a regular conference and that next time we can get far more technical with the content and swap the really gritty stories of lessons learned.

//speakerdeck.com/assets/embed.js

Questions from my Continuous Delivery Talk

My short talk on how we do Continuous Delivery at 7digital generated many questions from both the audiences at Devs in the ‘ditch and London ACCU.  Also, a couple more were asked on Twitter after the events.  Here are are the ones I can remember and my answers.  If anyone has any more questions please add them to the comments.

Can you choose which release version to deploy?

As we deliver web-based services, not products, we are always aiming to release the latest version which is almost always the of HEAD of the Master/main integration branch merged into a Release branch.

We rely heavily on TeamCity to trigger our deployments as well as our continuous integration.  It includes a feature called ‘pinning a build‘, which prevents it or it’s artifacts from being deleted in a clean-up policy.  It also allows us to reference these artifacts in another build, such as a deployment build.

Once the Release branch has been updated with the changes in the HEAD of the Master branch, and all of the tests have passed and we are happy, the build is ‘pinned’ in TeamCity and we kick off the Deploy to Live  build which picks up the pinned artifacts and deploys them to the production servers.

We can choose what build should be pinned and therefore what artifacts are released to Live.  We don’t necessarily version our releases because we never refer back to the versions and only a single version is ever live at one time.

How do you do a rollback?

We ‘un-pin’ the build and artifacts of the ‘bad’ release, ‘re-pin’ the build and artifacts of the previously known ‘good’ release and run the Deploy to Live step once again.  This effectively does a ‘roll forward’ with known good artifacts.

What role do QA have in the process and do they trust the automation?

QA are generally involved throughout the process.  Together with the Developers we will both fulfill the traditional role of a BA and analyse a piece of work, creating Acceptance Criteria which normally form the basis of the Automated Acceptance Tests.  Also, this means that QA are fully versed in the feature or change when it comes to UAT and explanatory testing and together we can make a judgement call as to whether a change actually needs QA manual testing or is sufficiently covered by the automated tests.  Being involved all the way through gives them confidence in the process.

A point to make is that we don’t have a QA Team as such, each development team includes a QA person and a Product Manager.  We all sit together and attend the daily stand-up so everyone is aware of what is taking place, the mood of a change and can jump in at any point.

How do you handle large features/pieces of work?

We hold an analysis session within the team, including the developers, QA and Product Manager to break down the work into as small a user story as possible, aiming for under a day.  Each story needs to be a single contained piece of the functionality which can be released on it’s own.  This is not always possible and in these times we employ Feature Toggles which will hide a feature until it is ready.

What we don’t do is have feature branches.  This is something that must be avoided to ensure that we are always integrating all changes and any problems are highlighted as early as possible in the development cycle.

What about database schema changes?

We use a tool we developed internally, but have since Open Sourced: DBMigraine.  There are a couple of blog posts on the 7digital Dev Blog here and here which explain it in more detail, but in essence it builds databases from a set of creation scripts applies migration scripts, and performs consistency checks between databases.

Using this tool we build a database from the scripts and migrations at the beginning of each Integration test suite and run the tests against the new schema.  This should hopefully flag up any major problems before these migrations are also applied to the Systest and UAT databases which are integration points for all of our apps sharing the same database.

It’s worth noting that we try to avoid destructive migrations, but this process has allowed us to gradually delete unused tables in a tested manner.

————————————–
Edit – new Question from @AgileSteveSmith

What cycle time reductions have you seen?

In my reply, I linked Steve to the following two posts on the 7digital Developers’ Blog related to productivity at 7digital: “Productivity = Throughput and Cycle Time” & “Development Team Productivity at 7digital“.

The posts illustrate, with data tracked from our own work items, that there was an incredible reduction of Cycle Time in over the course of 2009 to 2011 – you can even see the massive spike at one point where things got worse before they got better, as I mentioned in my presentation!

A full report was put together, with even more charts and graphs, which can be downloaded from the second blog post.

Continuous Delivery at 7digital

It began with an off-hand comment on the ACCU General mailing list that at 7digital we release on average 50 times per week, across all of our products.  I thought nothing of it, virtually all of our products are web-based, which makes it relatively easy to deploy on a regular basis, but it seemed that others were interested in how we do it and so I was cajoled into giving my first presentation.

I began by explaining what we understand as Continuous Delivery – a set of repeatable, reliable steps which a change must go through before being released.  In our case most of these steps are automated.

I described where we came from and how we approached the change, in both a technical and business manner, and where we would like to see ourselves going.  I then included a flowchart of  A Day in the Life of a Change at 7digital, which Prezi allows me to ‘bounce’ around as we hit different stages in the pipeline.

I answered many questions clarifying how we handle rolling back a bad release (we actually ‘roll-forward’ with artifacts of the previous ‘good’ release), whether our QA team are comfortable with the process (yes, they help write the criteria),  and how large pieces of work are tackled (we try to break them down into deployable pieces no bigger than a day).

Here are the slides:

http://prezi.com/bin/preziloader.swf

Group Feedback

Cross-posted from the 7digital Dev Blog
Whiteboard with Group Feedback cards arranged showing Pairing and Communication as the biggest groups

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.