Agile Cambridge 2012 Aftermath

An event full of discovery, psychology, therapy sessions, learning, juggling and lots more fun, that in a nutshell was Agile Cambridge 2012.! It was great to meet old friends and new as well as sit in on some great sessions. Here are just a few of my personal highlights from the conference.

Cynifin - dealing with uncertainty

In hindsight there was a theme of “dealing with uncertainty” running through the conference, but I guess when that is the consistent thread in our lives then its hard to get away from that pattern anyway.

This is the first time I managed to see Dave Snowden (@snowded) talk about his Cynifin model for dealing with uncertainty and it was worth the wait. Whilst I have seen several people talk about Cynifin before, Dave really conveys the value and importance of the model like no other.

Cynefin is a Welsh word that means “the place of your multiple belongings”. Essentially it refers to the fact that there are thousands of things in your experience that influence your understanding and you can never be fully aware of them or their affect.

Humans evolved to make decisions very quickly as tigers tend not to wait for a project budget before they eat you. We are therefore very good at making decisions based on partial requirements and past experience. We also focus on the negative as unfortunately avoidance of failure is more attractive than following success.

Cynefin is a “sense making” framework to help you understand and manage complex and complicated situations. Dependent on which of the four domains you are in, simple, complicated, complex & chaotic defines how you should think and analyse the situation.

In a simple domain then you can easily categorise the situation and deal with it appropriately. A software development team is rarely a simple domain and tends to fluctuate between complex and complicated domains, driven by the unpredictable nature of the businesses they support.

The Cynefin model looks a great way to think about the situations I am in and its a big take away to try and apply it to my working practices.

Cracking your big rocks

Some tasks seem to us to be so out of our scope, so unfamiliar or painful to do that we will do anything else to avoid doing them. These tasks that become unmovable and intractable in our minds and cause us to waste too much time thinking about not doing them. These are our Big Rocks!

Cracking your big rocks was another example of a great coaching session, specifically to help us break down some ones big rocks.

Assembling in groups of 4, one person had a big rock, two were coaching and one had a deck of big rock cards. The coaches helped the person understand the challenge of their big rock and encouraged them to find ways that they could start to break it down. The cards were used to help shape the coaching discussion or highlight concepts the coaches raised. Cards covered techniques for framing the problem, keeping rolling, saving progress as well as anti-patterns.

My Rock

I was the person with a big rock, mine was writing a book (although much applied to other writing too). I never seemed to have enough time to write the book, was overly concerned about quality and had many other personal and professional tasks pulling me away from the book writing. The coaches helped me break down the challenge, so rather than writing chapters at a time I started to focus on sections in a chapter. A section could be done in an hour or less and I could give myself a micro-break and decide whether to continue or re-prioritise.

I’ve never seen Johanna Hunt and Simon Cromarty talk before and was really impressed with their session, the way they bounce the conversation between themselves and the audience was really engaging.

Coaching techniques

Leaning to be an effective coach is very challenging so its great to learn new techniques to help. Using the simple props of juggling balls, we coached each other in how to juggle

Where no one in a group had any experience of juggling, it was a case of the blind leading the blind. In this situation one group decided to gate-crash a few other groups, observing what they were doing and learning by figuring out where the juggling experience was.

Coaching someone to juggle is a great exampel of where experience of the skill can bring a lot of value to the coaching.

In my group, Simon and Nasim were pretty expert jugglers. Simon had no problem understanding what I should be doing to juggle, the challenge for him however was to coach me rather than teach me - two very different things with different results. By suggesting things I could try and encouraging me to thing about what I was doing I soon gained more confidence. Nasim was observing Simon coach me and at the end of my basic juggling session, he gave feedback on what he saw.

When Nasim was coaching Simon he was a bit taken aback by Simon’s level of skill and wasnt sure how to coach him as he was already doing so well. However, by talking to Simon about his juggling technique he was able to relate to him better a juggler of equal skill. Also asking Simon what he wanted to achieve from the session helped set a goal for Nasim and Simon to get to, framing the session nicely. In this case Simon wanted to learn to juggle with 4 balls, so Nasim encouraged Simon to understand his technique so he could build on it and find a way to achieve his goal.

