CAS Agile Spain 2014 – The next management

Last 3rd and 4th of December 2014 I attended the CAS 2014 conference that took place in the gorgeous city of Barcelona, Spain. During these two days I attended a series of conferences covering all the aspects of modern approaches on agile technologies along with detailed aspects I wasn’t aware of in project management.

The experience was extremely productive and interesting, and I just regret not being able to attend all of the conferences (normally, you would have to choose between several options, as there are too many speakers at once, and as usual you probably regret attending some, being some kind of lottery somehow). While you can see all the conferences in the official website, most of them were purely in spanish, being not quite convenient for English speakers.

Here’s a résumé of the conferences and keynotes I attended:

 Jurgen Appelo Keynote


Jurgen is the author of Management 3.0. I was lucky enough to share a dinner with him the previous night, where we interchanged some interesting points of view regarding privacy in social networks.

The main message of his key note was: How can we change our workers? Clearly, by boosting the following key elements: Motivation, organisation culture, manager mind-set, teams that will take responsibility, managers that will trust their teams, and develop people’s competencies.

According to Jurgen, the concept of management is too important to leave it to old-fashioned managers. Everyone is a manager. The world needs less “managers”.

And, indeed, leave the project success to serendipity is not really good idea. Do we really know the people we work with? Do we want to? Knowing each other is an effective way to work, but it doesn’t always work for some people.

When it comes to project completion, there’s a huge gap between the concepts of offering, committed, started, persisted and finished. Only 7% of all the purposes truly make it to the end. The key is to FOCUS ON THE GOOD STUFF. Not in the problems.

After some brief introduction to the concept of Kudo Cards (tokens of appreciation for employees) and the new funny job titles (like “Common senser”!), Jurgen spoke about workshops and performance measurement.

Workshops: are they really useful? You make decisions for others and you may explain your motivation, but a discussion isn’t desired or wanted. Your listeners decide if your motivations are wise. It’s their call. It’s a command.

And when it comes to performance, how do you measure your own? You should always do it by objectives and key results. A good example is the “Runner example”: an optimal result of performance is measurable (let’s say you set yourself a goal of running 10 km in one hour) and should always be 70% or 80% in the best scenario. A 100% score means you’re lazy. It was too easy if you could do everything perfectly. Metrics ecosystems are very good in all cases.

Then we moved to the tricky subject of people’s commitment, something very difficult to achieve. People like fairness over negotiation most times. And when it comes to salary formulas: Commitment should be the measure key, not the hours spent at the office.

In the matter of project failure: failures are part of our daily progress. Without failing there is no learning. A complete success is just efficiency, not learning. Same goes for mistakes.

And finally, a sentence to remember: Scrum is like your mother in law. It doesn’t solve your problems, just points at them.

You can see the whole keynote here. Long but worth it!!.

 Unit tests suck and it’s our fault by Jose Armesto


Jose made a very funny but also interesting and productive presentation about how testing code is good for every team if used efficiently and also how it should be coded. Here are some of the issues he pointed out:

Test code is different from other kind of code. There are some subtle differences. Test code must be trustworthy, express the intent and has to be flexible.

It is important to choose good names, there’s no need to read the whole body of the test. Even if the function name is long, the name of the feature should be self-explanatory.

We must also avoid logic inside tests: Conditionals, Loops, etc. Who will test the tests if there is logic inside them? Straightforwardness is the key.

Highlight the important stuff: Do not add much information, just the main points. Think what you can leave out. The name of the feature should be self-explanatory.

Don’t hide the important stuff: express the intent. “Extract method” is not meant to reduce lines of code. Just make it more readable. It’s about thinking, not typing.

The usual suspects in failure are generally setup and data providers. Setup moves important code out of sight. You have to remember where the code was. You lose context on why that code is there. It’s better to use a “explicit setup”. Data providers tend to make tests more complex, the most meaningful parts of the test are outside the test (Input and output).

Builders to the rescue: Building the same objects over and over make everything dependant on the constructor. Sometimes a particular constructor requires variables not needed for the test. It’s a good idea to create a builder in order to instantiate the class.

