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!