When it was my turn to coach, I encouraged Nasim to vary his technique, to go back to basic principles and to gradually introduce more balls into the mix. I typically asked lots of simple questions about juggling to prevent Nasim from over-thinking the task. I also asked emotional questions, such as which technique feels better, to gauge if I was helping Nasim keep in a positive state of mind.

By asking us to coach someone in a technique that we were not familiar with was a good way to practice our core skills as a coach, especially our ability to assess the situation, listen and gain understanding of the other persons objectives. As an agile coach, it is very easy for the agile practices and mindset to dominate the conversation and activities, when doing something that most people were not used to coaching it really helped us get back to basics.

One Man Dan

It was great to hear from Dan North (@tastapod) again, he is always entertaining and thought provoking. Dan is embarking on his solo career and will be hitting 13 different events between now and the December holidays. His talk on embracing uncertainty complemented the opening keynote perfectly and highlighted how unpredictable software development is and why its wasteful to try create order. Dan discussed the real value that can be attained by accepting uncertainty and dealing with it gracefully.

In Summary

Conferences are a great way to discover new things as well as catch up with friends and make new ones. It was great to catch up with Dan North and find out about his new adventures, hear the agile coaching stories from John McFaden and meet Darcy D, another ex-thoughworker mixing UX development and agile coaching.

There were lots of sessions I didn’t get chance to see, so am looking forward to catching up with them on InfoQ soon.

Thanks to Mark Delgarmo and team for organising the event. Special thanks to Rally Software for sponsoring the social event on Thursday night where I had some great conversations, delicious food and a pint or three of Samuel Smiths beer!

Hope to see you all at Agile Cambridge 2013!

Thank you.

This work is licensed under a Creative Commons Attribution 4.0 ShareAlike License, including custom images & stylesheets. Permissions beyond the scope of this license may be available at @jr0cket
Creative Commons License

UK Developer Startup Wins Aussie Gold

Coding is fun, its also great if you make some profit!

UK developers lead by community expert Alan Parkinson recently formedHindsight Software, a start-up focused on bringing Behaviour Driven Development (BDD) to as wide an audience as possible. With their first product Behave for JIRA, they entered into the Atlassian Codegeist competition judged by Atlassian’s CEO Mike Cannon-Brookes. They scored a big win against a record number of entries in the annual competition.

Read More

Behavior Driven Development Coming to JIRA

Hindsight is a start-up company focused on building intelligent testing software that supports agile practices such as acceptance testing.  Using the Atlassian Marketplace to enable rapid development of their first tool, Behave for JIRA, they had a platform to quickly deliverer a valuable product to a large number of software teams around the world.

Atlassian competitions such as Codegeist showed Hindsight how easy it was to get started with plug-in development with JIRA and inspired the team to secure funding for their own product development.

Hindsight is passionate about software quality and is in the business of providing tools to help everyone in the software development team focus on quality of the delivered product.

Their first product, Behave for JIRA, brings acceptance testing to the wealth of Atlassian customers around the world and at a lower cost of entry into the market.  If successful the company will look to extend this service to the cloud.  In the mean time the Atlassian market place allows Hindsight to validate that their innovative solutions are valuable to the market before they make a major infrastructure investment

Behave for JIRA – bringing Acceptance Testing to all your projects

Acceptance tests allow you to express specific needs for your software product in a way that is testable and measurable.  It is also invaluable for breaking down the barriers in software development.

Behave for JIRA allows you to easily add acceptance tests to any issue in your projects.  Acceptance tests are written in a natural language, eg. English, but in a structured way so that those needs can be matched up to the software that is created to satisfy them.  In Behaviour Driven Development an example acceptance test would be:

Given _a specific situation
When _something occurs
Then _you will get a specific outcome

The most commonly used acceptance testing framework is called Cucumber and supports many different software programming languages.  Once you have defined you acceptance criteria with JIRA Behave, you can then run those tests with Cucumber to get instant feedback on you software development progress.

As this is a plug-in for JIRA, you can easily make use of all the data your projects and have a simple to use and powerful way to edit and review your test specifications.  This includes syntax highlighting editor for quick authoring of requirements & acceptance tests.

Developing products using Atlassian tools