Create your own abstract language. Create own methods and use them in tests. They can potentially be used in other tests, becoming recursive. They can even make non-developers understand the testing code.

When it comes to describe and execute test doubles:

  • Dummy: Substitutes the original but won’t be used. Always use the real objects unless it has side effects or it’s somehow expensive
  • Stub: Copy of your class for testing. Value object, Entity and Service.

Avoid test doubles for value objects. Think twice for entities.

Concept of command Query separation principle: Commands change the state of the system but don’t return values. Queries do, but system does not change. This is free of side effects. Stubs are used when you want a query to return a value.

An interesting point was: without test doubles, is it still unit testing? Tests need to be dependency free. Don’t modify tests when refactoring.

How much testing is enough? Write tests until fear is transformed into boredom.

Confidence + Communication = Success.

High code coverage is not a goal, it is a side effect. Most importantly: THINK. Don’t follow rules like these. Just do what works for you, these are just guidelines.

Testing makes you faster. Throw love to your tests. If you go slower, find why. TDD makes things far easier.

Here is the whole conference (spanish).

Scrum Pocket Edition by Vanesa Tejada


Vanesa made a pretty straightforward and simple explanation on the Scrum framework, covering what’s Scrum, the Scrum roles and Scrum cycle. The speech was definitely interesting for newbies. After covering the Scrum master, Product owner, Dev team and Stakeholders roles, she explained the main elements of a Scrum cycle: events & artefacts.

A bit of detail on these events:

The Business meetings make the product backlogs grow: it is the single source of requirements, the product vision. The product owner manages it. The whole team is responsible for it.

The grooming sessions define the details and estimations of the product backlog items. Everyone should be there, including the stakeholders.

The sprint planning defines the backlog and work to be performed by the sprint.

During a sprint, the product owner keeps the backlog clean and prioritized. The stakeholders support requests and progress. The team creates the increment and focuses on achieving the sprint goal. The Scrum master is the leader of the Scrum team, and removes impediments in order to make the development team progress in their tasks.

The daily scrum or daily stand up should cover what we did yesterday, what we do today, and what is blocking us.

The sprint review meeting establishes what’s done and not, and shows a demo of the increment. It decides what we do not need and prioritise next sprint.

The sprint retrospective meeting tells us: How was it? What went well? What can we do better? How do we implement our potential improvements? It’s very important to have a proper look back.

The Main advantages of Scrum:

  • Effective team collaboration
  • Complex projects
  • Iterative, incremental approach
  • Deliver products with highest possible value
  • Transparency, inspection and adaptation

Here’s the conference (spanish).

 Scrum Masters, Product owners, Agile coaches, unicorns and other mythological beings by Isra Alcazar


Israel had a very interesting approach to the Scrum framework that complemented perfectly the previous speech, in a very clever tone, and using a very catchy and straightforward message channelled through the human emotions.

We live in a world of constant tech evolution (Google Wallet, Uber…) and old-fashioned business models need to catch up fast in a world of fierce rivals. Hence, new ways to focus problems have to emerge.

Why Agile now? It’s not new at all. Agile focuses on people, not technology. And also focuses in iteration cycles, cooperation and communication.

Scrum is just a framework with a series of tools and a team or set of teams that must or should be multidisciplinary, small and self-organized.

The product owners are focused in the business model and have the vision of it. They have to be in constant contact with the stakeholders and are in charge of organising and see the best perspective and interests for everyone in the chain. And of course, they need to build and prioritise the backlog requisites. They are the unicorns, like the scrum master.

The Scrum master is the facilitator: shows empathy, listens, removes impediments, coaches and mentors, NOT telling the team what they have to do. The teams must find their own way. Same way the scrum master should be able to help the product owner, being a good speaker and especially a good listener.

The agile coach must be the mirror where the team and roles look at, and the amplifier of issues that some people do not see or appreciate. He must also be a giver of feedback and supporter of the company or organisation in transitions to Agile. Not many so far…

The challenges:

The Team must deliver every 2 or 3 weeks, learn to automatize, testing, handle new responsibilities, communicate, self-organize, having always in mind that not talking is a very bad idea. Sometimes people email each other instead of talking when they’re close to each other!

