Actions from previous Retros
2022-12-14: Hack day - Monitoring and alerting
Retro summary
Start | Continue | Do differently | Stop | What tech stack do we feel we should go with? |
---|
Follow up on hack day work Get SMEs in where possible Avoid working on backlog tickets other than as spikes / investigations Following discovery, pitch ideas for teams to tackle Pre-discovery so everyone is up to speed at the start of the hack day Work to the strengths of the team you have Understand current as-is where appropriate Involve everyone Prizes are great motivators Consider ice-breakers / warm up exercises
| Using Service Standard Agile Phases (explain where necessary) Not being scared to structure the day Joint discovery and split teams for alpha / beta (for Hack day topics that merit shared understanding of the problem space) Picking the topic before the day (but encouraging people to wait till after Discovery on the day to start thinking about solutions!) Mixing up the teams Solving real problems
| Clearly work out what the problem is (during Discovery). Using double diamond perhaps to go broad and then narrow the focus. Also have different blueprints perhaps for different kinds of hack day (tech improvement, product development, team collaboration, etc) Pre-Hack day prep-work. Include a clear focus for the day (tech improvement, product development, team collaboration, etc)
| Being too ambitious. Consider the double diamond technique. Focus on achievables, and stretch targets Moving between Agile phases without a clear assessment of the phase you’re in (including, don’t forget, the possibility of ditching an idea from one phase to the next) Having too large groups. Each team on this hack day was 11 people in size. This is at least 50% too many, and possibly twice the ideal size. Having to procure our own pizzas - hack day budget!
| There’s a lot of questions around Prometheus and Grafana. Their usability is limited by our current need to go through Trustmarque. Rob indicated that changing this would require a complete re-procurement of AWS - a large piece of work. There wasn’t enough that came out of the day to conclusively say one stack was better than the other. However, when asked their preference, those that gave it (6) all said AWS Native felt the better option. |
Actions
2022-11-01: Hack day – dual location in-person event
Actions
2022-03-08: Hack day – Open house
Next time
Clearly decide at the start whether the problem statement your team is working on lends itself to UCD, Agile, etc.
More rapid planning at the start of the day to get a clearer course of action from the start.
Consider JFDI the 1st solution to gain insight to inform how you modify it and/or develop other solutions to the problem statement.
Follow ups
Review ideas - add to backlog / save for future Retros / discard?
Take chatbot idea and run with it - present at Review, with a cross-reference to having had a Hack day.
Hack days are safe spaces to conceive experiments against problems, build them out and have fun. Do we need to review any outputs before presenting relevant ones to users, or do we present the raw outputs in the context of this is a PoC created during a Hack day?
0 Comments