Gerard Chiva, Agile and business coach, made a very interesting speech about obsession with attention to detail, quality and pace on product delivery using a very interesting metaphor.
This is the first of a series of posts about the CAS 2015 (Conference Agile Spain) in Madrid, a really incredible meeting point to share learning and synergy between people who see product development in a different way, being this my second time attending. Since the amount of conferences I attended is big, and so is the amount of information I collected, I will summarize them progressively in the following days.
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.
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!
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!)
- 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!
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:
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:
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:
Export your reports
We’ve also added an Export to Excel feature, accessible from the toolbar on the top right of your dashboard:
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.
As previously mentioned, older and obsolete versions of our WebServices APIs are being retired – see https://devblog.bango.com/2013/11/27/web-services-upgrade-reminder/
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.
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 http://heartbleed.com
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.