The product owner must deliver the info, search for new tools in order to know what the users want, be the new speakers, have different responsibilities and abilities, and most importantly being able to say NO in the most assertive way.

The scrum master is the facilitator, the conflict solver, the impediments remover, the promoter of new ways of thinking, the change catalyst. Should a team leader be the scrum master is still a polemic discussion, though!

However, when we talk generally about the people, the human beings that compose the teams, we’re all just a combination of thoughts (facts, body language, values, prejudices, beliefs, expectations), emotions (feelings, fears, Frustrations), needs (what do I need, what do WE need) and actions.

The human thinking moves through belief and emotion into action. For instance, believing the product owner is our boss has consequences. What if I believe internally his ideas or thoughts are worthless or plain shit? We will probably just swallow it.

When it comes to fear, there are many types. The fear of survival (to be fired), to failure (not being totally sure of your efficiency in a particular role, or showing weakness when you’re not meant to), the fear to lose power (Does my status inside the company get compromised?), and change in general. People fear change instead of embracing it and leave our comfort zone.

We cannot forget about hierarchies and the rest of the company. Hierarchies have always existed and it’s something the world has used since… forever?. We must work inside and outside our teams. This makes possible the “invisible relationships”.

Who approves your holidays? He/She is your boss. It’s not healthy who decides this is the product owner. It’s not a healthy relationship. Who you smoke with even if you don’t smoke? It generates empathies and the opposite too. Who you go for lunch with? How can you help each other?

By understanding reality

Available options:

  • Trace an action plan
  • Let things be
  • Do
  • Feedback
  • Improve

Conclusion: It’s all about emotions. We just got to learn peoples’ contexts and their emotions so we can help them improve.

Have a look at this fantastic speech here (spanish).

 Beyond budgeting by Bjarte Bogsnes


Bjarte made a quite technical speech about self-management and budgeting. While I could not totally connect with this talk (I’m a developer after all), I did understand the value of some of the key points he made:

  • Case for changes. What causes the problem that requires a change?
  • Beyond budgeting principles
  • Statoil model – Ambition to action

Usual budgeting problems:

  • Weak link to strategy
  • Time consuming
  • Decisions made too early and often too high up
  • Assumptions quickly outdated
  • Accordion forecasting horizon
  • Can prevent value adding activities

When managing traffic performance, who manages the information and based on what? We should compare traffic lights to roundabouts: same objective, very different answers. What’s more efficient and more difficult?

Most of management means make people’s work difficult

Self-regulating management is nowadays essential. The world has changed and we must adapt the way we lead and manage, especially processes, to have a balance between dynamic (risky) and stable (rigid, rules-based, centralised, control, secrecy) management. That is the theory X. Theory Y means Values based autonomy, Transparency, Internal motivation. We need to move from narrow measurement into a holistic assessment.

  • Translating strategy from ambitions to actions
  • Secure flexibility, room to act and perform
  • Activate values and leadership principles

Not everything that counts can be counted, not everything that can be counted counts
Albert Einstein

Here’s the whole keynote (in english!).

 Generating tests by Rafa de Castro


Rafa made a pretty fast-paced but extremely interesting speech about tests generation, focusing in impediments and key points to follow if we want to have efficient test suites for any purpose.

Why do we have a complicated relationship with TDD? We love it until we have a production bug or something does not work as we expected. We can test properties by using tools such as Scalacheck, Rantly or test.check, but Rantly was chosen as the tool to use during his talk.

First step: have generators such as string, integer, list, hash…

Shrinking goes next, reducing the string or data to see if the test passes. That way we know “reduced successes” and the minimal failed data. Shrinking is extremely important, as it allows developers to THINK.

Finally, some good practices when it comes to tests generation:

  • Create a command pattern: a common interface with all the possible commands for our system.
  • Aim for concurrency, possible but difficult to achieve. A unit test by definition must be repeatable. But it’s awfully complicated.
  • Create a sequential phase and a parallel phase with threads.
  • Refactor with less fear!

