Collaboration and innovation in 2014

As those of you who know me personally can attest, i’m never particularly enamoured with the phrase – “Thats just what we’ve always used”, or “Thats just how its been since i started”. Im a firm advocate of the Winston Churchill quote “To improve is to change; to be perfect is to change often.” and yet I feel that a lot of companies fail to do this.

A lot of us in IT like to reminisce about “Oh wow, 2.5″ floppy drives – I bet you dont even know why there isnt a B drive in Windows do you?” (Or worse still with the older generation – “Oh VAX was the best..”), instead of looking at the drawbacks which led to the eventual demise of these technologies. I feel the same can be said for email; its so engrained in corporate culture that no one has actually thought to product analyze email itself – in terms of:

1. What problems does it solve?

2. Is it fit for purpose and easy to use?

3. Is it advanced enough to allow for further growth and evolution?

In 1971 when ARPANET first devised email, I imagine the above were true – but it was also true that it would be 4 years until Microsoft would be founded, and another year until the breakthrough Intel 8008 microprocessor would be released. Nowadays, email tends to be the cause of more problems that it is worth, especially when used inter-company.

Dont get me wrong, I dont think email is all bad – for starters, how else would Sales teams communicate with customers? How else would electronic invoices be sent? How about emails that need to be tracked for auditing purposes (i.e. formal notices from HR, legal, and so forth)?

I think email has the same purpose as the one a postal system holds; content delivery rather than collaboration and speed. However, in the last 10-15 years  email has been used more and more as a collaborative tool between teams and departments, leading to infuriatingly long email threads, reply-to-all’s, and a lack of dynamism that can really hurt companies in the fast moving society in which we currently inhabit.

Email is also prone to abuse – we have:

1. Spammers / Scammers

2. Automated junk from websites and services

3. Junk you might have once thought of as a useful idea (i.e. “Oh its great that Salesforce emails me everytime a lead is created”).

Along with a million other ‘Junk rule’ creating annoyances.

So, what is the answer?

Recently, I’ve been working more and more in the world of ‘integrations’, taking data and events from one tool and doing something in another – and this has exposed me to a world of possibilities in terms of – “Why cant this idea be taken and applied on a company wide scale?”.

What if instead of having hundreds of folders containing automated emails – and then having to forward these emails to colleagues, then skype them “Hi, about that email..” – you could both see the ‘event occur’, and then discuss it live, along with the rest of your team?

In my company alone, we use at least 10-15 platforms across departments, ranging from ServiceCloud for customer success (nee: technical support), Salesforce for CRM and Sales, Jenkins for builds, Git for storing magic, JIRA Agile for SCRUM/Agile, ProdPad for Product management, and so forth. All of these tools generate events and it would be awesome if we could quickly access and collaborate on these; yet currently we (like many others) are reticent to set up email alerts as they will inevitably annoy us and be tossed into junk via a rule.

A potential answer? A chatroom-like tool that allows feeds directly from the aforementioned tools, but at the same time allows for the dynamic creation of rooms/group chats, sharing of files (Docs, images, etc) and more importantly – dynamic discussion and resolutions. Namely, Slack or Atlassian Hipchat.



Hipchat is a free (for normal use) tool from Atlassian, the makers of JIRA, JIRA Agile, Confluence, BitBucket and more. It allows tools such as their aforementioned products to send data and messages into various ‘rooms’, such as ‘Engineering’, ‘Support’ and more – meaning that if a new customer incident is raised in JIRA, it will appear in the Support room within seconds, allowing support engineers to quickly discuss the incident and assign appropriately.

There are a number of Hipchat integrations available here, ranging from GitHub and Drupal through to email and even Opsview (i.e. ‘customers edge router has gone down, send a message into the Networking room to tell them).