As Hindsight have stakeholders with a vested interest in the success of the company, they make use of the Atlassian tool-set to ensure everyone is up to date with the progress of the software development.  Any non-technical people involved in the company can see the sprint burn-down charts and understand the status.  It is easy to see what is planned and what the development team have committed to and hold the team to account if they don’t meet the targets they set for themselves.

For the developers, using GreenHopper it was easy to see if things were going to over-run and a decision could be made quickly about re-prioritising the work.  As this all fed into a JIRA dashboard for the stakeholders, communication about progress was updated in real time.  When two new graduates were on-boarded, it took just two sprints to adjust their capability using GreenHopper to track and review progress.

The development team uses a Scrum-like approach, base on a two week iteration.  Using JIRA GreenHopper scrum template made set-up of the project as simple as defining a project name and pressing a few buttons. The team have also used the rapid board to manage their individual responsibilities so they can quickly priorities the features inside the sprint.

Hipchat provides an instant way for the team to to discuss challenges, especially when they are apart.  As Hipchat is also plugged into JIRA and their overall build process, any significant changes in the project get broadcast on the Hindsight Hipchat channel.  This immediate feedback from build servers, allows the team to quickly fix problems as they happen.

3 most valuable practices

1) Visibility to the business – stakeholders can see our commitments and easily hold us accountable

2) Distributed working is often a necessity and so having our up to date progress accessible anywhere there is an Internet connection is invaluable.  Using Distributed Version control also means we can work off line

3) In constant communication using Hipchat which also enables the team to see JIRA notifications on bug reports, issues re-opened tickets and other major events.

Head over to Atlassian to find out about their range of software for software developers and dont forget to checkout the Codegeist competition (ends 16th July 2012).
Thank you.

This work is licensed under a Creative Commons Attribution 4.0 ShareAlike License, including custom images & stylesheets. Permissions beyond the scope of this license may be available at @jr0cket
Creative Commons License

Dibi Conference Aftermath - Designers Get Coding, Developers Get Creative

Some conferences are huge, some are very social, some are highly technical. DesignIt, BuildIt was the most creative and moving of experiences I’ve had in a long while. It has really inspired me to add so much more creativity to my coding projects.

There were some amazing speakers at this years DiBi, split into Developer and Design tracks. I took the opportunity to delve into the design track and learnt so much more than I can capture in one blog. So here is the first highlight from what I felt were the most passionate speakers.

@seb_ly - Hybridify yourself

Seb Lee-Delisle opened the day by making is all think about the possibilities when you combine creative design with technology.

JavaScript has really evolved to be a highly productive tool, when coupled with graphics tools like Processing and WebGL some amazing games and animations can be created really easily. For examples, take a peak at, and

With these kinds of tools at hand, there is no reason designers and coders shouldn’t code their own creative works. Althought there is still a big gap between these two disciplines, even at the DiBi conference there was The valley of incomprehension, with most people defining themselves as either designers or developers. Seb encourages us all to be a bit more of a creative coder!

coder + designer == creative coder

Seb also reminded us how easy it is to code something creative, with just one line of code on a commodore 64 emulator. Taking this further with and 10 minutes of live creative coding in JavaScript, Seb created an eye-catching visuals that responded to mouse control and gravity.

Most coders get into it because they want to play games they create. Its much easier to create games than you think. When you get designers and coders working together it improves the communication and helps share skills. Designers discover much more when they learn to code. More importantly, working together helps share ideas; if designers and coders work together they can implement ideas in the easiest possible way.

Developers find the creative process hard, as many are too used to thinking literally. The more developers are part of the creative process, the more appreciation they will gain for it.

Developers should take the time to play with visuals more, start with small ideas and playing with tutorials to learn how to draw with code. By looking at the examples at communities like OpenProcessing it will help inspire coding towards more creative goals and help give software an experience that people have real affinity for.

In the next blog about DiBi12 I’ll cover Dan Ruben (Moo) and Cameron Moll. Both inspired in very different ways.

Thank you.

This work is licensed under a Creative Commons Attribution 4.0 ShareAlike License, including custom images & stylesheets. Permissions beyond the scope of this license may be available at @jr0cket
Creative Commons License

QCon London 2012 Aftermath - the Return of Dan North?