Finally, he recommended reading the book Scalacheck: the definitive guide.

Have a look at the conference (spanish).

 Integrating UX & Design in Agile design / The history of the after years by Antonio de la Torre


Probably one of the best conferences I attended. I really fell in love with the contents of this speech and the passion Antonio put in it. The slides were also great! Here are the key points:

Two years ago we would create user stories from the info given by the manager, a maybe not very useful practice. A new way to work was needed. How could we work this out? By using mixed teams we would get fewer storms, a new way to work with everyone’s needs.

The design part seemed to be isolated always from the Agile project, as if it was less important. The level of empathy with the UX team meant lots of discussions.

The list of functionalities is pretty much defined by the UX specialist. They know what the user needs. They help defining the product by creating the MVP (Minimum Viable Product) and the iterations. They facilitate team dynamics, inceptions, user personas, workflows and Things that matter and not. Most importantly: they provide empathy.

The main point: The analyst as we know is DEAD.

The agency model: cascade with Analysis, UX, Design, front and back end development… analysis means knowledge. The design part means rework, contract extensions, parts that were ambiguous… and this is why there are so many contracts in the market.

As a good practice, there should always be a two-hour meeting with designers in order to save a lot in misunderstanding. It’s called Lean UX.

How does this work for Scrum and the sprints?

UX plans activities shortly before scrums by defining stories, wireframes, prototypes, etc… but how shortly before? Just enough to set the definition of “ready” and assist the sprint definitions of the project to be validated by the customer.

Everything goes together. Designing all stories at once doesn’t make any sense. It’s not the same the story of the landing page than the story of the user profile. The backlog needs to be defined in parallel having the designs into account.

Working with “The tool”: We want everything in “The tool”. In the sprint kitchen, sprints are not reutilisable. But there should be sprints for design, and designs for other issues? Reordering is essential in order to block and prevent further suffering. Other way to do things is divide tasks in two, but this is not a good practice.

Cooperation is the key! Focus on Sprints! Work! Be productive! Then usually two weeks later we decide to pay attention to other projects. WTF?? This is so bad for motivation…

You can’t fill Sprints with execution. It is about Knowledge. It is about quality. This is the approach of a designer. The designer knows the product deeply, same with users.

Definition of a Kanban flow (LINK): Improve the flow, less planning, more collaboration, iteration and reduction of waste. With it, the organization of Sprints disappears, but still needs a high responsibility in pulling from it. It needs dedication as well: to know who needs to do what at all times. Kanban means “pull”, but the main focus of Kanban is to dramatically reduce waste. All that’s started is finished.

And then what? The team should keep on growing with designers and UX engineers.

Feel the force and trust your Scrum master (or Agile hero you have inside).

Here’s the full conference (spanish).

 Software debt by Angel Núñez


While the subject is one of the most interesting ones when learning the Scrum culture, this speech felt literally taken from one of my favourite Scrum books, Essential Scrum. Most of the slides came from this very book and I definitely encourage you to read it.

The cases explained during this speech were practical ones where release dates haven’t been achieved, real cases: problems with Drupal, one of the most used CMS in the world.

Technical debt was detected in their platform at some point and that’s what was killing Drupal. They couldn’t handle the technical debt.

Technical debt slows development, but can be repaid. The problem happens when this debt is not repaid: it grows exponentially and every minute spent in not-quite-right code counts on interest on that debt.

Technical debt is like drug addiction. Once you hardcode, the code wants more. The technical debt is not totally bad as it can speed up development as long as it is quickly repaid. It is also okay for quick deliveries; reduces initial costs or sensitive delivery dates.

Software tech debt is inevitable. Its problem is not its existence, it’s its management. Problem isn’t just the developer, the code or the refactor. There are many kinds of software debt: Technical, Quality, Design, Infrastructure, Configuration management…

The holistic management means: involve and educate, visualise and measure, sustain, attend and pay, plan and experiment…

Involve and educate the product owner. He’s the first to be involved. Evaluate the software debt impact. Visualise and measure by code metrics, velocity and bugs. Sustain rhythm and quality: Don’t push, but pull.