Slack is like Hipchats better looking, cooler younger brother. Its much more user friendly, the UI design is excellent and I love how easy it is to setup. The main differences I found with Hipchat and Slack are:

  • Hipchat seems more corporate; you have an IRC style interface for a start – with a list of users on the right that you can double click on to either IM or video chat (are people STILL trying to flog that as an idea? Let it die!).
  • Slack is easier to use and is a hell of a lot prettier from a UX perspective, which ALWAYS helps adoption.


The issue I found with trying to setup Slack and Hipchat as my email-killer, is that whilst they offer integrations, they dont offer an all-encompassing range that fits my needs perfectly, and as im not a developer I’d have no idea where to start in terms of writing my own integrations.

For example, with Hipchat the integration with JIRA Agile is excellent, you can be notified for all sorts of things – which is what you’d expect from 2 tools from the same vendor, however they offered no integration with Salesforce or ServiceCloud. Likewise, Hipchat had some neat integrations via webhooks, but also fell down on Salesforce integration, and their JIRA integration is pretty poor.

In order to get messages from these vendors into the ‘chat tools’ i just mentioned, you have to use another product that has popped up in the market in recent years, an ‘event broker’.

Event brokers

An event broker is essentially a man in the middle, who takes data from one tool, formats it, and sends it to the other tool – for a nominal fee (or free, depending on your tool de jour).

The benefit of using event brokers is that as long as they can talk to your chosen client (Hipchat, Slack, etc) then its generally much easier to setup integrations as thats their bread and butter. A few examples of event brokers are:

  1. Zapier
  2. IFTTT (If This Then That)
  3. Cloudwork
  5. We Wired Web

Some of these tools are free-free, such as IFTTT, and some are free to a point, such as Zapier, WWW and more. The pricing tends to hinge around:

  • Number of integrations
  • Frequency with which integrations can be delivered
  • Total messages that can be sent per month
  • Users

In my testing, I have so far looked at IFTTT and Zapier.


Verdict? Its OK – probably more use for home users and script kiddies than to a business, judging from the list of integrations:



It doesnt have Salesforce support, JIRA support, or other items like Jenkins etc however it does have GitHub support.


Verdict? Pretty good! It is incredibly simple to configure and use, and linking your accounts (i.e. the Salesforce account you want to get information via) is VERY simple to do. The configuration of what you want to send is also very simple, as it sucks the fields in from Salesforce, Twitter, or any other tool you want – for example, I want to send a message into my marketing room whenever my company was mentioned on Twitter, so they can discuss if they need to respond, etc.

To do this, I set up a new ‘Zap’ as below:





Trust me, it IS as easy as that. And now, whenever anyone tweets with the words ‘Opsview’, it will appear in our Marketing teams Slack/Hipchat room. Observe:


We can now discuss the tweet, respond if its a query, pass it onto Sales if its an enquiry, and so forth! All done without a single email. Ah the bliss.

What next?

The end goal is to have a fully automated solution, that takes in inputs from all of our chosen tools, uses an event broker (if required – some tools can output directly into Slack/Hipchat using Webhooks), and puts them into the correct room, in the correct format – allowing for quick diagnosis, recognition – and most importantly, COLLABORATION.

Heres a little screenshot of what ive set up so far:


Here, we are sending a message into the #sales room in Slack when a new opportunity is created (via the website or an account manager). We are sending an alert into the marketing room when we are tweeted about, and when a customer raises a ticket in ServiceCloud – the support team gets an alert. The plan is to roll this out to our other functions, then start the most painful part – driving adoption!

Potential barriers to adoption

So – this things bloody marvellous, why wouldnt anyone want to use it? Well there are a few areas:

1. It doesnt have a calendar functionality, meaning people will still be using Outlook to send calendar invites, and view other users diaries.

2. People are familiar with Outlook – meaning that when driving adoption, highlighting the advantages of this disruptive move (Crossing the Chasm, Geoffrey Moore) is going to be key to its adoption throughout.