Talks at technical conferences can give a very detailed insight into new innovations, they be a great source of inspiration and motivation. Sometimes they even make you giggle.

At QCon London I got large doses of all of the above, thanks to Rich Hickey, Dan North (DWZ Trading), Colin Humpreys (Carrenza), Ade Oshineye (Google) and Patrick Debois (father of DevOps, working with Atlassian). Here is a summary of my experiences.

Read More

Developers Party Time at QCon London 2012

Talks at technical conferences can give a very detailed insight into new innovations, they be a great source of inspiration and motivation. Sometimes they even make you giggle.

At QCon London I got large doses of all of the above, thanks to Rich Hickey, Dan North (DWZ Trading), Colin Humpreys (Carrenza), Ade Oshineye (Google) and Patrick Debois (father of DevOps, working with Atlassian).As I didnt make the training days this year, I was sad to miss out on the tutorials by Simon Brown, Russ Miles and Rachel Davies which all looked great.

My favourite talk was definitely the “Cloud… so much more than a tool“ by Patrick Debois. Not only was it an interesting experience report on the realities of using Cloudy technology to build a highly scalable video broadcasting service, it was also the best use of LolCats I have ever seen… ever…

@jr0cket: @patrickdebois has the best cat based slides ever - even better than @swardley which is saying something #qconlondon

Dan North was a cheeky a rascal as ever, actually making the audience think! At a conference! Oh, the humanity! Colin Humphrey from UK Atlassian partner Carrenza gave an overview of the fantastic build pipeline they create for their customers, along with insight into the business drivers of using such a build pipeline with respect to IaaS, PaaS and SaaS solutions.

jr0cket Adoption of continuous delivery is becoming ubiquitous, companies asking @Carrenza to deliver this via Platform as a Service @hatofmonkeys #qconlondon

I had the pleasure of listening to Ade Oshineye sharing his experiences when developing Google Buzz & Google plus and how understanding how someone is going to use your code is very important when developing a public API, you cant just expect them to know everything you know.

Atlassian also realised the importance of the developer experience as it helps engage with the wider community of developers as well as our own teams, enabling them to start developing amazing plug-ins quickly. The last year has seen some real usability improvements to the Atlassian SDK and our Atlassian Developers website and with JIRA 5.0 we have a stable API that is guaranteed future proof for all future 5.x versions.

Everyone had great fun at the Atlassian party on the Wednesday night and very large Cenral Hall building was bursting at the seams.

Organising the Atlassian party was a nice little challenge as the hall was massive and I had very welcome help from our UK partners: Gareth Wilson (Adaptavist) and Matthew Buckland (Clearvision).

There was a great spread of food, although we did tease people a little by it coming out in stages! There was also a great selection of beers, not just bottled larger. There was everything from Newcastle Brown, John Smiths, Spitfire, a nice range of largers and even some wine at the request of Trisha Gee.

QCon London 2012 - Pictures from the Atlassian Party

Find out other great events and party’s Atlassian are involved with on our Events List.

Thank you

This work is licensed under a Creative Commons Attribution 4.0 ShareAlike License, including custom images & stylesheets. Permissions beyond the scope of this license may be available at @jr0cket
Creative Commons License

Clojure Developers Making Music Together - London Overtone Hackday

The coldest night in London of 2012 so far was the warm up to a symphony of music by a collection of unstoppable Clojure hackers. As it was my first hackday with Overtone there was lots of new things to learn, from setting up the environment to a whole load of interesting music theory.

I also have Gnossiennes No.1 by Erik Satie on an endless loop in my head after having fun playing around with a piano synthesiser.

I cant really cant do justice to how much fun it is working with Overtone. Its like getting your hands on a Stylophone for the first time, just after seeing Rolf Haris demo it on TV! The only difference being you can make much better music with Overtone.

There is something just so ultimately geeky and fun in creating music using a functional programming language like Clojure.

I first tried Overtone at a London Clojurian coding dojo and with the help of the rest of the team we were quickly creating weird and wonderful sounds - although not quite in the same leaguge of

Thanks to some great documentation on the overtone github site it was pretty easy to set up my lubuntu laptop with an audio server, Overtone server and a nice lightweight clojure development environment (emacs, leiningen). I am afraid it will take me a bit longer to absorb music theory!