Here’s, once again, the full conference (in spanish)

BONUS TRACK: Round table with Cristobal Colón, Pedro Serrahima and Jorge Uriarte regarding work ethics.

Unfortunately this fantastic video is only in spanish, but if you have the chance to see it (and understand it!) or subtitle it, please do it. It’s a really inspiring and beautiful insight on the beauty of work and ethics above economical interests.

Posted in Bango Development Team | Tagged , , , , , | Leave a comment


It’s Friday, exactly one week since POC JAM! Iain, Alexie, Keir, Dani, Santi, Jack, James, Yomi, Nick, Nelson, Asad, Neil, Sean and Maria gathered in the boardroom to do a retrospective of the event.

On the agenda were the standard retrospective topics; talking about what went well and what could be improved. But before we get to that, I should probably explain what POC JAM! is all about…

What is POC JAM!

Jam: noun: an improvised performance by a group of musicians, especially in jazz or blues
– or in this case, improvised performance by a group of software developers!

POC: noun: Platform Operations Centre
– a team reporting to the VP Platform Operations, working round the clock to carefully monitor the platform and third party connections and innovate new ways to deliver our services at high speed and with low cost!

I asked the POC to present a range of challenges they face using the tools they have available to do their jobs and I asked the developers to jam some solutions to help with those challenges.

POC will get some new features and developers get work in which ever style they prefer with whomever they want on which ever challenge they are most motivated by.

It is a win-win!

Getting started

It’s Friday, the day of POC JAM! Asad, Jon, James, Neil, Sean, Lewis, Jason, Yomi, Santi, Alexie, Andy, Glenn, Jack, Nelson, Dani, Iain, Keir and Maria from development and Chris, Dan T, Dan L, Max and Kieran from POC are gathered in the boardroom to kick off the day.

On the agenda were important topics such as ordering pizza and the deadlines for completion of the tasks. The morning started with a brief introduction to the concept:

Only one business day has been set aside for this experiment. Whatever is developed has to be ready for quality assurance Monday morning…

The POC had prepared 15 tickets with a headline for their challenges ahead of the event. Each POC member then took it in turn to describe the challenge in a bit more detail, spending no more than 60 seconds per ticket.

After the presentation of available tasks to work on for the day, the developers voted for the tickets they would like to solve. First round was to gauge interest and a developer could vote as many times as he or she wanted to. In the second round each developer only had one vote – chose what you’ll be doing today.

After two rounds of voting seven teams had formed – seven tickets were hopeful of resolution! Two tickets didn’t get any votes in the first round and unsurprisingly didn’t get picked and they are still stuck to the wall, fading more for each day that passes…

Just in case the rules had been forgotten they were reiterated – there was a lot of excitement in the boardroom and I know developers can sometimes get overexcited (I should know, I used to be one!)

The rules

  • Use common sense :-)
  • Your work has to be ready for upload to QA Monday morning
  • No new hardware requirements guys, seriously ;-)
  • Make sure existing stuff that worked before you started still works when you’re done
  • Try something new
    • Peer programming
    • Test driven development
    • A new methodology
    • Work with someone you don’t usually work with
  • Remember to have some fun


And so the creation of awesome stuff commenced.

Here are a few tweets from the teams as the morning went on.


And the progress made! Not that I take this diagram completely seriously…


Most of the morning was spent in meeting rooms, white-boarding (which is not a form of torture) and brain-storming (which is not related to the weather forecast).

During the retrospective several developers agreed that POC JAM! had given them the feeling that they could achieve a lot in a day. That doesn’t really match up with the numbers (captured one week after the event, for the retrospective):

If we define “complete” as “the solution is working in production and is accessible and usable to the POC”:

  • If we look at the completion rate inside timescales: 0%.
  • If we look at completion rate over all: 0%

Now, a mere four weeks after the event, four out of the original seven tickets have in fact “completed” – and the POC are happy, but more about that later…

After a bit of chasing a Domino’s order was finally put together – who knew developers could be so engulfed in problem solving they would forget to submit a pizza order on time?



Even the sales team got involved in the excitement – and the pizza!