3. People use Outlook for task management – Simple, use something designed for that purpose like Wunderlist, my personal lord and saviour of time management. Again however, there is likely to be some pushback on this – given people are still using IE, Id be amazed if they jumped on something like Wunderlist without reticence.


To conlude, email is good for external communications – but in my opinion, stay away from outlook when thinking of internal communications – it might have been the way to do it 20 years ago, but with the rise of event brokers, tools like hipchat/Slack, and an onus from software vendors on creating an easy to use API to allow for automation, the days of “email for everything!” is nigh – collaborative tools will drive customer success, and eventually the success of your business as a whole.

I see event brokers becoming more and more prominent amongst a user base who wants integration without the development headache – forcing vendors to create ‘recipes’ for these platforms such as IFTTT, Zapier, and co. Overall – software will become better at talking to other tools, which can only be good for customers.

Slack and IRC

As part of my Slack evangelism I’ve been hellbent on trying to integrate as many products I/we use into the aforementioned tool, to test out where the limit is on what this awesome product can do. Next on my list of things is IRC – that old warhorse. Opsview has a large number of users on IRC, yet I continually forget to start my IRC client after reboots, etc meaning i miss out on all the useful questions, comments and other items that our community have to offer.

Therefore, it sounds like a perfect technology to stream into Slack; 24/7 coverage of ANY IRC room – pretty cool, huh?


To find the right integration, I scoured the internet and tested a few different solutions. Some where just OVERLY complex, some just didnt work, and some were just right (Codename Goldilocks). The one that I found worked perfectly for me was ‘slack-irc-plugin‘, by Jimmy Hillis. To install any of the IRC bots, it turns out you need ‘node’ installed on your server. But lets back-up - how does this actually works?

Basically, you need something that is always-0n, which the irc-bot can run on. This bot connects to the IRC channel(s) and monitors what is going on, s that when something changes like someone posting a new message, the bot notices this and sends the information to Slack using the given parameters.  Essentially, you need the following setup:

Screen Shot 2014-09-04 at 13.03.16


The IRC Bot runs on your server/PC, and updates Slack whenever anything happens. So, how do we install it?


This bot, and the others I tested, all run on node which is interesting, as i’ve never had the pleasure of using node before. After some testing, it turns out that the version of node that some OS’s have in their repositories (like Ubuntu) doesnt work, so in my installation instructions I will give you the correct repo to use.

Firstly, lets add that repo:

Next,  clone the slack-irc-plugin from git:

Of course, change the directory above - DONT blindly copy and paste. Next, go into that new directory and lets build the tool:

This npm command is inherited from node. There will be some output now, as node downloads the actual components of the bot (listed in the node_modules dir) and installs them. After this completes, lets copy the config file and then edit it:

In here, we will need to edit the following:

Let me explain the above:

Server = This is the IRC server you are going to connect to, i.e. Freenode is

Nick = This is the name you want the bot to show as in the channels it joins.

Username = The bots actual username.

Token = You will need to create a new INCOMING WEBHOOK via – which will give you a token as a result, i.e.:

webhook api inbound

Next, we have Channels: This is where you bind which channels you want to watch in IRC, and where that chat is dumped to, so i’m monitoring the #opsview room in IRC, and I want to mirror it into an #irc channel in Slack.

Users: This tripped me up for a WHILE, but this is where you bind IRC users to their slack usernames. This is very finicky, but you need to include the tilde, i.e. ~ircuser, and you need to ensure that it is the same username as what is shown when you do an ‘/whois ircuser’. Your slack username is shown on your account, if you dont know it:


Finally, you really want to set ‘silent’ to true, otherwise the bot randomly starts blabbering into the channel which is pretty embarrassing, as i found out.

NOTE: This is all you need to get it working, as per the instructions, but i found that when i was running this (3rd Sept 2014) my bot was constantly joining/leaving the channel. I found out it was being kicked due to ‘Flooding’, even though it was posting no messages. After digging around in the API of the actual bot module, (link here if your bored), I had to edit the following file and line:

Doing this solved all my problems (well, IRC ones at least…). Finally, lets start her up:


I have no idea what any of that means, but i’ve fed it back to the developer as they might have more of an insight! But thats it, your bot is now configured and is sending data back to your Slack room when items are entered into IRC:


Pretty fancy eh? Now, go forth and Slack!

JIRA Agile and Workflows


After my post yesterday on JIRA Agile and Hipchat using post functions on workflow transitions, I played around with modifying the default JIRA workflow to include a ‘testing’ stage – as currently it goes from “Open”, “In Progress” to “Resolved” or “Closed” – with no mention of testing.

This is easy enough to add – you simply modify the workflow, and add a new stage, as per below:

Screen Shot 2014-08-14 at 14.03.43

Here I added a new status, ‘In Testing’, and linked it from ‘In Progress’ with a  ‘QA’ transition. This is really cool, because you go from having a default view of an ‘in progress’ story of:



To one that has a new button, “QA”, the developer has finished with the story:



When the developer clicks ‘QA’ (Or ‘Assign to QA’, whatever you call it!) the buttons will change, along with the status of the story / task, as per the image below:


Obviously, you might want to link the ‘In testing’ status to ‘In Progress’ again, if the testing fails for example – this is just a quick setup :) The problem we have with the above workflow however, is that the same workflow is not applicable to all types!

So what do i mean by this? Well, you might want to use a different workflow for tasks or bugs, compared to user stories – i.e. in a user story, you will generally have ‘developer’ tasks and QA tasks, therefore having a developer task go to ‘In testing’ makes no sense – you might want just ‘open’,’in progress’ and ‘closed’ for example – whereas bugs might be ‘open’, ‘in progress’ and ‘fixed’, etc. Luckily, there is a way in JIRA that you can create seperate workflows for specific items – hidden in plain sight at ‘Workflow’ under your project:


In my example above – I have 2 workflows – one for ‘tasks’, and one for ‘everything else’. In tasks I have forgone the QA element – just to diffentiate between them, as per above.

Im not going to go through adding a workflow, as its really simple – you basically click ‘Add workflow’, choose the one you want (i.e. JIRA default), associate that with the issue types you want, and then click OK/Submit. Then, edit away – add new statuses/transitions, rename labels, add new post functions, and more. Then, publish – and your changes are applied!

Task in progress


Bug in progress



Basically, using workflows and post functions, you can pretty much customise everything you want in JIRA Agile. For example, I played around with ‘Slack’ last night on the recommendation of a friend, and whilst it wasnt as advanced as the Hipchat integration – it is remarkably easy to setup – just configure it as a Webhook, and again – select a post function on a transition, ‘Type: Webhook’ and voila, your configured! Its really simple but incredibly powerful.



Integrating JIRA Agile and Hipchat

Recently, I came across Hipchat as a user had created a way to send Opsview notifications into it – and i had no idea what *it* was. After having a brief google, it looks like a very interesting tool – a sort of chatroom meets dev tool blend, whereby development teams can chat and ask questions in amongst messages from other tools including GitHub, JIRA Agile and more.

So, naturally – as JIRA Agile users, and with HipChat being free, I wanted to integrate it so i could test it out. Unfortunately this is a bit difficult if you arent an Atlassian employee, so below are some simple steps to get you from 2 seperate systems, to an integrated setup where messages are sent from JIRA Agile into your Hipchat room of choice.

1. Link them together

In order to link JIRA Agile and Hipchat together, you first need an API key from Hipchat. To do this, navigate to https://* where * is your Hipchat domain. On this page, you will be able to click ‘Create’ new token which will generate an API key for you:

Screen Shot 2014-08-13 at 16.02.19

After creating your token, you will be left with an API – like so:


Copy and paste that bad boy, as you’ll be needing it in a moment. Now, login to your JIRA Agile instance - in my case, we are using JIRA On-demand, so if you are using the on-prem version this may slightly differ for you.

