Stuart Harrison, ruby developer for the ODI, introduced us to the ODI’s mission and how it facilitates ‘openness’.
I think for many Agile Staffordshire participants, including me, it was a great introduction to an organisation of which only the name may have been familiar. Stuart provided a spirited talk on the rationale for open data and shed some light on how open data has already gained some traction.
It is possible I am really late to the ‘open data game’, but I find the idea profound. I first encountered open data systems being realised during Brooklyn Beta 2013. Since then I have been interested in how applications can make use of available open data to overcome information hoarding. I think this is relevant to Agile Staffordshire, many of us being involved in software development for the web. How many great projects have stalled due to unavailable data; and particularly data that could really benefit society by being open, authoritative and reliable? Public information could be stored in several data stores, with no external access to the organisation responsible and with no arbitration or authority. Stuart explained the situation by way of a scenario involving an app designed to provide information on public transport.
The introduction to ODI provides Agile Staffordshire with a number of things to think about:
- How can we become more open? Would it help attract more members if we were?
- Could we make our projects open, inviting other interest groups to make use of the fruits of our labour?
- Is there scope to making our event planning open? Again, some transparency may assist us with reaching more people in the local area.
Overall, for me the main message seems clear. Great software, great business and great people all seem to share one particular trait. They all create more value than they take. ODI embodies this principle and I think we are better off for their endeavours. Software that provides a great experience and service, but also provides opportunity for others to build on it and create value elsewhere is good for everyone.
At the February meeting we ended proceedings in a truly Agile manner by inspecting and adapting the way that the group and meetings were conducted through a Retrospective.
For those who found this useful and want to take this away and try it elsewhere then here is the format we used:
- Give everyone some sticky notes, a pen and 5 minutes to consider the following two questions:
- What have we done well?
- What can we improve?
- Invite everyone to write down as many points as they want, one per sticky note, that answer one of the two questions.
- Place the two questions (or a 🙂 and 🙁 will suffice) as headings on a whiteboard, a wall, a chart, a table – anywhere that is visible and accessible
- Invite everyone to stick their notes under the relevant heading.
- Once everyone has had a fair chance (5 minutes) to stick their notes and think of any additional points then get everyone to sit down ready for the next step.
- Group any related notes together to avoid duplication.
- Invite everyone to take a pen and place a mark, dot, circle, tally or cross against the points they wish to talk about:
- Each person gets 3 votes
- They can vote for any of the notes, including their own
- They can place their 3 votes on any note, with all 3 on one if they wish
- Allow around 5 minutes for this activity
- Once everyone has voted you should see an order to the points that people want to talk about – take the top 3 notes as the topics that will be discussed.
- Spend the remainder of your timebox (we used 30mins but at Codeweavers we generally use 1 hours) discussing the 3 top points.
- Appoint a chairperson to control the flow of conversation and to ensure everyone gets a fair chance to speak
- Appoint a time keeper who ensure that the 15 minute timeboxes for each point are kept to – this isn’t strict but ensure the timebox is not abused.
- Try to summarise discussion into actionable points – two or three per point should allow you to complete these actions before the next retrospective. Some things don’t have actions, just the discussion is enough.
- When the timebox is up, the discussion comes to a close and no further points are discussed – if a point was not discussed this time, and it reoccurs for next time, it is likely that it will get discussed. Only points that the whole group deem important will be discussed so no one person will get to dictate the course of improvement.
- If you find that you don’t have time for 3 points, try just 2, or try extended your timebox.
- If you find you are not covering enough items then try taking the top 5 – be aware though, that your goal is to raise actionable points from the issues raised, so ensure you only cover what is likely to be actionable before the next meeting.
- Don’t make the timebox too long as people lose concentration and other stakeholders think you are wasting time in meetings. Keeping the discussion focussed and producing action points mean that other stakeholders (managers etc) can see the results of the meeting, and if you follow up on the action points, they can see the improvements being made.
- Give it a go, if it doesn’t work, have a retrospective retrospective – what went wrong, what can you improve, what went well? Change the format, ask on the google group for suggestions.