And as the day went on the progress became more apparent in my inbox…


I had chosen a Friday for this experiment and the general Friday afternoon atmosphere started to spread. It was noted in the retrospective to try a different weekday for any future events because it is a well-known fact that the TGIF sets in relatively soon after pizza, hence why only two out of the seven tickets made it to QA in the timescales given.

As the facilitator of this event that didn’t fill me with much confidence. I thought I would have to cling on the fact the developers when asked had said they were more motivated on the day of the event than they had been during the week, and the fact that some knowledge would have been shared and that at least we had only “wasted” one day. And I was frightened the POC would be upset, and the leadership team and all the people who had wished to book meetings or tasks but had been turned down for that Friday because of a “failed” experiment…


I had not needed to fret for all was well in the boardroom the week after the event and although the delivery of solutions to the POC were weeks late (and some still incomplete) optimism was shared all round!

The developers thought it had been a great opportunity to try out new stuff and they all agreed the morning had been particularly invigorating! They all, bar one, had fun and were keen to do it again. (The one who didn’t have fun had accidentally lost all his work, which is never fun!)

The list of things they suggested changing for any future events was longer than the list of positive outcomes, but they all loudly proclaimed that was not at all a reflection on how much they had enjoyed doing it.

They suggested changing the voting process, the time of the voting process, putting in place measures for forcing them to do things differently, changing the seating arrangements for the day and making the tracking process for completion of work more formal (or maybe that was my idea).

I met with Tanya, Chris and Jamie from the POC to get their thoughts on the event, and despite the lack of concrete solutions to the problems they had presented they were also extremely enthusiastic and even wanted to help out with any future events – even if it was a jam where the produced results would not directly benefit them. On top of that they were keen on exploring the opposite idea – what can POC do for developers? Does anyone need an upgrade of hardware or anything like that?


Do it! Just do it!

The key elements I think you should consider before embarking on this jam journey and the things we will change for our next event are listed below, in bullet point form for your (and my) convenience:

  • Define the scope! Limit what the team can work on by presenting them with a range of problems they can chose from to keep the focus and to ensure the business will see a benefit. For future events this might change!
  • Make sure the day is blocked for this purpose only and make sure the rest of the business is made aware well ahead of time to prevent disappointment in unavailability of development resource or developers being dragged away from the jam.
  • Don’t do it on a Friday. People want to finish on time and enjoy their weekend.
  • Present the problems to be solved the day before the jam but leave the voting until the morning of the event. This gives the team some time to mull over the problems and possibly form valuable ideas. It also clears up more of the day to solve the problems.
  • Put in place simple and easy to follow processes for communication between the people who are stakeholders in the problems and the team solving them. This should also be used for tracking the progress and code releases and the final handover of a service or product.

Oh, and did I mention, just do it!

Posted in Bango Development Team | Leave a comment

Bango Dashboard for Operators v2.0

The Bango Development Team has just completed work on version 2 of our Bango Dashboard for Operators. This latest version provides you with a more customizable interface, and the ability to drill deeper into your payment analytics data. Here’s a list of the highlights:

Enhanced Date Selection

You can now run your dashboard reports using either pre-set dates (Today, Yesterday, This Month, Last Month); or custom date ranges as shown below:

Date Options

Select Pre-Set or Custom Dates


More information on your top selling content

As well as the overview of your top selling content, you can now hit the ‘View more’ button on the top right of the bar chart to view more of your data:

View More Option

View More Option 


View More Detail

Top Items Drill Down


Custom Chart Scaling

The bar chart has been replaced with an area chart to accommodate our new custom date range functionality, and we’ve also added custom scaling to enable you to set and/or lock the graph scale to your preference:

Area Chart

New Area Chart

Custom Graph Scale

Customize your Graph


Export your reports

We’ve also added an Export to Excel feature, accessible from the toolbar on the top right of your dashboard:

Export To Excel

Export To Excel

User Management Features

Lastly, we have added a new feature to enable you to add new users, or edit your existing users’ profiles. You can access this feature by clicking on your name on the top right of the screen and selecting the options you wish to configure. These options include permissions updates, password resets and deleting users.