Within JIRA Agile, navigate to ‘System’ via the gear cog as below:

Screen Shot 2014-08-13 at 16.07.56

And once in here, go to ‘Mail’ and then ‘HipChat configuration’ on the left hand side:

Screen Shot 2014-08-13 at 16.17.01

In here..well, you know what im going to say next :) Paste in that API Badboy you copied earlier, and click save. For those using Hipchat ‘on premise’ (if thats even a thing), you might need to modify your URL here – but for me and most other users, just leave it as default:


2. Configure JIRA Agile

Ok, thats the easy part out of the way. JIRA Agile is now setup to talk to Hipchat (trust me, it is!). Now we need to tell JIRA Agile what to tell Hipchat about – to do this, we must edit our JIRA Workflow (scary!). The workflows can be found via the left hand menu under your JIRA Agile project:


Click on ‘Workflows’, and you will be presented with your workflow (or default one, if you’ve never changed it!). Now, we want to edit the workflow in order to tell JIRA Agile when to alert us – so to do this, click the little ‘pencil’ icon on the right hand side:


This will load up your workflow edit view. This is basically the ‘flow’ that your user stories, tasks and whatnot follow – and is comprised of 2 items:

  1. Statuses – Statuses are states that a user story or task can ‘be’, for example – a story can be ‘Open’, ‘In Progress’, or ‘Closed’.
  2. Transitions – Transitions are what happens when a user or developer changes the status of a user story, i.e. changing from ‘Open’ to ‘In Progess’ has a transition by default of ‘Start progress’.

The item above that we are interested in is ‘Transitions’.

What we therefore need to do, is edit a transition and set what Atlassian refer to as a ‘Post function’, i.e. something that happens when a transition is triggered. By default, the post functions are mainly ‘Send an email to annoy everyone’, or ‘Alert the boss’ – what we are going to do is add another rule, ‘Send a message to HipChat Room X’. (There is a very dandy and technical link here for anyone who wants to learn more).

Configure the post function

So, that sounds all very fancy and technical – how do we actually do it? Well I am glad you asked. Firstly, click on the LINE (the line being the transition), and you will notice a series of options appear on the right hand side, like below:


After clicking on ‘Post functions’, you will see a list like so:


This is ‘the list’ of things that are supposed to happen when the ‘Start progess’ transition is invoked, i.e. someone changes a user story from ‘Open’ to ‘In progress’. What we need to do next, is click ‘Add post function’ which is hidden in the middle right of that above screenshot. Clicking this will give you a a lovely list of options, one of which is, you guessed it, “Notify HipChat”:


Select this line and click ‘Add’, and you will get the edit screen for that particular post function:


This is where you can now specify the parameters – what gets sent, and where to. Use JQL to specify only certain projects to certain rooms, only certain epics, etc etc. In my example i left JQL blank but i ticked ‘All members, Ehertz and Private members room’ rooms (just a few examples I made up), along with the client-side notification – as I am running the dedicated OS X client which is rather nice. After clicking add, that is the configuration done!

Next, and finally, we need to publish our workflow. You’ll notice after clicking add that:

A) Your workflow now has another post function – your HipChat line

B) You have this new ‘Publish’ bar at the top

publish your workflow

Go ahead and click ‘Publish draft’, and then save a backup (if you want), and voila – your changes have been made – prepare yourself for the HipChat storm!

So what does it look like?

So now we’ve configured it – what does it look like? Well, this being a sample project and a sample HipChat room its not very interesting, but below is a screenshot of the hipchat client and the messages received when i created a new user story and changed it from ‘Open’ to ‘In progress’:


Cool eh! Now, imagine if you had a room for each development team, and their specific JIRA changes going into the room, along with the GitHub/Bitbucket updates and OTHER items – it would be awesome!

Now, go forth and configure!