Setting up the audio for Overtone

In order to get sounds out of your overtone project on Linux, you need to add a few packages.

sudo apt-get install jack-tools ant openjdk-6-jdk fftw3 qjackctl

As you grow your overtone project you may want to switch to a linux kernel set up for real time processing, but to start with this is not necessary. If you do get more involved projects, its probably a good idea to also look at Ubuntu studio which provides a great selection of audio, video and graphics tools.

_Mac OSX already has a suitable sound server, so nothing extra is required. If you are using windows, overtone is supported also (not sure if you need to set anything up though).

Create a new overtone project

An overtone project is just like any other clojure project, with the overtone dependency added.

Create a new clojure project with your build management tool of choice: maven, cake or leiningen. I used leiningen as my tool of choice.

lein new tutorial

Add the Overtone dependencies to the project configuration file tutorial/project.clj

(defproject tutorial "1.0"
:dependencies [[org.clojure/clojure "1.3.0"]
[overtone "0.6.0"]])

With the overtone dependencies added to the project file, used leiningen to download the jars that make up overtone itself.

lein deps

Leiningen will download about 16 jar files for overtone 0.6.0 and places them in the project lib folder. This gives you all the libraries you need to start creating things in overtone, including an appropriate version of clojure.

Fire up your environment

Emacs not only has great support for the Clojure language, its a great way to try out your code by evaluating individual functions (s-expressions).

My preferred way to launch emacs is to change directory to the project top level and fire off emacs with the project file

emacs project.clj &

Using the dynamic environment of Clojure, the REPL, is a great time saver for trying out functions as well as running your project code. To fire up a repl inside emacs I use the new emacs 24 approach, running Meta-x (clojure-jack-in) to start up and connect to a repl using the underlying lein project file.

Meta-x (clojure-jack-in)

I have set up a keyboard shortcut of C-c C-j to make this even easier.

Starting Overtone

For my initial experiments I run an overtone server on my laptop, that way I can also play on the train home. You can also use an external overtone server called the SuperCollider (no not the LHC)

In the repl, I fired up the internal server (dont try to fire off both servers in the same repl, it crashed my repl)

in the REPL
(use '
_____ __
/ __ /_ _____ _____/ /_____ ____ ___
/ / / / | / / _ \/ ___/ __/ __ \/ __ \/ _ \
/ /_/ /| |/ / __/ / / /_/ /_/ / / / / __/
\____/ |___/\___/_/ \__/\____/_/ /_/\___/
Programmable Music. v0.6
Hello jr0cket, may this be the start of a beautiful music hacking session...
# Defining my first instrument
I soon discovered that it does take a little time to build your instruments. Its like any good programming challenge, there are many ways to do things and there are always lots of surprises. Reading the [getting started guide]( helped me with my first instrument.

(definst annoying-tone [] (saw 220))

This is a simple and rather annoying tone that uses the saw function to create the sound. To play the sound I simply call its name:


The easiest way to end your experiment in sound quickly is to use the (stop) function.

Quickly testing out your instruments with emacs

Many cool things were done at the hack day and it was great fun to play with the Ableon Novation Lauchpad. Its a midi controller that can be used to help you play your instruments and make it easier to turn overtone into a song maker.

I got as far as creating a few basic instruments and borrowing a few others, such as the one to create Jingle Bells!

Thanks to Phil Potter for having the energy to organise this event, Thoughtworks for supporting us with the venue and everyone there for making it a great day.

To have a whole day focused on overtone really helped me accomplish something and its going to be easier now to keep the learning going. All my experiments are now uploaded to my github account.

Hope you find the time to make music with Clojure and Overtone, you will love it.

Thank you.

This work is licensed under a Creative Commons Attribution 4.0 ShareAlike License, including custom images & stylesheets. Permissions beyond the scope of this license may be available at @jr0cket
Creative Commons License

MonkiGras London - the Craft of Conferences

It a little soon to be choosing my favouite event of 2012 but MonkiGras London is going to be a hard act to follow.

Monkigras London had such a diverse range of topics, a great line up of speakers, great party games and a host who had so much passion and enthusiasm share. It certainly was the most thrilling of conferences to experience. Here are the parts that stood out the most.

Read More