Manage User Options

Manage User Options Menu


User Permissions

Add User

Add a new User

User Settings

User Settings

resetPasswordWe hope you enjoy the newest version of the Bango Dashboard for Operators, and find the features useful. As always, we look forward to your feedback and comments!

Posted in Analytics reports, Application analytics, Development, Payment reports, Product Update | Tagged , , , , | 3 Comments

WebServices retirement – 2nd June 2014

As previously mentioned, older and obsolete versions of our WebServices APIs are being retired – see

We extended our support for these versions of the APIs through January until June of this year, however as nearly all customers have now successfully migrated to the latest versions, we will be closing down the older services.

We continue to develop innovative features and functionality and make these available through our APIs for you to use, along with a richer data set, enhanced performance and security, there’s no reason to not upgrade to the latest APIs.

Keep an eye on this blog and our support site for notifications of new versions as they are made public.


Posted in Development, Product Update, Web Services | Tagged , , , , , , , , | Leave a comment


We have been approached by customers and content partners to ask whether Bango has been affected by the ‘Heartbleed Bug’. We can confirm that none of our systems have been affected.

We want to ensure you are fully aware of the ‘Heartbleed Bug’. This bug has the potential to affect the Open SSL implementation of the TLS (Transport Layer Security) protocol. Details of the bug, vulnerabilities and how to reduce exposure can be found at

This vulnerability has been widely addressed since being discovered and announced on the 7 April 2014. The bug has existed since December 2011, so before being addressed the bug created the possibility for a malicious user to exploit a vulnerability in the Open SSL coding to access the system memory in client and server software potentially rendering visible data that might include security data, such as encryption keys, private certificates passwords.

The protocols HTTPS, FTPS and TLS are potentially vulnerable to this bug. The good news is that Bango does not use the Open SSL library in its products and services. We have ensured those vendors providing hardware and software systems, and support to Bango, are also not affected.  All of our systems have been scanned for the vulnerability both internally and externally; none are affected.

However, we highly recommend you review and change your passwords you use to access Bango Services; if you use the same password on any other system which was affected by ‘Heartbleed’ then these credentials could be used to compromise your access to Bango. As a matter of best practice, you should have a unique password per system or service.

There is no requirement for us to change our SSL keys and certificates as a result of this bug. Bango rotate our SSL keys and certificates regularly and as a matter of good security practice, we recommend you do the same.

We also recommend that you test your own systems regularly for security flaws, and you should also be aware that Open SSL use is not limited to webservers. It is also used widely in hardware and software network products, so we recommend that you test for this specific vulnerability in any of your own systems that you use to connect to Bango.

Posted in Development | Tagged , , , | Leave a comment

Web Services – Have you upgraded?

At the end of September, we notified you of changes to our Web Services APIs and the availability of the latest versions for a number of services (see

Because we are fast approaching the holiday season, we have extended our retirement of existing services until the end of January 2014 – however, you should aim to upgrade to the latest version as soon as possible – existing services are no longer being actively maintained, so if you encounter a bug or require a new feature not currently supported, you’ll have to upgrade.

If you have any further queries on how to upgrade, or require more information, please refer to the previous blog entry, or contact our friendly support guys by dropping them an email to

Posted in APIs, Development, Integration, Web Services | Tagged , , , , , , , , | Leave a comment

New Analytics Feature – Trend Reporting

If you’ve previously wondered about comparing your data between one date range and another, we have good news! Now you can with the new Bango Analytics Trend Reports.

With our new reports you now have the ability to compare trends in your data. For example, you can compare the average of sessions for every day last month with a day this month; or the weekly unique visitors from every week last month against every week this month.

There is a separate Trend report available for both web and app data. The web report is found on the Web analytics tab in the menu under Visitors > Visitor activity. The app report is on the App analytics tab in the menu under Users and Usage.

To get started first select your date ranges from the date picker.


The report will show you a line graph depicting the data for each of your date range selections. Below is a report comparing Unique Visitors from September plotted against those from October, comparing the data over Week’s Days.


Continue reading

Posted in Development, Preview, Product Update | 2 Comments